Settlement Attestation Receipt (SAR)

A canonical delivery proof format for agentic commerce.

The gap this addresses

x402 solves how agents pay. ERC-8004 addresses who acted. Coinbase Agentic Wallets handle custody and spending policy.

None of these layers prove delivery.

An escrow contract waiting to release funds, a reputation system updating an agent’s score, a DAG orchestrator deciding whether to proceed — all of these need to answer one question before acting:

Did the agent actually deliver what was paid for?

Right now each system that needs this answer either skips the check, rolls its own verification logic, or trusts the agent’s self-report. That’s not a reliable foundation for settlement.

What SAR is

Settlement Attestation Receipt (SAR) is a minimal, open receipt format for delivery attestation in agent commerce.

A SAR receipt is a stateless, deterministic, cryptographically signed artifact that any system can verify offline, without contacting the issuing infrastructure. It answers one question — did the agent deliver what was specified — and produces a portable, replay-stable proof that payment rails, wallets, escrow contracts, reputation systems, and orchestration frameworks can act on independently.

The signed core is exactly six fields: task_id_hash, verdict, confidence, reason_code, ts, and verifier_kid.

Extensions are additive and never affect the signed core or receipt_id derivation.

Design principles

Deterministic. receipt_id = SHA256(JCS(core_fields_bytes)). Any party can recompute the ID from the receipt contents. No trust dependency on the issuing server.

Minimal signed core. The signature covers only the invariant fields. Extension namespaces are additive and never affect receipt validity. Extension namespaces must not alter signed core fields or receipt_id derivation.

Portable. Ed25519 signatures. RFC 8785 — JSON Canonicalization Scheme (JCS). Public key discovery at .well-known/sar-keys.json. Verifiable in any language, on any chain, in any runtime. After initial public key resolution, receipts can be verified indefinitely offline without server interaction.

Non-custodial. SAR receipts are attestation artifacts. The format takes no position on custody, enforcement, or dispute resolution. Downstream systems decide how receipts are used.

Three verdict paths. PASS FAIL INDETERMINATE. The third verdict matters: an evaluator that can’t determine delivery should say so, not collapse uncertainty into a false binary.

The receipt format

SAR Receipt
{
  "receipt_version": "0.1",
  "receipt_id": "sha256: 4a7f3c...",
  "task_id_hash": "sha256: 9b2e1a...",
  "verdict": "PASS",
  "confidence": 0.94,
  "reason_code": "SPEC_MATCH",
  "ts": "2026-02-15T01: 00: 00.000000Z",
  "verifier_kid": "sar-prod-ed25519-01",
  "sig_alg": "Ed25519",
  "sig": "base64url:...",
  "counterparty": "0x...",
  "_perf": {
    "verify_ms": 82,
    "total_ms": 105,
    "spec_bytes": 128,
    "output_bytes": 131
  },
  "_ext": {}
}

The _ext envelope accepts namespaced integration context — x402 payment hashes, ERC-8004 agent DIDs, escrow contract addresses, wallet policy IDs, DAG workflow references — without affecting the signed core or receipt_id.

v0.2 The optional counterparty field supports downstream indexing and relationship graphs. It is not part of the signed payload — deterministic verification is unchanged. Fully backward compatible with v0.1.

Reason code registry

VerdictCodeMeaning
PASSSPEC_MATCHOutput satisfies spec
PASSSPEC_MATCH_PARTIALSatisfies spec within confidence threshold
FAILSPEC_MISMATCHOutput does not satisfy spec
FAILOUTPUT_ABSENTNo output produced
FAILOUTPUT_MALFORMEDOutput unparseable against spec schema
FAILTIMEOUTOutput not produced within spec time window
FAILSPEC_INVALIDSpec itself malformed or unevaluable
INDETERMINATESPEC_AMBIGUOUSSpec does not define clear success criteria
INDETERMINATEEVALUATOR_TIMEOUTVerifier did not complete within SLA
INDETERMINATECONFLICTMultiple evaluation passes produced conflicting verdicts

Reason codes are versioned and extensible. Implementers must treat unknown reason codes as non-fatal.

Verification algorithm

Deterministic. No server contact required after key resolution.

  1. 1Parse the receipt JSON
  2. 2Extract the six core fields: task_id_hash, verdict, confidence, reason_code, ts, verifier_kid
  3. 3JCS-canonicalize the core object (RFC 8785 — JSON Canonicalization Scheme)
  4. 4SHA-256 hash the canonical byte stream. Confirm hex matches receipt_id after removing the sha256: prefix
  5. 5Resolve verifier_kid via GET /.well-known/sar-keys.json
  6. 6Verify sig (Ed25519) against the SHA-256 bytes using the resolved public key

Keys are published at a stable well-known endpoint and can be cached. After initial resolution, receipts can be verified indefinitely offline.

Interactive verification walkthrough →

Implementations

SAR is designed to be implementable from this document alone. Independent implementations have validated the specification across all three verdict paths.