Trust & Safety · The verification hole

Why can’t a receipt prove I got what I paid for?

Because today’s receipts are payment receipts. A cryptographic receipt proves that money moved from buyer to seller. It proves nothing about what came back. That gap — payment provable, delivery not — is the verification hole. Every purchase in the growing agent economy crosses it.

What does a receipt actually prove?

It proves settlement: this buyer paid this seller this amount, and the payment is final. On stablecoin rails the payment is an on-chain record — anyone can look it up on the public ledger. That half of the purchase is genuinely checkable, by anyone, forever.

Now the other half. OTTO, our example AI agent, pays $0.01 for one page of text extraction. If the seller returns perfect text, the receipt looks one way. If the seller returns garbage — or nothing — the receipt looks exactly the same.

No human watches these purchases. That is the point of them. But it also means nobody’s eyes close the gap between “paid” and “delivered.” The full paper chain, and where it holds, is walked through in How trust works.

What happens when a purchase goes wrong?

The dispute has almost nothing to stand on. The buyer can prove payment. The seller can claim delivery. Neither side can prove the middle — what was actually done. One contributor in the x402 standards discussions put it in three sentences:

“Mandate / budget proves may spend. Settlement proves funds moved. Without a recomputable join to what ran, disputes collapse to screenshots.”

Unpack it. The mandate proves the agent was allowed to spend. The settlement proves the money moved. But there is no signed record of the work itself — so a complaint comes down to screenshots: one side’s word against the other’s.

This is not one rail’s flaw. Card rails ship a built-in dispute process, including the chargeback — but that process still has to weigh evidence, and the delivery evidence is what’s missing. Stablecoin settlement is final by design, so any dispute process must be built on top — and it hits the same wall.

Do the people building the rails see this hole?

Yes, and they say so in public. The clearest statements sit in the x402 protocol’s own repository, in open discussion threads anyone can read.

Thread #2332, “Post-settlement accountability layer,” opened 2026-05-15 and still open as of 2026-09-02, states the problem in its first lines: the settlement proof “proves the payment completed” — and then lists what it does not prove. What the agent did after being paid. Whether the record of that action was altered later. Whether the agent stayed inside its authorized scope.

Thread #2648, “Recomputable mapping,” is where the quote above comes from. Its contributors are working on exactly the missing piece: binding a settled payment to a signed record of the work it paid for.

These are discussion threads, not finished standards. We cite them because they show the builders naming the hole themselves — this page is not our opinion against the industry’s.

What would close the hole?

A receipt bound to the action. Today’s receipt names the money. A closing receipt would also name the work: which request ran, what came back, signed by the seller, and tied to the payment — so that software can re-derive the connection instead of trusting anyone’s logs. That last property is what this site calls recomputable.

The everyday version: a bank statement versus an itemized receipt. A statement line proves you paid the hardware store. The itemized receipt proves you bought tile. The agent economy runs on statement lines. It needs itemized receipts.

Concretely, three records would be joined: the permission (what the agent was allowed to buy), the payment (what settled), and a signed record of what ran (what the seller says it delivered). Joined, any third party could check a purchase end to end — without access to either side’s infrastructure.

Drafts of this exist. Offer-receipt staples the seller’s promise to its receipt — though the delivery confirmation is still the seller’s own signature, a step forward rather than independent proof. SEP-2828 proposes signed execution records and continues as a draft at the IETF. None is finished, and none has won. All of them, with status and links: the standards tracker.

What can you do while it stays open?

Read receipts for what they are: proof of payment, nothing more. A seller’s claims about delivery or quality need their own evidence.

Check sellers before money moves, not after. The failure-modes page shows the patterns that exploit the hole; the seller checklist is the practical version you can run with public data.

And hold us to the same standard. “Verified” on this site means verified payments — public chain data can prove money moved, and cannot prove the work was good. Our numbers will claim the first and never the second. The bar is written down in the methodology.

Where are the primary sources?

• Read x402 discussion #2332 — “Post-settlement accountability layer: tamper-evident proof of agent action after payment.” Opened 2026-05-15; open as of 2026-09-02.
• Read x402 discussion #2648 — “Recomputable mapping: binding an x402 settlement to a signed execution receipt.” Quoted comment dated 2026-07-26.
• Read the offer-receipt extension — draft x402 extension, version 0.6.
• Read the IETF draft continuing SEP-2828 — signed execution records, in progress.