Integrate SAR in an afternoon.

A receipt for what was delivered, recorded after the fact.

A Settlement Attestation Receipt records delivery evidence after work or a resource has been delivered. It is a structured object — not a log line — that binds a delivered payload to the request it answered, names the acting_party that delivered it, and states the authority boundary under which it was recorded.

Three things it is deliberately not:

• Not a payment railIt does not replace how you get paid.Your payment rail proves value moved. SAR sits alongside it and records delivery evidence. The two are independent.
• Not a gateEmission never blocks delivery.A receipt is produced as a byproduct of delivery. If receipt emission fails, delivery still happened; you simply have weaker evidence of it.
• A structured receiptIt gives the payer or verifier something to inspect.Instead of trusting a 200 response and a private log, a third party can resolve the receipt by receipt_id, recompute the payload binding, and read the authority boundary.

A 200 and a payment success are not evidence of delivery.

Two systems can both report success and still leave a gap that neither side can settle later:

Deliver first. Emit the receipt as a byproduct.

The integration seam is after your delivery logic runs. You add one step: emit a SAR payload describing what you just delivered, then submit it so DefaultVerifier can record and resolve it.

• Resource serverReceive request / payment contextYour service receives the request and whatever payment/settlement context your rail provides. Nothing about SAR changes this.
• Resource serverDeliver the resource or workYou deliver exactly as you do today. This is the load-bearing step and SAR never sits in front of it.
• Resource serverEmit the SAR payloadAs a byproduct, build a payload with: the request binding, delivery evidence (a payload hash), the acting_party, the authority boundary, and an integrity block.
• DefaultVerifierRecord and resolve the receiptDefaultVerifier records the receipt and makes it resolvable by receipt_id. It records evidence — it does not deliver, move funds, authorize access, or control release.

Pick how far you want receipts to reach.

You can adopt SAR at whatever depth fits. These postures are additive — most partners start at the first.

• Posture AReceipts as your recordEmit receipts purely for inspection and replay. When a delivery is later disputed or audited, you point at a resolvable receipt instead of a private log. Lowest-commitment starting point.
• Posture BReceipts as your gateA downstream system in your own control checks the recorded evidence before it continues its next step. The check is yours — DefaultVerifier records and resolves; it does not authorize or control that downstream release.
• Posture CReceipts as future trust historyOver time, receipts accumulate into a track record for an agent or resource server. This is a direction of travel, not a shipped scoring product — treat it as future work.

A real, abbreviated receipt — not a fictional schema.

Below is a minimal excerpt from the SAR-402 public_demo payload. Every field shown is a real field from the current demo receipt; fields have been removed for brevity, not invented. The JSON is valid — nothing has been added inside it that the receipt does not carry.

{
  "receipt_id": "sha256:91e2ae85f03c7a8e7df10e8862895b99456cb13abc50b4e23ba84f1c15b3b8c9",
  "receipt_type": "sar_402_settlement",
  "receipt_context": "public_demo",
  "created_at": "2026-06-23T17:01:58Z",
  "agent_id": "agent:x402:eip155:84532:0xPAYER0000000000000000000000000000000002",
  "receipt": {
    "issuer": { "verifier": "DefaultVerifier" },
    "authority_binding": {
      "acting_party": "resource_server",
      "verifier_has_execution_authority": false,
      "verifier_controls_resource_release": false,
      "resource_server_controls_delivery": true
    },
    "delivery": {
      "evidence_digest": "sha256:ea24c8369b31816546e07644b3621831d2e8d780e527ccb0c9fd26471dd2a8c6"
    },
    "verification_mode": "record",
    "verification_point": "post_delivery"
  }
}

Fields omitted for brevity include the inner request/operation-binding block and other settlement metadata carried by the full receipt. agent_id is the payer-derived identity — not the deliverer; the deliverer is named by authority_binding.acting_party. For recomputation, work from the full published payload, not this excerpt — see the links section.

Resolving a receipt and recomputing its id are two different checks.

Depending on the fixture and path, the receipt_id may be computable from the original payload preimage: canonicalize the payload preimage using the derivation rule for that path (for the SAR-402 Path A demo: sorted_keys_compact_v0 applied to payload_without_integrity), SHA-256 the canonical bytes, and you get the receipt_id. That is the recomputability property — but it is a property of the payload file plus the derivation rule, not of every response body.

Practical consequence: if you want to claim recomputability for your receipts, preserve the original payload preimage (or fixture) you derived the id from. Without it, you can still resolve the receipt, but a third party cannot independently re-derive the id.

Attribution over a receipt, without touching the receipt.

In Path A, issuer.verifier = "DefaultVerifier" is a self-asserted string. The recording wrapper (Path B) adds cryptographic recording attribution: DefaultVerifier signs a wrapper over the receipt so a third party can confirm DefaultVerifier — not the submitter alone — recorded it.

PASS, FAIL, and INDETERMINATE.

A SAR verification resolves to one of three outcomes. The third one is a feature.

The authority boundary, stated plainly.

Reading a SAR receipt correctly means reading the boundary. DefaultVerifier is a recorder and resolver of evidence — nothing in this integration hands it your delivery, your funds, or your access control.

The afternoon, step by step.

1. Decide the delivery event that creates a receipt — the seam right after your delivery logic succeeds.
2. Define the request binding — how the receipt references the request/operation it answered.
3. Define the payload / evidence hash — a canonical digest of the delivered object (sorted keys, compact separators, excluding the digest field itself).
4. Identify the acting_party — the deliverer, i.e. your resource server. Keep it distinct from the recorder.
5. Add authority boundary fields — verifier_has_execution_authority = false, verifier_controls_resource_release = false, resource_server_controls_delivery = true.
6. Emit the SAR payload as a byproduct of delivery — never gating it.
7. Submit / record with the verifier so the receipt is recorded and resolvable.
8. Test resolver lookup — GET /v1/attest/receipt/{receipt_id} returns your record.
9. Inspect in Explorer — open the receipt and confirm role separation and the payload binding read as expected.
10. Preserve the fixture / preimage if you intend to claim recomputability of the receipt_id.

Everything here is publicly resolvable.