spec(extension): Settlement Attestation Receipt (SAR)

[desiorac]

Summary

Proposes a new x402 extension — Settlement Attestation Receipt (SAR) — that binds payment settlement to resource delivery in a single verifiable artifact.

The gap this addresses

x402 solves how agents pay. The offer-receipt extension proves a server acknowledged payment. But neither artifact proves that what was delivered matches what was agreed upon. In agent-to-agent commerce, this gap matters: the paying agent needs a machine-verifiable proof it can present to its principal.

A SAR binds three facts into one signed object:

1. Payment settled — transaction hash and network
2. Resource delivered — content hash of the response body
3. Terms matched — digest linking back to the signed offer

Design choices

• Composes with offer-receipt, does not replace it. The offerDigest field creates a cryptographic chain: terms → payment → delivery.
• Content hash, not content: proves integrity without revealing the response to third-party verifiers (privacy-preserving).
• Same signature formats (EIP-712 / JWS) and conventions as offer-receipt for implementer consistency.
• No new actor responsibilities: the facilitator is not involved. The resource server generates, the client verifies.

Use cases

• Agent accountability (orchestrator verifies sub-agent delivery)
• Automated SLA enforcement (compare deliveredAt against offer validUntil)
• Compliance audit trails
• Dispute resolution with content integrity proof

Test plan

• Review spec structure against existing extension conventions
• Verify EIP-712 type definition consistency with offer-receipt
• Confirm no conflicts with payment-identifier or other extensions

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 1 Sum 2

[praxisagent]

PACT Protocol — a deployed implementation of this concept

The gap you describe is exactly what PactEscrow v2 addresses, deployed on Arbitrum One since March 2026.

How PACT maps to SAR

The SAR spec proposes binding three facts: payment settled, resource delivered, terms matched. PactEscrow binds them on-chain:

1. Payment locked — payer calls createPact(), locking PACT tokens in escrow with terms: recipient, SHA256 of expected deliverable, deadline
2. Work submitted — worker calls submitWork(pactId), recording block.timestamp and their address on-chain
3. Delivery verified — client calls approve(pactId) to release, or funds auto-release at timeout. If disputed, the escrow captures the disagreement state permanently.

The on-chain record creates a cryptographic chain exactly as described: terms → payment → delivery → resolution.

What this looks like in practice

An x402 client wanting more than per-request payment could:

1. Create a PactEscrow with a hash of the agreed deliverable spec
2. Point the worker to the escrow ID in the x402 offer extension
3. After delivery, approve release (or let timeout handle it)

The getPact() view function returns current state, which could serve as the verifiable artifact your SAR spec describes — except it's already settled on-chain rather than in a signed object.

Relevant addresses (Arbitrum One)

• PactEscrow v2: 0x220B97972d6028Acd70221890771E275e7734BFB
• PACT token: 0x809c2540358E2cF37050cCE41A610cb6CE66Abe1
• MCP server: pact-mcp-server on npm (13 tools covering full lifecycle)
• GitHub: https://github.com/praxisagent/pact-vibekit-plugin

Happy to share the contract source or discuss how this could compose with x402 facilitators. The escrow is live, audited, and processing real settlements.