Agent Receipt Protocol: How AER-1 Standardizes Verifiable AI Agent Receipts

What an agent receipt protocol is

A protocol is an agreement between strangers. An agent receipt protocol defines three things so that parties who never met can still check each other's claims:

1. What a receipt contains. The exact fields every receipt carries, so nothing essential is missing and nothing ambiguous sneaks in.
2. How a receipt is canonicalized. The exact byte sequence that gets hashed, so two implementations computing independently arrive at the same answer.
3. How a receipt is verified. The step-by-step check any party can run, with no account on the producing side and no trusted third party.

Without a protocol, every agent platform keeps its own logs in its own format, or keeps none at all. A log that only the platform can read is not proof. It is a claim made by the party being checked, in a format nobody else can audit. A protocol removes the platform from the verification path entirely.

Why AER-1 is the agent receipt protocol

AER-1 is published as an IETF Internet-Draft (draft-zambo-aer1), currently at revision 23. An Internet-Draft is a working document in the IETF process: public, versioned, and open to review. It is not a finalized standard. It documents behavior that open implementations already exhibit, and it advances through review like any IETF work.

That matters because a protocol only works if more than one party implements it. AER-1 has independent implementations in multiple languages, and framework packages emit AER-1 receipts natively for popular agent frameworks. A worked cross-vendor example is the AER-1 x Tanilo interop: a full run with real values, with the receipt chain verified end to end by an independent party. One format, another implementation checking it, no coordination required.

The receipt format

AER-1 receipts carry five interoperable fields:

1. Identifier. A unique ID for the receipt.
2. Creation time. When the receipt was minted.
3. Tool and caller scope. Which tool ran and on whose behalf.
4. Canonical bytes. The exact UTF-8 byte sequence of the observed result, preserved so verifiers can reproduce it byte for byte.
5. SHA-256 output commitment. The hash of those canonical bytes.

The canonical-bytes rule is the load-bearing piece: producers must preserve the exact UTF-8 byte sequence that was hashed, and verifiers must reproduce those bytes exactly and reject anything that is not valid UTF-8. This is what makes independent verification possible across vendors and languages.

How to verify a receipt

The verification procedure is deliberately simple, so anyone can implement it:

1. Take the receipt's canonical bytes.
2. Compute SHA-256 over them.
3. Compare with the receipt's output commitment.

Match means the stored result is the result the tool returned. Mismatch means tampering. Try it now with the public verifier at zambo.dev/verify, or mint your own test receipt first at the try page and verify that.

How to implement the protocol

Implementing AER-1 means following the format and the canonicalization rule, nothing more:

1. Capture at execution time. Record the tool result's exact bytes the moment the tool returns, before any rendering or reformatting.
2. Hash the canonical bytes. Compute SHA-256 over the exact UTF-8 byte sequence.
3. Emit the five fields. Identifier, creation time, tool and caller scope, canonical bytes, output commitment.
4. Chain receipts per session. Link each receipt to the previous one so the whole run is one tamper-evident chain.

Because the verification procedure is fully specified in the draft, a verifier written in any language can check any conformant receipt. For developers, framework packages add receipt collection to popular agent frameworks with a single install, so every run emits hash-chained, offline-verifiable receipts per the protocol.

What a verifiable receipt proves

Start in 30 seconds

You do not need an account, a token, or anyone's permission to see the protocol working. Mint a real verifiable receipt on the try page, then run it through the public verifier. Then read the spec itself: draft-zambo-aer1 on the IETF Datatracker.

Execution receipt protocol for AI agents

A protocol, not a report format. An execution receipt protocol for AI agents defines how receipts are minted at execution time, what they commit to, and how any receiver verifies them, so receipts from one system are checkable in another. AER-1 is that protocol as an open IETF Internet-Draft (revision 23): it defines the per-step receipt, the digest over the saved result, and the workflow record that binds a run's receipts in order. Implementations mint; strangers verify; the protocol is the agreement that makes both sides mean the same thing by the word receipt.

Zambo is the verifiable work layer for AI, and its receipts follow this protocol on every call, which is why a receipt produced here can be checked by a receiver who has never heard of the tool that produced it.

Proof of execution protocol for AI

Why proof needs a protocol at all. Without a shared protocol, every platform's proof of execution is a proprietary claim: a badge, a status field, a PDF. None of them can be checked outside the system that issued them, which means the proof expires the moment you stop trusting the issuer. A proof of execution protocol for AI fixes the semantics instead: what a receipt must contain, what its digest commits to, and what a verifier must recompute, so proof produced anywhere can be checked anywhere. That is the work AER-1 is doing in the open, with a public conformance kit implementers can test against.

Judge any candidate protocol by one test: hand its artifact to a skeptical stranger with no account and no context. If they can reach a verdict alone, it is a protocol. If they have to ask the issuer, it is marketing.