Skip to content

How It Works

A visual guide to the core mechanics of the Agent Receipt Protocol.

Every Agent Receipt is a W3C Verifiable Credential recording a single agent action. It captures what happened, who authorized it, whether it succeeded, and where it sits in a tamper-evident chain.

Agent Receipt (W3C Verifiable Credential)idissuervalidFromversioncredentialSubjectprincipalwho authorized itactionwhat happenedoutcomedid it succeed?chainposition in sequenceintentwhy the agent actedauthorizationscopes and grantsdelegationparent chain linkproof — Ed25519Signature2020 (signs the canonical receipt)requiredoptional

The four required sections — principal, action, outcome, and chain — are always present. Optional sections like intent (why the agent acted) and delegation (who delegated the task) add context when available.

Before a receipt can be trusted, it needs a cryptographic signature proving the issuer created it and the contents haven’t been altered.

Receipt fields(no proof yet)RFC 8785canonicalizeEd25519 signz-base58btcSigned Receipt
  1. Start with the receipt fields (everything except proof)
  2. Serialize to RFC 8785 canonical JSON — deterministic byte ordering
  3. Sign the canonical bytes with the issuer’s Ed25519 private key
  4. Encode the signature as z-prefixed base58btc and attach as proof.proofValue

The same canonical bytes are also SHA-256 hashed to produce the link for the next receipt in the chain.

Each receipt includes the SHA-256 hash of the previous receipt’s canonical form. This creates a tamper-evident sequence — modifying any receipt breaks the chain from that point forward.

Receipt 1filesystem.file.readprev_hash: nullSHA-256Receipt 2filesystem.file.deleteprev_hash: sha256:a3f1…SHA-256Receipt 3email.sendprev_hash: sha256:b4e2…

All receipts in a chain share the same chain_id and issuer.id. A chain must have exactly one issuer — when an agent delegates work, the delegated agent starts a new chain.

When Agent A delegates a task to Agent B, Agent B creates its own receipt chain and links back to Agent A’s chain using the delegation field.

Agent A’s chainReceipt 1file.readReceipt 2delegates to BReceipt 3email.senddelegationAgent B’s chain (delegated)Receipt 1api.readdelegation.parent_chain_idReceipt 2api.write

Key rules:

  • A chain must have a single issuer — Agent B cannot add receipts to Agent A’s chain
  • The delegated chain’s first receipt carries a delegation field with parent_chain_id, parent_receipt_id, and delegator.id
  • Both chains share the same principal — the human who authorized the work doesn’t change across delegation

For the full field reference, see the Agent Receipt Schema. For verification algorithms, see Receipt Chain Verification.