A paid-resource workflow was recorded. The evidence is a receipt built for public inspection — and the recording is now attributable to DefaultVerifier.

The claim, bounded

What this proves, and what it explicitly does not.

Path A proves recorded delivery evidence. Every clause below is backed by shipped, tested code in attest-service — and every excluded claim is stated so no reader infers more than the receipt supports.

The proof chain

Eight steps from paid request to role-separated receipt.

Each step names the system that performs it and what an independent third party can confirm. Delivery and recording are performed by separate parties — that separation is the load-bearing property.

1. Client ↔ Resource server Request A client requests the paid resource (/pay/url-summary) and receives an x402-style quote. Proves: a paid-resource flow, not a free fetch.
2. Resource server / access layer Access decision The resource server — not DefaultVerifier — decides whether to grant access after payment evidence is presented. Proves: DefaultVerifier did not decide access.
3. Resource server Delivery The resource server delivers the URL summary to the client. DefaultVerifier delivers nothing. Proves: the resource server is the deliverer (acting_party = resource_server).
4. Resource server (fail-open SDK) Evidence emission As a byproduct of delivery, the deliverer emits a delivered-resource descriptor plus a digest of the payload. Emission never blocks delivery. Proves: the delivery evidence originates from the deliverer, not the verifier.
5. DefaultVerifier Receipt recording DefaultVerifier records the evidence as a SAR-402 receipt: verification_mode = record, verification_point = post_delivery. No signing step runs. Proves: verification left evidence; the verifier recorded — it did not deliver, authorize, or execute.
6. SAR Explorer Built for public inspection The receipt is resolvable by receipt_id using the same lookup path the SAR Explorer inspection surface reads — the canonical public_demo receipt is published and publicly resolvable at that URL. Proves: the evidence is structured for public inspection, not private to Default Settlement.
7. Independent third party Payload hash binding A third party re-hashes the delivered payload with the canonical method and compares to delivery.evidence_digest. Proves: the recorded delivered payload was not swapped.
8. Reader, over the receipt Role separation confirmation The reader inspects issuer.verifier (recorder) vs. authority_binding.acting_party (deliverer) and verifier_has_execution_authority = false. Proves: DefaultVerifier could not have fabricated the whole event alone.

Receipt & inspection

One content-addressed ID keys the lookup and the public Explorer URL.

The receipt_id is the inbound integrity.digest — a content hash the resource server computed, adopted (not generated) by DefaultVerifier. The same ID resolves the published canonical record and keys the public SAR Explorer URL — the same receipt shape and lookup path SAR Explorer uses.

Resolving the lookup path returns the published canonical record — resolved by receipt_id: TRUE:

# resolved against the published public receipt surface (testnet)
{
  "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",  // payer-derived, NOT the deliverer
  "receipt": { /* inner SAR-402 settlement payload */ }
}

The agent_id is the payer-derived agent identity, derived from settlement. It is not the deliverer — the deliverer is named by authority_binding.acting_party.

Payload hash binding

The receipt is bound to the actual delivered bytes.

The delivered object carries a delivery_evidence_digest computed by the /pay/url-summary delivery logic: SHA-256 over the canonical delivered object (sorted keys, compact separators), excluding the digest field itself. That value is copied verbatim into the receipt as delivery.evidence_digest. A third party can recompute it and confirm the payload was not swapped.

# 1. Save the delivered payload (section: delivered object) as delivered.json
# 2. Recompute the canonical SHA-256 digest:
import hashlib, json
obj = json.load(open('delivered.json'))
obj.pop('delivery_evidence_digest', None)   # digest excludes itself
canon = json.dumps(obj, sort_keys=True, separators=(',',':'),
                   ensure_ascii=False).encode('utf-8')
print('sha256:' + hashlib.sha256(canon).hexdigest())
# 3. Compare the printed value to delivery.evidence_digest in the receipt.

Role separation

Recorder, deliverer, and payer are three different parties.

DefaultVerifier could not have fabricated the whole event alone: the delivery digest originates from the deliverer, and the receipt structurally separates the recorder from the deliverer. The ingestion endpoint hard-rejects any receipt claiming the verifier holds execution or release authority.

In Path A, issuer.verifier = "DefaultVerifier" is a self-asserted string, not bound to a DefaultVerifier key. Path B adds that cryptographic attribution: a recording signature over the wrapper, verifiable against the published DefaultVerifier recording key (defaultverifier-recording-ed25519-1). Path B attributes recording only — it does not change the role separation above.

Reproduce

A third party confirms it in under ten minutes, trusting no single surface.

Path A reproduction proves inspectability, payload binding, and role separation. No CLI signature verification is part of Path A — that is Path B.

1. Resolve the receipt by its id on the public verifier surface:
   GET /v1/attest/receipt/sha256%3A91e2ae85f03c7a8e7df10e8862895b99456cb13abc50b4e23ba84f1c15b3b8c9
   → confirms the published canonical public_demo record resolves.

2. Open the public Explorer URL:
   https://sarexplorer.com/?receipt_id=sha256%3A91e2…b8c9
   → publicly resolvable; renders the same canonical receipt.

3. Recompute the payload binding:
   drop delivery_evidence_digest, hash the canonical bytes, compare to
   delivery.evidence_digest → match: TRUE.

4. Read the role-separation fields:
   issuer.verifier = DefaultVerifier (recorder);
   acting_party    = resource_server (deliverer);
   verifier_has_execution_authority = false
   → confirms recorder ≠ deliverer, no execution authority.

5. Sanity-check states:
   verification_mode = record · verification_point = post_delivery ·
   settlement_state = delivered · issuer.environment = test
   → post-hoc recorded demo/testnet evidence, not gating, not mainnet finality.

Source artifacts

Where this demo comes from.

The artifact was generated by attest-service and is preserved as a reproducible Path A demo. The canonical public_demo receipt is published and publicly resolvable on SAR Explorer.

Path B · recording attribution

Path B is live: the recording is attributable to DefaultVerifier.

Path C · deterministic conditional release

Path C: a deterministic gate where release depends on a committed acceptance spec.

DefaultVerifier was built around a simple commercial question: did the agent deliver what was specified, and can that be verified before payment, access, or resource release occurs? Path C is that founding thesis now live as a hosted DefaultVerifier endpoint — the deterministic version of the gate, evaluated and publicly verified.

Default Settlement can support evidence-producing gates where release depends on whether submitted output satisfies a declared, deterministic acceptance spec.

The spec is committed through the existing chain — body_digest → request_digest → action_ref — and the evaluator records a result against that action_ref. The following values are publicly retrievable from the live hosted endpoint.

# retrieve the committed evaluation record by action_ref
curl https://defaultverifier.com/v1/evaluate/deterministic/sha256%3Adb0ebf039e7ead24850f23070c950b739d7347caa21bee05fda071d295964e2e

# HTTP/2 200
{
  "result": "PASS",
  "declared_release_intent": "should release",
  "record": {
    "record_type": "deterministic_evaluation_record",
    "..."
  }
}

# retrieve the signed Continuity Evaluation Receipt by action_ref
curl https://defaultverifier.com/v1/evaluate/deterministic/sha256%3Adb0ebf039e7ead24850f23070c950b739d7347caa21bee05fda071d295964e2e/continuity-receipt

# HTTP/2 200
{
  "schema_id": "ds.continuity_evaluation.v0.1",
  "evaluation_state": "PASS",
  "action_ref": "sha256:db0ebf039e7ead24850f23070c950b739d7347caa21bee05fda071d295964e2e",
  "evaluator_id": "agent:defaultverifier:continuity-v1",
  "policy_ref": "policy:default-settlement/sar-402-deterministic-conditional-release-v1",
  "evaluated_at": "2026-06-27T03:12:07Z",
  "signature": {
    "alg": "ed25519",
    "key_id": "agent:defaultverifier:continuity-v1",
    "public_key": "MCowBQYDK2VwAyEArYiQHAFuLxlv/G0VAidYgoj3D+iX9Uk47w7qpWdWPuA="
  }
}

Full verification chain

The whole composition — from request intent to independent verification.

Path A and Path B above describe the SAR-402 delivery receipt and its recording attribution. The architecture now binds that receipt into a longer chain: a committed request intent, signed continuity evaluation records, delivery evidence, and published key material. The Step 2B evaluator key is published in sar-keys.json, and the chain can be independently verified using Default Settlement's published Agent Key Binding Assertion.

The SAR composition chain — Action Commitment, deterministic evaluation, signed Continuity Evaluation Receipt, and SAR delivery evidence — is now publicly inspectable. Signed records can be checked against their published keys, and the chain can be independently verified using Default Settlement's published key-binding assertion, which now covers the new evaluator identity.

1. Client → System Request intent A client requests a paid operation. The request carries the parameters that later records must correspond to. Establishes: the operation that was asked for.
2. SAR Action Commitment Action Commitment (action_ref) The request is canonically bound and a request_digest is derived, producing a stable action_ref join key. This closes the correlation gap between the requested operation and the later verification records. Proves: requested operation and verification records share one binding key. Does not prove execution correctness.
3. Continuity evaluator Continuity Evaluation Receipt A signed evaluator record returns PASS, FAIL, INDETERMINATE (evaluator completed but returned uncertainty), or EVALUATOR_TIMEOUT (evaluator did not complete). Proves: an evaluator reached — or could not reach — a continuity judgment, and signed it.
4. Executor Execution Outcome Receipt A signed executor record reports the outcome of the operation. A missing Execution Outcome Receipt is a verifier finding — an audit gap — not an outcome state. Proves: the executor recorded and signed an outcome. Absence is surfaced as a gap, not silently passed.
5. Resource server SAR delivery evidence The SAR-402 delivery receipt described in Path A: payload-bound, role-separated, recorded by DefaultVerifier, and — under Path B — attributable to a DefaultVerifier recording key. Proves: recorded delivery evidence, bound to the delivered bytes.
6. Agent Key Binding Assertion Agent key binding Published bindings map public identities to trusted Ed25519 keys, including agent:defaultverifier:continuity-v1. The binding assertion covers the Step 2B evaluator key published in sar-keys.json under the production publication key. Proves: which public key each signature should verify against. Does not prove agent correctness — a valid signature attests authorship, not that the agent behaved correctly.
7. Independent verifier Independent verification Using the shared canonical primitives — canonical JSON, SHA-256 digests, and the Ed25519 signing envelope — a third party re-derives each digest and checks each signature against the bound keys, joining the records on action_ref. Proves: the chain composes and verifies end to end, with each claim checked against its own evidence and explicit trust source.

Two live documents make this independently checkable. The publication key signs Default Settlement's published assertions; the agent key bindings map public identities to their trusted Ed25519 keys.