SAR v0.1 Specification

SAR (Settlement Attestation Receipt) defines a deterministic, cryptographically verifiable proof that an agent-delivered task satisfied its settlement specification. Execution, payment, and identity layers do not prove delivery. SAR fills that gap with replay-stable receipts that downstream systems can independently verify without trusting the verifier’s infrastructure.

Request Schema

SAR requests submit task inputs, expected specifications, and observed outputs for deterministic verification.

Public key discovery

Verifier public keys are published at /.well-known/sar-keys.json.

• Resolve verifier_kid to an Ed25519 public key.
• Use that key to verify the receipt signature.

Fixtures (test vectors)

• /spec/sar-v0.1/fixtures/README
• sar-v0.1-pass.json
• sar-v0.1-fail.json
• sar-v0.1-indeterminate.json

• Cross-language verified.
• Canonicalization included.
• Signatures independently verifiable.

Verification algorithm

• Canonicalize the core object using RFC 8785 (JCS).
• SHA-256 hash the canonical bytes to produce receipt_id.
• Fetch verifier public key from /.well-known/sar-keys.json using verifier_kid.
• Verify Ed25519 signature over the SHA-256 hash.

Reason code registry

• PASS
• SPEC_MATCH
• FAIL
• SPEC_MISMATCH
• OUTPUT_ABSENT
• OUTPUT_MALFORMED
• TIMEOUT
• INDETERMINATE
• SPEC_AMBIGUOUS
• EVALUATOR_TIMEOUT
• INTERNAL_ERROR

Unknown codes must be treated as non-fatal.

Extension Semantics

SAR receipts MAY include an optional _ext object for additive metadata.

The _ext object is outside the signed core.

• _ext MUST NOT affect signed-core verification.
• _ext MUST NOT affect receipt_id derivation.
• _ext MUST NOT affect Ed25519 signature verification.
• Unknown _ext fields MUST be ignored by SAR verifiers.

Reserved Extension: _ext.operation_binding

The _ext.operation_binding field is reserved for composition with x402 operation-binding workflows.

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

Field Definitions

• operation_digest — required. SHA-256 digest of the canonicalized operation object.
• schema_id — required. Identifies the schema used for the operation object.
• operation_id — optional identifier.
• resource_url — optional resource endpoint.

SAR Verification vs Cross-Layer Validation

SAR verification and operation-binding validation are separate.

• SAR verifiers MUST verify the signed core.
• SAR verifiers MUST derive receipt_id normally.
• SAR verifiers MUST ignore unsupported _ext fields.

Systems implementing operation-binding MAY recompute operation_digest and compare it with the extension.

Unknown schema_id Behavior

• SAR verification MUST still succeed.
• Cross-layer validation MAY stop or fall back.

Verifier Behavior

• recognized schema_id → verify SAR + optional binding check
• unknown schema_id → verify SAR, skip binding check
• missing extension → verify SAR normally
• unknown unrelated _ext field → ignore

Extension Namespacing

Future _ext extensions SHOULD use namespaced identifiers to avoid collisions.

_ext.operation_binding is reserved for x402 operation-binding composition.

Reference Fixtures

Example fixture set demonstrating SAR ↔ operation-binding composition:

https://gist.github.com/nutstrut/7a0bda88164863a712a25025ad65841b

Rationale

Operation-binding answers: Was this exact operation paid for?

SAR answers: Did execution produce the correct outcome?

Changelog

v0.1 — Initial canonical receipt release

• Deterministic receipt_id
• Ed25519 signatures
• RFC 8785 canonicalization
• Public key discovery
• Fixture vectors published