What is the difference between a payment receipt and an execution receipt for AI agents?

A payment receipt proves money moved: the amount, the payer, the payee, and the settlement reference. An execution receipt proves what ran: which tools the agent called, what the inputs and outputs were (hash-committed), and whether the record was tampered with. They answer different questions, was I paid versus what happened, and production systems need both.

Does a payment proof prove the AI agent did the work?

No. A payment proof shows that a payment for a call or a quota unit settled. It says nothing about what the agent did with that call: which tools ran, what data was touched, or what came out. Proving the work requires execution evidence, a tamper-evident record of the run itself, which is what AER-1 verifiable receipts provide.

Can an execution receipt settle billing?

Not on its own. An execution receipt proves a unit of work ran and that the record is intact, but it carries no payment rail: it does not move money or record settlement. Billing needs a payment proof. The two receipts are complementary: the execution receipt is the evidence for the invoice line, and the payment proof is the evidence that the invoice was paid.

Why do production agent systems need both kinds of receipts?

Because disputes split along the same line. A client disputing a charge asks was I billed correctly, which is settled by payment proofs. A client disputing the work asks did the agent do what I paid for, which is settled by execution receipts. One without the other leaves half of every dispute unanswerable. Systems that mint both give each invoice line a checkable record of the work behind it.

Payment Receipts vs Execution Receipts: What Each Proves for AI Agents

Q: Are payment-proof protocols and AER-1 competitors?

No. Payment-proof protocols operate on the money layer and AER-1 operates on the evidence layer. They solve adjacent problems in the same transaction: pay for the call, then prove what the call did. A complete agent economy needs a payment rail and an evidence rail, and they are designed to be used together.

The two questions, side by side

Every paid agent transaction has two halves: the money and the work. Each half needs its own proof, because each half is disputed differently.

	Payment receipt	Execution receipt
Question answered	Was I paid?	What ran?
Records	Amount, payer, payee, settlement reference	Tool calls, input and output hashes, hash chain, provenance
Proves	Funds moved and the charge settled	The work happened and the record is intact
Checked by	Payment rails, wallets, ledgers	The public verification algorithm, offline, no account
Dispute it settles	"Was I billed correctly?"	"Did the agent do what I paid for?"

What payment-proof protocols cover

Payment-proof protocols handle metered, pay-per-call agent transactions: an agent calls an API, a micropayment settles, and the protocol produces a proof that the payment happened. The receipt typically binds the amount, the payer and payee identities, and a settlement reference such as a chain transaction or ledger entry.

This is real infrastructure and it matters. Agents that pay each other need a money layer with the same rigor as the rest of the system. But the payment proof is scoped to the money:

It proves a payment for a call settled. It does not prove the call did anything useful.
It records what was charged. It does not record what was computed.
It settles billing disputes. It cannot settle work disputes.

A settled payment for a call that never ran, ran the wrong tool, or returned garbage is a settled payment for nothing. The money layer cannot see the work layer.

What execution receipts cover

An AER-1 execution receipt is minted as the agent works. For each unit of work it records which tool ran, commits the inputs and outputs to SHA-256 hashes, chains the steps so the sequence is fixed, and binds the record to its issuer through provenance. Anyone can re-verify it later with the public algorithm: recompute the hashes, check the chain, confirm the provenance. No account, no permission, no trust in the operator required.

This is scoped to the evidence:

It proves the work ran and the record was not tampered with afterward.
It gives every invoice line a checkable record of the work behind it.
It settles work disputes: did the agent do what was asked, and is the record of it intact?

An execution receipt proves the saved execution record was not changed. It does not prove the model was right, the decision was fair, or the output was true. It is evidence of what ran, not a certificate of correctness.

What it does not do is move money. An execution receipt carries no payment rail and records no settlement. It is the evidence for the invoice, not the payment of it.

Why you need both: the complete transaction

Put the two halves together and a paid agent transaction looks like this:

The agent works. Each tool call mints an execution receipt: what ran, what it touched, what came out, hash-committed and chained.
The work is billed. The metered usage settles through a payment-proof protocol, producing a payment receipt for the charge.
The invoice is complete. Every billed line points at the execution receipt for the work behind it. The client can check the money on the payment rail and the work on the evidence rail, independently.

Now disputes split cleanly. "Was I billed correctly?" goes to the payment proofs. "Did the agent do what I paid for?" goes to the execution receipts. One without the other leaves half of every dispute unanswerable, and the party that cannot answer a dispute loses it.

This is why the two layers are complementary, not competitive. Payment-proof protocols and AER-1 solve adjacent problems in the same transaction: pay for the call, then prove what the call did. A complete agent economy needs a payment rail and an evidence rail, and they are designed to be used together.

AI agent transaction receipt

One transaction, two receipts, two different questions. An AI agent transaction receipt can mean the payment record for agent work (what was paid, to whom, when) or the execution record for the work itself (what ran, what it returned, what was saved). A complete agent transaction needs both, and neither substitutes for the other: the payment receipt settles that money moved, and says nothing about whether the work happened; the verifiable execution receipt proves the saved result was not changed since it was saved, and says nothing about whether anyone paid for it.

Zambo is the verifiable work layer for AI, and it treats the pair as one workflow: the work leaves execution receipts step by step, and the transaction closes against that record. When a dispute comes, you want both documents on the table, each answering the question it is actually able to answer.

Common questions

I already have payment proofs. Why add execution receipts?

Because your payment proofs cannot answer "what did the agent actually do?" The moment a client disputes the work rather than the bill, you need evidence of execution. Execution receipts turn every billed call into a checkable record, which is what makes the invoice defensible.

I already have execution receipts. Why add payment proofs?

Because execution receipts cannot settle billing. When agents pay each other per call, the money layer needs its own proof: amounts, settlement, reconciliation. The execution receipt is the evidence behind the charge; the payment proof is the charge itself.

Do the two receipts need to reference each other?

They can, and cross-referencing strengthens both: a payment receipt can reference the execution receipt it pays for, and an execution receipt can carry evidence references to related records. AER-1 supports hash-committed evidence references to external records, so the link is verifiable rather than just a label. But each receipt verifies on its own; the reference is upside, never a dependency.

How do I start minting execution receipts?

pip install aer1kit for Python, or the aer-1 package on npm for JavaScript and TypeScript. Framework collectors exist for SmolAgents, CrewAI, LangGraph, AutoGen, OpenAI Agents, and more. Verify any receipt at zambo.dev/verify with no account. The format is defined in the IETF Internet-Draft draft-zambo-aer1-23, which is a draft, not a finalized standard.

Where does x402 fit in?

x402 is the payment side of this split in practice: when an endpoint answers a request with an HTTP 402 challenge, the agent pays in USDC on Base and retries with proof of payment. The full walkthrough, with a real challenge captured field by field, is in What is x402? How AI agents pay for API access themselves. The payment proves the payment happened; the execution receipt is the record of the work it bought.