Receipt cert_4dww28dx5j

Signature verified just now (current form) — this receipt is genuine.

Whose eyes: this receipt is signed by a party to the sale, so it proves the store issued it with these fields on this date — not that the goods were good. A receipt your agent's own runtime signed is the other party's word about the same purchase. Neither is a disinterested observation; that is a third kind of artifact, and /attestation says which is which.

Item — A Signed Hello

Date — 2026-07-22

Paid — Free shelf — no payment moved

Patron number — #1

For — First Customer

Certificate id — cert_4dww28dx5j

Verify this yourself

Checked on this load, not asserted. Each line is a separate question; they mean different things, and none of them is folded into the line above.

• Record found in this store's book under cert_4dww28dx5j.
• Artifact hash 184f937e87d0a6ba881ea0bc6523890a6994f6566c58e561e2e931721e469eb6 (sha256 of the exact signed bytes; the anchored digest matches the bytes served now).
• Signature valid (ed25519, current form) under a key this store retired on 2026-07-31. Signed with a key this store used to publish and has since retired. That is expected on an artifact issued before the handover — and whether THIS artifact was is not left to reassurance: its own date is checked against the key's published service window and the verdict reported beside this field as service_window. Inside the window, retirement does not weaken the signature: the key remains published in key_history precisely so artifacts signed under it stay attributable to this store, and the handover itself is signed by the retiring key and verifiable at its own URL. Dated AFTER the window, the artifact is the exact shape a stolen retired key produces, and service_window says so in those words.
• Interop signature (RFC 8785) — absent (minted before this store emitted a second, canonical-JSON signature beside the primary one; history, not a defect).
• Existed by Bitcoin block 965720 (mined 2026-09-06) Signed by a key that was once current; issue time UNPROVEN. The earliest block bounding these bytes is 965720 (mined 2026-09-06, per https://blockstream.info), after the key retired on 2026-07-31. This is the shape of every receipt anchored on backfill AND the shape a stolen retired key produces, and the artifact alone cannot tell them apart. The date on the certificate does not resolve it: it is the signer's claim.

Where this sale stands

Derived on this load from the signed fields above and the delivery-audit row for the settlement, never stored beside the receipt.

• Payment — no payment recorded.
• Order of operations — settled then delivered since 2026-08-10 the goods are produced first and the money moves at the last line before the signature; a delivery that fails takes nothing.
• Delivery audit — not applicable (No on-chain settlement is named on this certificate, so no delivery-audit row was ever keyed to it: the free shelf, a trade-account sale the marketplace collected, or a settle that returned no transaction hash.).
• Failed attempts on this receipt — none possible (A certificate is minted only after the goods were produced. A delivery that fails before settlement takes no money and mints nothing, so it cannot appear on any receipt — there is nothing to receipt. This record is the delivery. Per-attempt state — payment_state settled | not_settled | unknown, charged, delivery_state, reconciliation_reference — lives on the buyer's purchase journal, opened only by the buyer's own token: GET /api/purchase-status/{purchase_id} with Authorization: Bearer <status_token>, or the check_purchase MCP tool. Both are returned with every purchase response and every decline. The store publishes its own conduct, never a buyer's failed attempts.).

What this does not prove

That the goods were delivered, that they were any good, or that the buyer was who they said. It proves this store issued this certificate, with these fields, on this date.

Stated per artifact class, with what the signature covers and whose word you are taking, at /attestation.

Take it with you

The machine record is this same URL as JSON — the exact signed bytes, the signature, the public key and the anchor proof:

curl -H 'Accept: application/json' https://scvd.store/api/verify/cert_4dww28dx5j

Check it without asking us, against a key you fetch yourself from /.well-known/scvd-signing-key: ed25519_verify(utf8(signed_payload), signature, public_key). Or export everything, Bitcoin proof included, and verify offline:

npx -p x402-verify scvd-evidence export https://scvd.store/api/verify/cert_4dww28dx5j --out ./receipt-cert_4dww28dx5j
npx -p x402-verify scvd-evidence verify ./receipt-cert_4dww28dx5j/bundle.json --public-key <the key you fetched>

Or replay the whole call as an integration test — the signed bytes, the accepted terms and a JWS offer over them, the settlement transaction, the sale's standing, and the refusal body a wrong-scope re-presentation gets — in one signed document: /api/replay/cert_4dww28dx5j.

This page re-checks the ed25519 signature on every load; reload it and the check runs again. Re-verification is free, forever, and answers for anyone, not only whoever bought the thing.

Holding this

A signed receipt from a human-run general store for agents, paid over x402. You own what was bought outright and owe the store nothing for it (/rights). The store: the front · the shelf · what gets read here.

For the format: the developer portal, openapi.json, skill.md, the free preflight and conformance desk, the key at https://scvd.store/.well-known/scvd-signing-key.