Settlement Without Execution Proof Is a Paid Black Box: Closing the Agent Payment Audit Loop

Key takeaways

• x402 processed 169 million agent payments on Base in its first year, but payment_hash proves only that a transaction settled — not what the agent did — the receipt extension (OMA3/x402, merged into the protocol) records who paid, what service, when, and a payment reference, but not which screening version, policy rule, or model version ran on the server side (Chainalysis, 2026; OMA3, 2026).
• The IETF action_ref draft (draft-etcheverry-action-ref-02, July 2026) defines a content-addressed identifier — SHA-256 over canonical JSON of agent_id, action_type, scope, timestamp — that any auditor recomputes without trusting the emitter — with optional fields for policy-version auditability, so an auditor can determine not just that rule 7 fired, but which version of rule 7 was active at that moment.
• The IETF x402-retention-chain draft (draft-hopley-x402-retention-chain-06, June 2026) formalizes the composition: a Settlement-Action Binding (binding_ref) binds payment_hash to action_ref in one receipt — plus a Policy Binding (policy_bound_ref) that binds the governing policy version to the action, and a Compliance Gate Binding (gate_ref) that binds an ALLOW/REFER/DENY verdict to the policy reference.
• All constructions use only SHA-256 and JCS (RFC 8785), verifiable by any party holding the receipts without contacting the issuer — satisfying MiCA Article 80, DORA Article 14, and AMLR Article 56 audit trail requirements (IETF draft-hopley-x402-retention-chain-06, 2026).
• Settlement without execution proof is a paid black box; execution proof without settlement is an unverifiable claim; agents need both to close the trust loop — x402 settles the exchange, action_ref binds the execution context, and binding_ref composes them into one auditable receipt.

The problem: six protocols, zero execution receipts

The agent commerce stack converged in 2026: UCP (discovery), A2A (communication), MCP (tooling), ACP (checkout), AP2 (authorization), x402 (settlement). Six layers, sixty-plus launch partners — Google, Shopify, OpenAI, Stripe, Visa, Coinbase. Every purchase is covered: the agent discovers, negotiates, uses tools, checks out, gets authorized, and pays.

Except one thing: proof that the agent actually did what it was supposed to do.

x402 settles the payment. The payment_hash proves the transaction completed on Base in approximately 200ms. The x402 receipt extension (merged into the protocol via the OMA3/x402 collaboration) adds a signed, portable proof of purchase — who paid, what service was accessed, when, and a payment reference. This receipt is digitally signed by the service, tamper-proof, and universally verifiable.

It does not record what happened inside the service. The receipt proves the agent paid. It does not prove which screening version ran, which policy rule fired, or which model version produced the decision. For a vendor compliance check, the receipt proves the agent paid for the screening API call. It does not prove which version of the screening logic actually executed.

For regulated procurement — EU AI Act Article 12 enforcement August 2, 2026, FCA SYSC 9.1, SOC 2 CC7.x — that gap is the compliance blocker. Logs can be rewritten. A payment receipt that does not bind to execution is a paid black box.

The fix: two IETF drafts that compose settlement and execution

action_ref — content-addressed execution identity

The IETF action_ref draft (draft-etcheverry-action-ref-02, July 23, 2026) defines a deterministic, content-addressed identifier for agent actions. The identifier is computed as:

action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp}))

Where JCS is the JSON Canonicalization Scheme (RFC 8785), which produces a unique byte sequence for any JSON value. The four preimage fields:

Field	What it captures
agent_id	The terminal executor after delegation resolution (in a chain A→B→C, agent_id is C)
action_type	Semantic label (payment.send, compliance.screen, oracle.signal)
scope	The agent's requested-intent scope at the point of action
timestamp	RFC 3339 UTC with exactly 3 millisecond digits

The design goal is operator-independence: a verifier holding the four fields can recompute action_ref without calling the emitter's infrastructure. The draft includes optional fields for policy rotation auditability — so an auditor can determine not just that rule 7 fired, but which version of rule 7 was active at that moment.

x402-retention-chain — the binding layer

The IETF x402-retention-chain draft (draft-hopley-x402-retention-chain-06, June 24, 2026) defines seven cryptographic constructions. Three are directly relevant to the payment → settlement → audit loop:

1. Settlement-Action Binding (binding_ref) — binds the x402 payment_hash to the action_ref in one receipt. A settlement attestation now proves not only that a payment occurred but which verified agent action it corresponds to. An auditor holding the receipt follows the chain from payment_hash to action_ref to the action record, confirming both without contacting the issuer.

2. Policy Binding (policy_bound_ref) — binds a content-addressed snapshot of the governing policy to the action. A screening decision is verifiable against the exact policy version in force when it was made. A policy rotation is detectable by recomputation — the hash changes when the policy changes, so the auditor sees the transition.

3. Compliance Gate Binding (gate_ref) — binds an ALLOW/REFER/DENY compliance verdict and a no-PII payer reference to the policy reference. The screening outcome is provably tied to the rule version that produced it, with no personal data in the bound record.

All constructions use only SHA-256 and JCS. No external infrastructure required. No contact with the issuer. Any party holding the receipts can verify.

The audit loop: payment → settlement → auditable logs

The complete loop for a regulated agent commerce transaction:

1. Payment — the agent calls a paid API (vendor compliance screening, supplier verification, product lookup). The server returns HTTP 402 with payment terms.

2. Settlement — the agent signs an authorization, retries with PAYMENT-SIGNATURE, the facilitator verifies and settles on Base in approximately 200ms. The server returns the resource with a settlement receipt containing payment_hash.

3. Execution — the agent performs the action (screening, lookup, decision). It emits action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp})) — a content-addressed identifier any third party can recompute from the four preimage fields.

4. Binding — the binding_ref links payment_hash to action_ref in one receipt. The policy_bound_ref links the governing policy version to the action. The gate_ref links the compliance verdict to the policy reference.

5. Audit — an auditor (regulator, counterparty, internal compliance) holds the composed receipt. They recompute action_ref from the four fields. They verify payment_hash against the Base blockchain. They check policy_bound_ref to confirm the screening ran under the correct policy version. They check gate_ref to confirm the verdict matches. No call to the operator. No trust required.

The loop answers: payment settled, this specific screening version ran, under this policy version, at this timestamp, with this verdict. Two layers, one receipt.

Why each layer alone fails

The diagram below shows the full loop — payment, settlement, execution, binding, and audit — and why each layer alone is insufficient:

Settlement without execution proof is a paid black box. The receipt says the agent paid for a compliance screening. It does not say which version of the screening logic ran, whether the policy was current, or whether the verdict was correct. A regulator asking "did you screen this vendor against the July 2026 sanctions list or the June 2026 list?" gets no answer from payment_hash alone.

Execution proof without settlement is an unverifiable claim. The agent says it screened the vendor. Without a payment receipt binding the screening to a settled transaction, there is no economic evidence the screening actually occurred. The claim is free to make and worthless to audit.

The combination closes the trust loop. Settlement anchors the economic event — proof that money moved. Execution proof anchors the semantic event — proof of what was done. The binding links them. An auditor verifies both from one receipt, recomputing hashes without trusting any party in the chain.

What this means for a B2B build

A procurement agent that places orders, authorizes payments, and screens vendors needs the full loop in its audit trail. The architecture:

• x402 handles settlement. The agent encounters a 402 response from the vendor compliance API, pays in USDC on Base, and receives a settlement receipt with payment_hash.
• action_ref handles execution identity. The agent emits action_ref for each compliance screening action, recording the agent_id, action_type (compliance.screen), scope (vendor ID and screening type), and timestamp.
• binding_ref composes them. The settlement receipt carries payment_hash and action_ref in one envelope. The policy_bound_ref records which policy version governed the screening. The gate_ref records the ALLOW/DENY verdict.
• The audit trail is the composed receipt chain. An auditor recomputes action_ref from the four fields, verifies payment_hash on-chain, checks the policy version hash, and confirms the verdict — all without contacting the agent operator, the payment facilitator, or the screening service.

For a regulated industry — pharma GMP compliance, aerospace ITAR screening, financial services sanctions checks — this is the difference between an agent that is auditable and an agent that is a compliance liability. The EU AI Act Article 12 record-keeping requirement (enforcement August 2, 2026) requires traceability of AI system decisions. MiCA Article 80 requires transaction records. DORA Article 14 requires audit trails for operational resilience. The binding_ref construction satisfies all three from one receipt.

Related reading

• When the Agent Places the Order: How Agentic Payments Close the B2B Procurement Loop — the procure-to-pay cycle from RFQ to payment reconciliation with agentic payment protocols
• Kill-Switch by Design: Agent Governance Architecture — the governance layer that decides when an agent can act and when it must stop
• Proportional Agent Governance: Why Binary Trust Fails — matching autonomy levels to risk, including the payment authorization checkpoint
• EU AI Act Agent Deployments: Compliance — the Article 12 record-keeping requirement that the audit loop satisfies

---

A mid-market distributor running an agent that screens 85 suppliers per week for compliance needs more than a payment receipt. It needs proof that the screening ran under the correct policy version, at the correct time, with the correct verdict — bound to the payment that funded it. The binding_ref construction composes x402 settlement and action_ref execution into one receipt that any auditor can verify without trusting the operator. That is the audit loop: payment → settlement → auditable logs. Two layers, one receipt, zero trust in the emitter.

Request a scoped build. One-week discovery. You get a system inventory, workflow map, and fixed scope — whether or not you build with us.