Architecture

Three-Way Commitment: How Our Stack Binds Payment Intent, Execution Transcript, and Settlement Into One Verifiable Receipt

By IdeaBosqueLast updated: July 30, 2026

Key takeaways

A three-way commitment hashes payment intent, execution transcript digest, and settlement txid into one receipt — an auditor verifies each independently, then confirms the combined hash covers all three — the commitment either covers all steps or it does not; there is no partial coverage (IETF draft-hopley-x402-retention-chain-06, 2026).
Cross-session replay is detected by hash mismatch, not prevented by policy — because binding_ref hashes payment_hash AND action_ref together, swapping a payment from session A with an execution from session B produces a different combined hash; the verifier recomputes and gets a mismatch (x402 GitHub issue #2332, 2026).
MCP modules produce the execution transcript natively — each tool call (vendor compliance screening, supplier lookup, quote drafting) is logged with arguments, results, and timestamps; the transcript digest is action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp})), recomputable by any party holding the four fields (IETF draft-etcheverry-action-ref-02, 2026).
x402 settlement on Base produces payment_hash in ~200ms — the on-chain transaction hash is independently verifiable by querying the Base blockchain; no trust in the operator or facilitator is required (Chainalysis, 2026).
All constructions use SHA-256 and JCS (RFC 8785) — the same canonicalization standard used by the Hermes Agent audit trail (GitHub issue #487), so the execution transcript digest is produced natively by the agent's own audit system, not bolted on.

The problem: auditing each step separately is necessary but not sufficient

The six-protocol agent commerce stack (UCP, A2A, MCP, ACP, AP2, x402) covers discovery, communication, tooling, checkout, authorization, and settlement. Each protocol produces its own evidence: x402 produces a payment hash, MCP produces a tool-call log, AP2 produces an authorization mandate. Auditing each step separately is necessary — you need to verify the payment settled, the execution happened, and the authorization was valid.

But separate audit trails are not sufficient. Without binding, an attacker can mix a real payment from session A with a real execution from session B. Both are genuine artifacts. Neither is forged. But they did not happen in the same session. The payment receipt proves a payment occurred. The execution log proves a screening ran. Without a binding that links them cryptographically, there is no evidence they are the same transaction.

This is the cross-session replay attack: take a genuine payment_hash from a completed transaction and pair it with a genuine action_ref from a different transaction. If the audit system trusts the pairing because both artifacts are valid individually, it accepts a fabricated composite. The binding step is where this attack is detected — or where it is not.

The architecture: how our stack produces each component

The diagram below shows the full three-way commitment flow — which system produces each artifact, how the binding layer composes them, and how the auditor verifies:

How each component is produced in our stack

Payment intent: the x402 signed offer

When the agent calls a paid vendor compliance screening API, the server returns HTTP 402 with a signed offer. The offer-receipt extension (merged into the x402 protocol) commits the server to specific payment terms: amount, asset, payTo address, the exact resource being fulfilled, and a validity window. The offer is signed with EIP-712 (Ethereum wallet-based) or JWS (any asymmetric key, including Solana Ed25519).

The offer is the payment intent — what the agent is about to pay for. The auditor hashes it independently:

offer_hash = SHA-256(JCS(signed offer terms))

The auditor recomputes this from the signed offer terms and verifies the server's signature. No contact with the payment backend is required — the offer is a portable, signed artifact.

Execution transcript: the MCP tool-call log

Our MCP modules connect the agent to vendor compliance APIs, supplier catalogs, and payment rails. Each MCP tool call is logged: which module was invoked, what arguments were passed, what result was returned, at what timestamp, under which policy version. This is the execution transcript.

The Hermes Agent audit trail (GitHub issue #487) implements SHA-256 hash-chained action logging with RFC 8785 (JCS) canonicalization — the same standard that action_ref and binding_ref use. The execution transcript digest is produced natively by the agent's own audit system:

action_ref = SHA-256(JCS({
  agent_id: "procurement-agent-001",
  action_type: "compliance.screen",
  scope: "vendor:acme-corp screening-type:sanctions",
  timestamp: "2026-07-31T19:45:23.482Z"
}))

The auditor recomputes action_ref from these four preimage fields. No contact with the agent or its operator is required. The canonicalization is defined by RFC 8785, not by the serializer — so the hash is deterministic across implementations.

The policy_bound_ref binds the policy version that was in force when the action was executed. If the sanctions list was updated between June and July 2026, the policy hash changes, and the auditor can detect which version was active. The gate_ref binds the ALLOW/DENY verdict from the compliance screening to the policy reference, so the outcome is provably tied to the rule version that produced it.

Settlement: the on-chain txid on Base

The x402 facilitator verifies the agent's signed payment authorization, constructs the on-chain transaction, and broadcasts it on Base. Settlement completes in approximately 200ms. The facilitator returns the transaction hash (payment_hash) to the server, which passes it to the agent in the PAYMENT-RESPONSE header.

The auditor verifies payment_hash by querying the Base blockchain — the txid is a public, immutable record. No trust in the facilitator or the payment backend is required. The auditor confirms:

The transaction exists on Base
The amount matches the offer terms
The payTo address matches the offer
The transaction is confirmed (not pending)

The binding: how binding_ref composes all three

The binding_ref (IETF draft-hopley-x402-retention-chain-06) composes all three hashes into one commitment:

binding_ref = SHA-256(JCS({
  offer_hash,      // what was promised (payment intent)
  action_ref,      // what was executed (MCP transcript digest)
  payment_hash     // what settled (on-chain txid)
}))

This is a three-way commitment. The auditor verifies each component independently:

offer_hash — recompute from the signed offer terms, verify the server signature
action_ref — recompute SHA-256 from the four preimage fields, no contact with the agent
payment_hash — query the Base blockchain, confirm the txid exists and settled

Then the auditor recomputes binding_ref from all three and confirms it matches. If any component is swapped — a payment from session A paired with an execution from session B — the combined hash will not match. The commitment either covers all three steps or it does not. There is no partial coverage.

How cross-session replay is detected

The cross-session replay attack works like this: an attacker takes a genuine payment_hash from a completed transaction in session A and pairs it with a genuine action_ref from a different transaction in session B. Both artifacts are real. Neither is forged. But they did not happen in the same session.

Without binding, the audit system checks payment_hash and action_ref separately, finds both valid, and accepts the composite. The audit trail shows a payment that settled and a screening that ran — but they are from different transactions.

With binding_ref, the auditor recomputes the combined hash from the actual payment_hash and action_ref in the receipt. If the attacker swapped one from a different session, the hashes are from different preimage contexts, and the combined binding_ref will not match the value in the receipt. The verifier detects the mismatch. The commitment does not cover all steps, so it is rejected.

This is what makes the binding step the trust primitive: it does not add new evidence, it links existing evidence cryptographically. Payment hash on Base is verifiable. Execution log is verifiable. Binding proof makes the link between them verifiable. Without the link, each is a standalone claim. With the link, they are one composed receipt that an auditor can verify end to end.

What this means for the build

A procurement agent that screens 85 suppliers per week for compliance needs the three-way commitment in its audit trail. The implementation in our stack:

MCP modules produce the execution transcript. Each tool call is logged with arguments, results, timestamps, and policy version. The transcript digest is action_ref, computed natively by the Hermes Agent audit system using JCS canonicalization.
x402 handles settlement. The facilitator settles on Base and returns payment_hash. The offer-receipt extension signs the payment intent at the 402 response.
The audit layer (not the agent, not the payment backend) computes binding_ref from offer_hash, action_ref, and payment_hash. It also computes policy_bound_ref and gate_ref to bind the policy version and compliance verdict.
The human-in-the-loop checkpoint at payment authorization sees the composed receipt: offer terms, execution result, settlement confirmation, policy version, and verdict — all linked by binding_ref.
An external auditor (regulator, counterparty, internal compliance) verifies the composed receipt by recomputing each hash independently. No contact with the agent, the payment backend, or the audit layer operator is required.

The verification takes seconds: query Base for the txid, recompute action_ref from four fields, recompute offer_hash from the signed terms, recompute binding_ref from all three. The commitment either covers all steps or it does not. That is the primitive that makes agent commerce auditable end to end.