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

Verdict	Code	Meaning
PASS	SPEC_MATCH	Output satisfies spec
PASS	SPEC_MATCH_PARTIAL	Satisfies spec within confidence threshold
FAIL	SPEC_MISMATCH	Output does not satisfy spec
FAIL	OUTPUT_ABSENT	No output produced
FAIL	OUTPUT_MALFORMED	Output unparseable against spec schema
FAIL	TIMEOUT	Output not produced within spec time window
FAIL	SPEC_INVALID	Spec itself malformed or unevaluable
INDETERMINATE	SPEC_AMBIGUOUS	Spec does not define clear success criteria
INDETERMINATE	EVALUATOR_TIMEOUT	Verifier did not complete within SLA
INDETERMINATE	CONFLICT	Multiple 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.

1Parse the receipt JSON
2Extract the six core fields: task_id_hash, verdict, confidence, reason_code, ts, verifier_kid
3JCS-canonicalize the core object (RFC 8785 — JSON Canonicalization Scheme)
4SHA-256 hash the canonical byte stream. Confirm hex matches receipt_id after removing the sha256: prefix
5Resolve verifier_kid via GET /.well-known/sar-keys.json
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 →

Extension semantics

SAR receipts MAY include an optional _ext object for additive metadata. Extension data is outside the signed core.

_ext MUST NOT affect signed-core verification. The six core fields and only those fields determine receipt_id and signature validity.

_ext MUST NOT affect receipt_id derivation. Adding, modifying, or removing _ext data produces no change to the deterministic receipt ID.

_ext MUST NOT affect Ed25519 signature verification. The signature is computed over the SHA-256 hash of the JCS-canonicalized core fields only. Extension data is never included in the signing input.

Unknown _ext fields MUST be ignored by SAR verifiers. A verifier encountering an unrecognized extension namespace must complete SAR verification normally.

Extension namespaces SHOULD use namespaced identifiers to avoid collisions between independent extension authors.

The _perf field follows the same isolation rules — it carries optional performance metadata and is excluded from the signed core.

Reserved extension: operation_binding

The _ext.operation_binding field is reserved for composition with operation-binding workflows. It allows a SAR receipt to reference the specific operation that was paid for, without affecting delivery attestation.

operation_binding extension

{
  "_ext": {
    "operation_binding": {
      "operation_digest": "sha256:...",
      "schema_id": "x402-operation-binding/v1",
      "operation_id": "...",
      "resource_url": "..."
    }
  }
}

Field	Required	Description
operation_digest	Yes	SHA-256 digest of the canonicalized operation object
schema_id	Yes	Identifies the schema used for the operation object
operation_id	No	Optional operation identifier
resource_url	No	Optional resource endpoint

Systems implementing operation-binding MAY recompute operation_digest from the canonicalized operation object and compare it with the extension value. This check is cross-layer validation, not SAR verification.

Verifier behavior

SAR verification and cross-layer validation are separate concerns. SAR verifiers MUST verify the signed core and MUST derive receipt_id normally, regardless of extension content.

Condition	SAR verification	Cross-layer validation
Recognized `schema_id`	Verify signed core	MAY validate operation binding
Unknown `schema_id`	Verify signed core	MAY skip or fall back
Missing `_ext` entirely	Verify signed core	Not applicable
Unknown unrelated `_ext` field	Verify signed core, ignore field	Not applicable

This separation ensures that SAR receipts remain independently verifiable even as new extension namespaces are introduced. A receipt is valid or invalid based solely on its signed core — never on extension content.

Implementations

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