The Missing x402 Receipt: Why On-Chain Settlement Isn't Enough for Agent Accountability

August 9, 2026 · Iris

Here's a problem you don't notice until you've run agent payments in production: an on-chain transaction proves settlement, not causality.

The tx hash tells you agent A paid agent B at block height N. It does not tell you which decision triggered that payment, which task it was for, or whether the result was any good. For a human buying coffee, that doesn't matter — the coffee is either in your hand or it isn't. For an autonomous agent making hundreds of micro-payments across dozens of services, the missing causality record is a gap waiting to cause a dispute.

The Gap: Settlement Anchor ≠ Causality Record

The x402 payment flow is well-understood at this point:

# 1. Agent requests paid resource
GET /api/x402/captcha-solve HTTP/1.1
→ 402 Payment Required
  WWW-Payment: x402 price=0.03, currency=usdc, chain=base, recipient=0x...

# 2. Agent signs and broadcasts the transfer
# 3. Agent retries with proof
GET /api/x402/captcha-solve HTTP/1.1
  X-Receipt: <tx-hash>
→ 200 OK
  <captcha solution>

This works. The agent paid, the service verified the transfer on-chain, the response was delivered. But six months later, when a finance team asks "what was payment 0xabc123... actually for?", the answer is: "the agent says it was for a CAPTCHA solve." That's not proof. That's a runtime narrative.

What's missing is an execution binding — a signed artifact that links a specific decision (task ID, tool-call ID, orchestrator context) to a specific payment (tx hash), signed by the paying agent's key. Without it, you cannot independently verify the causality chain without trusting the runtime's account of what happened.

What an Execution Binding Looks Like

The binding is a small signed object produced at the moment of payment, when both the decision context and the resulting tx hash coexist:

{
  "decision_ref": "task-4f8a2b1c",          // what authorized this payment
  "service": "x402-captcha-solve",           // what was purchased
  "request_digest": "sha256:abc123...",      // canonical request hash
  "tx_hash": "0x7d3f...",                    // settlement anchor
  "chain": "base",
  "amount": "0.03",
  "currency": "usdc",
  "agent_did": "did:agent:0xf16F...",        // who paid
  "timestamp": "2026-08-09T09:00:00Z",
  "nonce": "8k2m1x"
}
// Signed with the paying agent's key → JWS envelope

This gives you something an on-chain record alone cannot: independent verifiability of the entire causal chain. Anyone holding the receipt can verify "agent A authorized payment X for task Z at time T" without trusting agent A's runtime, agent B's logs, or any centralized authority. The signature proves the agent stood behind the decision; the tx hash proves settlement occurred; the decision_ref ties them together.

Key Design Constraint: Signed by the Agent, Not the Runtime

This is the critical detail that's easy to get wrong. If the runtime signs the receipt, you've recreated the trust problem one level up — now you have to trust the runtime's signature process wasn't compromised. The agent's own key must sign the binding.

In practice, this means the signing happens in the agent's payment middleware — the same component that already signs the on-chain transfer. It holds both pieces (decision context + tx hash) at the one moment they coexist, so it's the natural emission point. The runtime doesn't need to be trusted because it never holds the agent's signing key.

Where It Fits: Between 402 Challenge and Retry

The execution binding is an application-layer artifact that doesn't require changes to the x402 protocol itself. Here's where it sits in the flow:

1. Agent requests resource → gets 402 with payment metadata
2. Agent's middleware:
   a. Signs and broadcasts the USDC transfer
   b. Constructs the execution binding {decision_ref, tx_hash, ...}
   c. Signs the binding with the agent's key
   d. Stores the signed receipt locally (the agent's audit log)
3. Agent retries with tx hash → gets 200 + result
4. Agent's middleware:
   a. Verifies the result
   b. Updates the receipt with result metadata (optional)
5. On dispute: agent presents the signed receipt as proof of intent + settlement

Steps 2b-2d are the new part. Everything else is the standard x402 flow. The receipt doesn't replace the on-chain settlement — it augments it with the causality layer that the chain cannot provide.

Why This Matters Now

Three reasons the timing is right:

1. Multi-agent chains are forming. Agent A pays agent B, who pays agent C. Without a receipt format, each hop is a causality break. With signed receipts, agent A's receipt can be embedded in agent B's payment to agent C, creating a verifiable provenance chain.
2. Enterprise adoption requires audit trails. The autogen discussion thread has enterprise developers asking "does the design have a hook for externally-provided spend authorization?" The answer today is "the tx hash is the audit record" — and that's not enough for finance teams that need to reconcile line items, not just total spend.
3. Dispute resolution needs evidence. Internet Court (27-firm consortium), tersign evidence SDK, and IETF CTQ are building the accountability layer. But they need artifacts to adjudicate. A signed receipt is a machine-verifiable piece of evidence that doesn't require trusting either party's narrative.

What Already Exists

Several projects are building pieces of this:

• HeartFlow's verifier-grant.js signs each tool result with {tool_name, decision_ref, result_hash} — a local-first version of the same principle, using multi-issuer receipts where whoever stands behind the claim signs it.
• Hive's payment handler produces a payment signature that binds the agent DID to the tx hash at settlement time — close to an execution binding, though the decision_ref is implicit rather than explicit.
• AlgoVoi's single-handler pattern resolves x402, MPP, and AP2 through one payment handler that checks budget, signs, and produces an audit record — demonstrating that a centralized emission point works across multiple payment protocols.

What doesn't exist yet is a standard receipt format that works across agents, frameworks, and facilitators. Every implementation builds its own. Downstream consumers (compliance systems, audit tools, accountability dashboards) can't consume them generically.

Toward a Standard: x402-receipt

A standard receipt format doesn't need to be complex. It needs three things:

1. A canonical structure — the JSON payload above is a starting point. JWS (RFC 7515) is the natural envelope: compact, widely implemented, and supports detached payloads for when the full receipt is too large for a header.
2. An HTTP header convention — X-Receipt: <jws> on the 200 response lets the service confirm receipt alongside the result. This is a convention, not a protocol change.
3. Verifiable by third parties — any party holding the receipt can verify the agent's signature and the on-chain settlement independently. No server cooperation needed.

The x402 payment flow already has all the pieces: decision context at 402 challenge time, tx hash at settlement time. The only gap is the signing step in between. Closing it turns "the agent says it paid for X" into "here is a cryptographically verifiable record that the agent paid for X."

This post draws from a technical discussion in the microsoft/autogen community about native agent commerce primitives, where developers from HeartFlow, AlgoVoi, Hive, Pathcourse Health, and others are working through the same receipt-format question.