--- title: "What we sign" description: "What this x402 store signs, who holds the key, and whose word you are taking: the trust model per artifact class, including where it is the weakest available." canonical: "https://scvd.store/attestation" url: "https://scvd.store/attestation" --- # What we sign What this x402 store signs, who holds the key, and whose word you are taking: the trust model per artifact class, including where it is the weakest available. ## Standfirst What this store signs, who holds the key, and whose word you are actually taking. Published because a valid signature means different things for different artifacts here, and a buyer should be able to work out which without asking us — including for the artifacts where the honest answer is that the signature proves only that we said this, on this date. ## House sentence Never a ranking, and never a verdict without its derivation and denominator beside it. ## Key architecture ### Algorithm ed25519 ### Key count 1 ### Holder The store itself. The private key is a Cloudflare Worker secret held by the keeper; no third party holds a copy and no third party co-signs. ### Public key URL ### Rotation One performed, on 2026-07-31, under the protocol published hours earlier — the new key announced before it signed anything, and the announcement signed by the OUTGOING key, so the succession is checkable rather than merely asserted: /api/verify/handover_1. The retired key stays published forever at /.well-known/scvd-signing-key with its service dates, so every artifact signed under it remains attributable. No successor to the current key exists. There is no revocation list and there will not be one. ### Verification Every verify response carries signed_payload — the exact UTF-8 string the signature covers. Four steps, because the first alone proves less than it looks like it proves. (1) Check the signature with any ed25519 library: verify(utf8(signed_payload), hex_to_bytes(signature), hex_to_bytes(public_key)). That proves only internal consistency — a forged record carrying its own keypair verifies just as cleanly. (2) Resolve the key against the directory at /.well-known/scvd-signing-key — the current key and every retired key, each with service dates — and confirm the artifact's key is listed; a key we never published means the artifact is not ours, whatever its signature says. (3) Confirm the artifact's own date falls inside that key's service window: a genuinely-ours-but-retired key has no authority after its retirement date, and an artifact dated outside the window is a forgery even though steps 1 and 2 both pass. (4) Compare the fields inside signed_payload against the artifact shown — if a field appears on the artifact but not in signed_payload, the signature does not cover it, and the response says so. The window comparison in step 3 is one function in the open verifier (x402-verify's checkKeyServiceWindow), so a dispute runs the same check this store runs. ## Why signed payload Most real signature-verification failures are canonicalization mismatches: the verifier rebuilds what it thinks was signed, gets a byte different, and the check fails — or passes when it should not. Publishing a canonicalization recipe moves that risk onto you. Serving the exact signed string removes it: there is nothing to rebuild. Compare the fields inside it against the artifact shown, and any gap between what is signed and what is displayed becomes visible rather than theoretical. ## Key continuity ### Backup #### Exists true #### State The signing key exists offline, on paper, in more than one physical location, neither of them this building and neither of them a computer. It has never been photographed, typed into a networked machine, stored in a password manager, or sent to a printer. WHERE the copies are is not published and will not be — that detail protects nothing of yours and weakens something of ours. WHAT it protects is stated plainly, because it is a narrow thing: loss, and only loss. A backup is a copy of the same key, so it is no defence at all against that key being stolen. #### Protects against - loss #### Not a defence against - theft - copying - coercion #### Note A backup is not a succession scheme, and the two get confused because both sound like continuity. A backup means the store survives losing its key. It does nothing about the key being copied by somebody else, because a thief with the key and a keeper with the key hold identical material and produce identical signatures. Anyone who tells you their backup strategy addresses compromise has described the wrong threat. ### Succession #### Successor key exists false #### State ONE HANDOVER HAS BEEN PERFORMED, on 2026-07-31, hours after this protocol was published and under every line of it — announced before the new key signed anything, and the announcement signed by the outgoing key at /api/verify/handover_1. It was not a drill. The store had no recoverable copy of its first private key, found that out while writing a paper-backup procedure, and handed over to a key written on paper before it ever signed anything rather than run on indefinitely with no recovery. The whole reason is published inside the signed announcement and dated on /corrections. NO SUCCESSOR TO THE CURRENT KEY EXISTS — not generated, not held, not escrowed, not pre-signed — and the question gating one has never been cryptographic: it is where a second private key would physically live, because a successor stored beside the primary is a second way to become us in exchange for nothing. #### Protocol ##### Item 1 ###### Rule A new signing key is announced BEFORE it signs anything, at /.well-known/scvd-signing-key and on /corrections, and never after. If a key appears on this store having already issued artifacts, that is not a handover and you should treat it as a compromise. ###### Because Announcement after the fact is indistinguishable from a thief updating the page. Ordering is the only part of this a holder can check without trusting us, so ordering is where the commitment goes. ##### Item 2 ###### Rule The announcement of a new key is SIGNED BY THE OUTGOING KEY, and the signed bytes are served the same way every other signature here is — the exact string, at a verify URL, checkable with your own library. An unsigned handover notice is worth nothing whoever posts it. ###### Because This is the only cryptographic content in the whole scheme. Only the holder of the old key can bless the new one, which is what makes a legitimate handover distinguishable from somebody replacing the key on a page they have taken over. Everything else on this list is a promise; this one is a check. ##### Item 3 ###### Rule A retired key never re-signs, revokes, back-dates, or improves anything it already signed, and the new key never re-issues old artifacts under itself. What was signed stays signed, exactly as it was, forever. ###### Because A signature is a statement about specific bytes at a specific moment. A store that re-signed its own history would destroy the only property that made the first signature worth holding. Already promised on /wind-down; this is the scheme that promise was assuming. ##### Item 4 ###### Rule If the outgoing key CANNOT sign the announcement — lost, destroyed, or in somebody else's hands — then there is no legitimate handover available, and we will say exactly that on /corrections rather than perform one anyway. Any key that follows is a new store wearing this one's name, and you have no cryptographic reason to connect it to anything signed before. ###### Because This is the failure this scheme does NOT cover, and naming it is what stops the other three rules from reading as a guarantee. A protocol whose bad case is unwritten is a protocol that will improvise the bad case in the moment it is most tempting to improvise. ##### Item 5 ###### Rule There is no revocation list and there will not be one under this design. If this key is known to be compromised, the honest instrument is a dated notice on /corrections saying so and from when — not a list that a compromised host could serve empty. ###### Because A revocation endpoint served from the same infrastructure as the key it revokes adds ceremony and no security. Better to have nothing than to have something that looks like protection. #### Mechanism THE PROTOCOL ABOVE IS IMPLEMENTED, NOT ONLY PROMISED. Every key this store has ever signed with is published at /.well-known/scvd-signing-key under key_history, and a retired key stays there permanently — an artifact carries the key it was signed with, so a rotation never breaks an old signature, but a key matching nothing we publish would leave that artifact merely self-consistent rather than attributable to us. Every verify response now names which published key signed the thing, whether that key is current or retired, and says so out loud when a signature matches NO key we have ever published, which is the honest answer that was previously missing. A handover announcement is a signed artifact class of its own with its own verify URL, and it is signed by the outgoing key because it is minted before the secret is replaced. The count of handovers is derived from the registry rather than typed, and from the key actually in the lock rather than from the file — so it reported zero right up to the moment the secret changed, and one immediately after, with no deploy in between and no window in which an old artifact read as unattributable. #### Key history URL #### Externally anchored history URL #### Anchoring limit The anchor log proves WHEN a key state was committed, never WHO SHOULD HAVE held it. A thief holding this store's key could timestamp exactly as validly as we can. It bounds a compromise window after the fact; the succession protocol above is the thing that is meant to prevent one, and these are different jobs. #### What is deliberately undisclosed Some of this is deliberately not explained, and it is worth being precise about which parts. Where key material physically lives is not published, will not be, and is not hinted at — that detail buys a reader nothing and costs us something real. How you would tell a genuine handover from somebody claiming to be us IS published, in full, above, before there is any handover to spin — because a succession plan kept secret is worth nothing to the person it exists to protect, and asking you to trust that a good plan exists is the one thing this store's whole argument is against. If we ever hand this key on and it does not look like the list above, that list is the evidence against us. ### Post quantum #### Today Every signature this store issues is Ed25519, which is not post-quantum safe, and every signature-tenure claim here assumes it holds. That assumption is fine today and is stated rather than hidden, because a durability claim with an unstated boundary is the defect class this store publishes corrections about. #### Migration path Already built, not because we anticipated PQ but because we lost a key copy once: a PQ migration is a key handover, announced under the outgoing Ed25519 key BEFORE the post-quantum key signs anything, with the Ed25519 key kept published forever in key_history so every pre-migration artifact stays attributable. The succession protocol at /attestation does not change; only the algorithm of the incoming key does. #### What would not survive Cryptographic exclusivity of old signatures. Once a relevant quantum computer exists, an Ed25519 signature no longer proves this store uniquely could have made it. What keeps its footing: artifacts bound to public chain state (settlement_tx) keep independent timestamps, and the key history keeps the record of what was claimed when. #### Trigger A post-quantum signature extension landing normatively in the x402 spec AND the runtime supporting the chosen scheme (ML-DSA-65 is the current proposal). Watching, not building: adopting a PQ scheme before the ecosystem picks one is how a store ends up alone on the wrong algorithm. ### Limit ONE COMMITMENT AND ONE CHECK, AND THEY ARE NOT THE SAME WEIGHT. The check is real: a handover signed by the outgoing key is something you verify with your own library and nobody's word. Everything else here — the ordering, the refusal to re-sign, the promise to say so plainly if the bad case arrives — is a statement of intent by one operator holding one key, written down early so it can be quoted back at us, and enforceable by nobody. It is worth what this store's word is worth. The record of what that has been worth so far is at /corrections. ## Trust models ### Self signed #### Name Self-signed (in-process) #### Means The store signs a statement about itself or about a transaction with itself, with its own key, in the same process that produced the statement. A valid signature proves the bytes came from this store's key and have not changed since. It proves nothing about whether the statement is true. #### Weakness This is the weakest trust model there is. If you do not trust the store, a self-signed certificate gives you no reason to start. It is a receipt, not evidence. ### Custody only #### Name Custody and timestamp only #### Means The content was written by the buyer, not by us. The signature attests that this store received exactly these bytes and filed them at this time. It is a notarised envelope: the envelope is ours, the letter is yours. #### Weakness We do not check, endorse, or vouch for anything inside. A signed anchor summary can be entirely false and the signature is still valid, because the signature was never a claim about the contents. ### Third party observation #### Name Third-party observation #### Means The store observes something it does not control and signs what it saw: public chain state on the networks each instrument declares, or whether somebody else's URL answered when we walked past it out of band. We are not a party to the thing being observed, which is the property that makes the observation worth anything. #### Weakness It is still OUR observation, made once, at one moment, by one party. It is not a consensus, not a monitoring history, and not a promise about any other moment. A NOT_FOUND is not a claim that something will never settle. ## Whose eyes ### Heading Whose eyes saw it ### Runtime A receipt your agent's own runtime signs is the agent's side of the counter: that key signed those bytes, in that order, and nothing in them has changed since. It is the agent's word about what the agent did. ### Party A certificate from this store is self-signed (in-process) by a party to the sale. The store signs a statement about itself or about a transaction with itself, with its own key, in the same process that produced the statement. A valid signature proves the bytes came from this store's key and have not changed since. It proves nothing about whether the statement is true. ### Observer Third-party observation is the third kind. The store observes something it does not control and signs what it saw: public chain state on the networks each instrument declares, or whether somebody else's URL answered when we walked past it out of band. We are not a party to the thing being observed, which is the property that makes the observation worth anything. ### None None of the three proves the report inside it was true. A runtime receipt and a certificate for the same purchase, side by side, are both parties' signed word (cited_artifact on the certificate is the shared link); only the third kind is a disinterested look, and it is labelled as such per artifact class below. ### Receipt line 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. ## Ard trust verification ### Identity did:web:scvd.store ### Identitytype did ### Trustschema #### Identifier #### Version 1 #### Governanceuri #### Verificationmethods - did:web - JWS-EdDSA-RFC8785 - OpenTimestamps-Bitcoin - outgoing-key-succession ### Attestations #### Item 1 - **Type** — scvd-signing-key-succession - **Uri** — - **Mediatype** — application/json ### Anchor check Verify the JWS AND match its public key to snapshot.current_public_key (or a retired_keys public_key for a historical signature) in an anchor-log entry with existed_by.status of bitcoin_confirmed or covered_by_later_anchor. Recompute the snapshot digest and previous_digest links, then independently verify its OpenTimestamps proof against Bitcoin block headers; for coverage, follow via_sequence and verify the later proof and every intervening link. The status word alone is this store's bookkeeping. Check continuity from a previously trusted checkpoint and each handover announcement signed by the outgoing key, with service dates, at /.well-known/scvd-signing-key. Compare the Bitcoin block time with the claimed history; a newly stamped replacement is not old history. Missing evidence, declared_only, pending proofs, broken links or an unknown key do not establish anchored identity. ## Artifact classes ### Contribution acceptance receipts #### ID contribution_acceptance #### Trust model self_signed #### Signs SCVD recorded acceptance of the identified submission under the hashed posted terms. The receipt binds the report and review digests, declared payout address, reward terms and recorded times. SCVD is the commissioning party, not an independent evaluator. #### Does not prove Does not prove every reported finding, wallet control, worker identity, uniqueness, a wider task's completion, payment issuance or redemption, or net earnings. No public endorsement or rating is granted. The receipt is historical; later payment and follow-through records remain separate. #### Verify URL #### Trust model name Self-signed (in-process) ### Recorded-evidence comparison #### ID change_check #### Trust model third_party_observation #### Signs The complete observation.record, including its signed source readings, dates, gaps and comparison or manifest. SHA-256 of observation.signed_payload is bound into certificate.attests. observation.signature_jcs covers the RFC 8785 canonical record. #### Does not prove Live endpoint state, continuous coverage, successful future payment or delivery, or provider safety. No new observations does not mean no endpoint changes. Missing dates, different endpoints and different batteries cannot establish a comparable change. #### Verify URL #### Trust model name Third-party observation ### Batch of recorded host evidence #### ID batch_spot_check #### Trust model third_party_observation #### Signs The complete observation.record, including its signed source readings, dates, gaps and comparison or manifest. SHA-256 of observation.signed_payload is bound into certificate.attests. observation.signature_jcs covers the RFC 8785 canonical record. #### Does not prove Live endpoint state, continuous coverage, successful future payment or delivery, or provider safety. No new observations does not mean no endpoint changes. Missing dates, different endpoints and different batteries cannot establish a comparable change. #### Verify URL #### Trust model name Third-party observation ### Research endpoint comparison #### ID research_comparison #### Trust model third_party_observation #### Signs The supplied endpoint set, observation window, per-endpoint preflight reports, advertised atomic terms, host history with dates and coverage, same-endpoint network comparisons, shared receiving-address matches, gaps and limits. SHA-256 of observation.signed_payload is bound into the purchase certificate as attests; observation.signature_jcs also covers the RFC 8785 canonical record. #### Does not prove Research accuracy, freshness, licensing or suitability for a trade; common ownership or common underlying sources; complete market coverage; final variable costs; settlement or delivery success. An advertised address match is not an identity verdict. No ranking, recommendation or Coinbase endorsement. #### Verify URL #### Trust model name Third-party observation ### ARD trust manifest #### ID ard_trust_manifest #### Trust model self_signed #### Signs Detached JWS (RFC 7515 Appendix F), EdDSA with the existing certificate key. Remove only trustManifest.signature, JCS-canonicalize the remaining trustManifest (RFC 8785), UTF-8 encode and base64url encode it. Restore that payload between the two dots and verify the protected header plus '.' plus encoded payload. The protected kid resolves through the existing did:web document. Also verify provenance.sourceDigest: remove host.trustManifest and every entries[].trustManifest from the full catalog, preserve every other field, JCS-canonicalize, SHA-256 the UTF-8 bytes, and compare 'sha256:' plus lowercase hex. Each entry carries the same trust envelope; an extracted entry must match the same identifier in the full catalog at provenance.sourceId, with every non-trust field equal, to check this binding. A valid signature, matching catalog digest AND independently verified anchor evidence establish that this manifest was signed by a key with an externally anchored succession history. #### Does not prove The signed digest binds the catalog's entries, URLs, descriptions and updatedAt. It does not prove that any entry in ard.json is accurate today, authenticate the resource bytes fetched from those URLs, or establish freshness. The anchor log dates key state, not this manifest or the right to hold a key. A stolen signing key can still sign. A first-time reader without a previously trusted checkpoint cannot rule out a replacement history. #### Verify URL #### Trust model name Self-signed (in-process) ### Certificates of purchase #### ID certificate #### Trust model self_signed #### Signs The canonical JSON of the certificate's own fields, in a fixed declared order: cert_id, item, patron_number, date, name, tip_usdc, note, win, tag, attests, made_by, paid_usdc, asset, network, payer, settlement_tx, cross_ref, purpose, from_the_store, mandate_id, saw, settled_via, trade_partner, trade_price_usd, trade_instruction, quote, issuer, cited_artifact, gateway_payment, accepted_usdc — every one of those that is present. DERIVED FROM THE SIGNING CODE, NOT TYPED BESIDE IT: this sentence was hand-written and had fallen a day behind by 2026-07-31, omitting made_by and then the five payment fields, on the page whose entire job is stating exactly what bytes a signature covers. Gateway certificates use signed accepted_usdc and gateway_payment at issue and omit paid_usdc and settlement_tx; later batch state lives on private purchase status. paid_usdc is the TOTAL settled rather than the tip, payer is the paying wallet (chain-verifiable, unlike a chosen name), settlement_tx is the on-chain transaction, and quote is sha256 over the RFC 8785 form of the five accepted x402 terms (scheme, network, asset, payTo, amount; EVM asset and payTo lowercased first) the buyer's payment signature was bound to — the same five the store's signed offer in the 402 commits to, so a held offer and a receipt can be matched without asking us. cited_artifact is a buyer-supplied : naming an artifact outside this store — recorded verbatim and signed, never fetched or verified here. The exact string is served as signed_payload on the verify response, so nothing has to be reconstructed. #### 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. #### Verify URL #### Trust model name Self-signed (in-process) ### Certificates of purchase settled on a trade account #### ID trade_certificate #### Trust model self_signed #### Signs The same canonical fields as a certificate of purchase, with settled_via (trade_account, or trade_account_test while the account is in test), trade_partner, trade_price_usd and trade_instruction present — and paid_usdc, asset, network, payer and settlement_tx absent, because no payment reached this store. trade_instruction is the sha256 of the exact string the marketplace signed (timestamp, nonce, body), so the receipt ties to one signed instruction from one named account. #### Does not prove That any money moved anywhere: not that the marketplace's customer paid, not that the marketplace paid us, not that either ever will. It proves this store delivered this item on a signed instruction from the named account, on this date, at the listed trade price. The receivable behind it is a statement reconciled by hand, and the daily cap on the account is the shape of the trust involved. #### Verify URL #### Trust model name Self-signed (in-process) ### Settlement attestations (single, or each member of a sheaf) #### ID settlement_attestation #### Trust model third_party_observation #### Signs The whole observation object: the transaction hash asked about, what the chain said, the block height, the chain head at reading, the confirmations, the moment observed, the desk's battery, and the binding — what, if anything, ties the transaction to one payment authorization (none, authorization_nonce or the reserved input_commitment), beside what was asked. When a facilitator's settlement response was supplied, input_claims is signed too: the sha256 of the bytes received and a per-field table of whether each claim agrees with the chain — never the claimed values themselves, echoed outside the signature under received_not_observed. The projection beside the artifact is signed on its own, points back by evidence_hash, and is never the record. Observations signed before 2026-09-11 carry neither battery nor binding: read that as predating binding classes, never as unbound; a battery cited without a binding is defective. From battery v3, a nonce checked against a successful receipt adds signed binding.evidence: pairing result, reason and, when readable, authorizer, nonce, recipient, atomic amount and receipt positions — one canonical USDC AuthorizationUsed immediately followed by its Transfer, every supplied term matching; ambiguous authorizers need payer, unknown ordering stays unestablished. Battery v2's independent nonce and transfer matches can overstate correspondence: consult /corrections before citing its binding claim. Battery v4 also checks the EVM receipt's transaction identity, reported chain, block height, chain head and status before signing; malformed provider answers, and missing or duplicate batch answers, are refused rather than labelled. From settlement-attestation-v5, a signed auth_capture field names each USDC leg that touched the x402 auth-capture escrow set (role, deployment, direction, source); absent, none did; status and binding never move for it. Historical signed bytes are unchanged; a sheaf (attestation_bundle) is this artifact at volume, every member signed alone. #### Does not prove That goods or services were delivered, that a NOT_FOUND will never settle later, or that the payment was legitimate. That the transaction was the settlement of any particular request: binding says what it ties, and authorization_nonce ties one EIP-3009 authorization, not one 402 challenge — whether the door tied that nonce to a single request is the door's work and unobserved. Under auth-capture, the lifecycle: whether the hold auth_capture names was later captured, voided or refunded was not read. Anything a facilitator's settlement response says: it is received, not observed, and an agreement row that reads disagrees is a finding about the response, not a verdict on anyone. One RPC read of public state, at one moment, signed by a party with no interest in the answer. #### Verify URL #### Trust model name Third-party observation ### Standing watch rows (the Night Watch) #### ID standing_watch_probe #### Trust model third_party_observation #### Signs Each hourly row on its own: the watch id, the watched URL, the moment, the verdict, the names of any failed checks, and the status and latency where present — in the declared canonical order, so any single row can be quoted alone. #### Does not prove Anything about hours we did not probe. The gaps are derived at read and counted against us in the same history; a row is one look from one vantage, never an uptime figure. Nor is it bought. The watched party pays — the rating agency's model, whose one defect is that the rater drifts favorable — so the terms say it at spec level: payment buys frequency and permanence, never outcome. An endpoint that degrades while its operator is paying gets signed readouts saying so, in public, at the URL the operator paid for. The clause rides every watch history as who_pays_and_what_it_buys. #### Verify URL #### Trust model name Third-party observation ### Patronage purchase grants #### ID recurring_patronage #### Trust model self_signed #### Signs Each purchased grant binds its certificate, pass ID, original purchase time, service start/end, renewal number and submitted agent name. The current pass carries its latest grant; each buyer receipt keeps the grant that purchase bought. The monthly note is signed separately. #### Does not prove That a later renewal never happened, or that any monthly note existed before it was written. The grant proves the original purchased term. A late retry restores that term without extending it; another extension requires another buyer-authorized purchase. #### Verify URL #### Trust model name Self-signed (in-process) ### Operator statement passes (the Operator's Statement) #### ID operator_statement_pass #### Trust model third_party_observation #### Signs A signed commission binds the purchase certificate, wallet, chain, asset, opening block or slot, original start/end dates and cadence. Each new pass carries its exact signed_payload. Each pass signs the statement id, the address, the chain and asset, the moment, the exact block range (slot range on Solana, and the pass says which) read and the chain head at read, the coverage word, inflows and outflows with counts and totals, the per-pass payer tally with its cap stated, and the pass's evidence hash — in the declared canonical order, so any one pass can be quoted alone. #### Does not prove What any transfer was for, who the paying addresses are, or anything outside the block range, asset and chain the pass names. The summary on the history is arithmetic over the passes and is not itself signed; recount it. Blocks not yet read and passes we missed are our gaps, counted against us on the same page, never a fact about the address. #### Verify URL #### Trust model name Third-party observation ### Conformance watch passes (the Conformance Watch) #### ID conformance_watch_pass #### Trust model third_party_observation #### Signs Each daily pass on its own: the watch id, the watched URL, the moment, the verdict, the names of failed checks and of advisories — in the declared canonical order, so any single day can be quoted alone. #### Does not prove Anything about the hours between passes, or about days nobody checked — those are derived at read and counted against us. One pass a day is conformance cadence, never uptime. Nor is it bought. The watched party pays — the rating agency's model, whose one defect is that the rater drifts favorable — so the terms say it at spec level: payment buys frequency and permanence, never outcome. An endpoint that degrades while its operator is paying gets signed readouts saying so, in public, at the URL the operator paid for. The clause rides every watch history as who_pays_and_what_it_buys. #### Verify URL #### Trust model name Third-party observation ### A2A repair-kit observations #### ID a2a_repair_kit #### Trust model third_party_observation #### Signs RFC 8785 canonical observation bytes: the card and endpoint URLs, moment, battery and protocol version, bounded exchanges, per-check states, counts and gaps. The purchase certificate binds the initial observation hash; each recheck and card-watch pass is signed separately. #### Does not prove Complete A2A conformance, untested versions or transports, application correctness, safety, uptime, or that the suggested repairs were applied. The store authored the suggestions; implementation is separately scoped. Missing watch slots are counted against the observer. #### Verify URL #### Trust model name Third-party observation ### Service audit reports (the Once-Over) #### ID service_audit #### Trust model third_party_observation #### Signs The whole report: the audited URL, the moment, the criteria version, the verdict, every check and advisory, and the report's evidence hash. The purchase certificate binds the same evidence hash in its attests field. #### Does not prove That the endpoint is endorsed, reliable, or up at any other moment. One GET against published criteria; an unreachable verdict is a fact about one network path at one moment. #### Verify URL #### Trust model name Third-party observation ### On-page audit reports (the Shop Window) #### ID onpage_audit #### Trust model third_party_observation #### Signs The whole report: the page named, the moment, the criteria version, the verdict, every check and advisory, the blind spots, and the report's evidence hash. The purchase certificate binds the same evidence hash in its attests field. #### Does not prove What a browser would show. The battery reads the HTML as served — script-rendered content is invisible to it and the report says so on itself. Not an endorsement, not a ranking claim, and nothing about any other moment. #### Verify URL #### Trust model name Third-party observation ### Launch checks (one real purchase attempt, from the buyer's side) #### ID launch_check #### Trust model third_party_observation #### Signs The whole walk: the endpoint named, the moment, the exact User-Agent sent, every stage (approach, challenge, terms, screen, payment, settle, delivery) with its detail, the quoted amount after a 2xx, payment_attempt evidence, the seller-named transaction where one came back, the paying field wallet, and the record's evidence hash. The purchase certificate binds the same evidence hash in its attests field. #### Does not prove Anything about any other moment, any other buyer, or the seller generally — one transaction, once. An unpaid verdict is a statement about this store's published rules (spend cap, sanctions screen, rails carried), never about the seller. Any payment presentation uses the v2 shape only; a v1-only seller's refusal is recorded as exactly that. A lost response or expired authorization does not prove no money moved: payment_attempt retains the reconciliation facts and names an unknown settlement explicitly. Replay byte recovery does not establish artifact truth or usefulness; changed bytes do not establish fresh fulfillment. Never a badge, never a score. #### Verify URL #### Trust model name Third-party observation ### Opening days (one real purchase attempt, then a week of daily passes, then the passport, under one certificate) #### ID opening_day #### Trust model third_party_observation #### Signs The launch check's whole walk (endpoint, moment, User-Agent, every stage, the quoted amount after a 2xx, payment_attempt evidence, the seller-named transaction where one came back, the field wallet) and its evidence hash, which the purchase certificate binds in its attests field. A signed watch commission binds the same URL, purchase certificate and original service dates; each daily pass is signed on its own at the history URL. The passport is the census's own signed, expiring object. #### Does not prove Anything about any other moment, buyer, or the seller generally: one transaction once, seven daily looks, and a page that names its own stale date. The three under one certificate are still three observations, not a grade. Replay byte recovery does not establish artifact truth or usefulness; changed bytes do not establish fresh fulfillment. Never a badge, never a score, never a guarantee the door stays up. #### Verify URL #### Trust model name Third-party observation ### Provenance checks (which doors advertised a receiving address, and when) #### ID provenance_check #### Trust model third_party_observation #### Signs The whole record: the subject address verbatim and its digest, every signed week the address was advertised with the doors, verdicts and offered terms as the round recorded them, the dated drift between weeks, the subject's standing note verbatim, the caveat, the limits, and the record's evidence hash. The purchase certificate binds the same evidence hash in its attests field. #### Does not prove Who operates any door or holds the address: a shared address is a fact about the address, not a verdict about operators, and custodial and platform wallets make unrelated doors share one. Nothing between weekly rounds, nothing about doors our feeds never listed, and never a ranking or a compliance verdict. Delivered to the buyer; the artifact existing publishes nothing. #### Verify URL #### Trust model name Third-party observation ### Mandates (claimed authorization, recorded before the acting) #### ID the_mandate #### Trust model third_party_observation #### Signs The whole record: the claimed instructions verbatim, who claimed to submit them (agent or principal — itself a claim), the declared cap and expiry where given, the moment of recording, and the record's evidence hash. The purchase certificate binds the same evidence hash in its attests field, and any later certificate citing the mandate_id carries that citation signed. #### Does not prove That the human principal actually gave these instructions — chain-of-custody, never truth-of-intent, and the store cannot distinguish a principal's client from an agent claiming to be one. Nor that the declared cap or expiry were honored: declared claims are recorded, never enforced. What it proves is narrower and real: this exact claim existed, signed and dated, before every purchase that cites it. #### Verify URL #### Trust model name Third-party observation ### Wallet statements (the chain's side of an agent's books) #### ID the_statement #### Trust model third_party_observation #### Signs The whole record: the wallet, the exact block window and chain head at read, every USDC transfer in and out (counts and totals over the full window; per-direction lists capped and saying so), each row's transaction hash, counterparty, amount and block, the coverage word, and the record's evidence hash. The purchase certificate binds the same evidence hash in its attests field. #### Does not prove What any transfer was FOR, whether the wallet's owner knows about them, or anything outside the stated window, asset, or chain — USDC on the one chain named on the artifact, and a wallet moving other tokens or on other networks shows none of that here. No comparison to the agent's own ledger was made or possible: we never see one. window_unreadable is a fact about our read, never about the wallet. #### Verify URL #### Trust model name Third-party observation ### Settlement reconciliations (movement and attributable or declared limits) #### ID settlement_reconciliation #### Trust model third_party_observation #### Signs The whole observation: the transaction asked about, the USDC movement found, any fixed authorization value or declared ceiling, WHERE THAT CEILING CAME FROM, whether it was observed or merely declared, the headroom between the two, the chain head at read time, and the moment. An EIP-3009 no_discretion reading requires the selected transfer itself to be paired with its authorization; a nonce elsewhere for the same payer is insufficient. Approval co-occurrence is not evidence of allowance consumption. The current reader establishes the reported chain, receipt identity, status and block/head before signing. Older observations can overstate attribution or lack these context checks: consult /corrections before relying on them. cap_observed is a signed field in its own right, because the difference between a ceiling we read off Base and a ceiling somebody told us is the entire weight of this artifact. #### Does not prove That a DECLARED ceiling is real. Where cap_observed is false the number came from whoever commissioned the receipt — generally the party it benefits — and the signature covers only that we were told it, never that it is true. It cannot establish allowance consumption from approvals in this or earlier transactions: 'no cap observed' never means no ceiling existed. RPC evidence is not consensus proof. And an over_cap on a declared ceiling is a fact about what the caller said, not about the chain. #### Verify URL #### Trust model name Third-party observation ### Case files (one purchase, every section present or absent by name) #### ID the_case_file #### Trust model third_party_observation #### Signs The whole assembly at one moment: the fresh settlement attestation, the reconciliation where the chain is EVM, the cited mandate with its declared cap printed beside the settled amount, the door's corpus rounds, watch rows and tier over the window, delivery where this store observed it, the buyer's declared inputs marked as such, every absent section with its reason, and the conflict line whenever this store is a party. Each observed section is the shelf's own artifact, produced by the same function. #### Does not prove Who was wronged, at fault, or liable: the file never says, and a reader who wants that sentence must write it themselves from the evidence. That anything was delivered where the delivery section is absent — 'not observed by this store' is the usual answer and it is stated in full weight. That the buyer's declared claim, expected amount, payer or recipient is true: those are stored verbatim and never checked. Anything about the door outside the window, or about a host the corpus never met. #### Verify URL #### Trust model name Third-party observation ### Patron Bitcoin anchors #### ID bitcoin_anchor #### Trust model custody_only #### Signs Nothing directly on the record. Two independent bindings do the work: the purchase certificate signs the buyer's digest via its attests field, and the OpenTimestamps proof commits the same digest into a Bitcoin transaction — the store's dated word and Bitcoin's clock, separately checkable. #### Does not prove What the digest is a digest OF. The label is the buyer's own claim, stored verbatim and never checked; the proof establishes the digest existed by a Bitcoin block, nothing about the bytes behind it. #### Verify URL #### Trust model name Custody and timestamp only ### Tab contribution receipts (the pooled corpus, layer 3) #### ID tab_delta_receipt #### Trust model custody_only #### Signs The receipt object exactly as served in signed_payload: the receipt id, the sha256 digest of the delta's canonical JSON, the delta kind, the moment of acceptance, and the trust line. An anonymized delta matching this digest was accepted at this time — nothing more. #### Does not prove That the report is true. Deltas are self-reported by contributing agents and unverified individually; any aggregate published from the pool is aggregated and signed by us, and that signature covers the arithmetic, never the truth of any single report. Sample sizes ride every published figure because a vendor can feed its own pool — the defence is sunlight, not a promise of resistance. The receipt also does not identify the contributor: nothing does, by design, which is why it doubles as the contribute-to-access ticket. #### Verify URL #### Trust model name Custody and timestamp only ### Corpus snapshots (the ecosystem record) #### ID corpus_snapshot #### Trust model third_party_observation #### Signs The canonical snapshot: version, sequence, the moment taken, the previous entry's digest, the source, the week, and the whole ward round it freezes — hash-linked to the entry before it and OTS-stamped into Bitcoin. #### Does not prove That the observed services behave the same at any other moment, or that the record is complete. The chain proves WE did not rewrite our own history; it cannot prove we saw everything. #### Verify URL #### Trust model name Third-party observation ### Replay kits #### ID replay_kit #### Trust model self_signed #### Signs The RFC 8785 form of the whole kit at /api/replay/{cert_id} — the certificate's signed bytes and signature, the settlement transaction, the accepted terms recovered by matching the catalog against the certificate's signed quote, a fresh JWS offer over those same terms, the sale's standing, and the wrong-scope refusal body — as the detached payload of an EdDSA JWS under the did:web kid the kit names. Assembled on every read from the record and the live catalog, stored nowhere. #### Does not prove That the 402 the buyer paid carried this exact offer: the original was minted per challenge with a five-minute validUntil and was not retained, so the kit signs a fresh one over the five terms the signed quote recovers, and says so. The kit's own signature proves this store assembled these parts on this read; each part is only as true as its own signature and the chain. #### Verify URL #### Trust model name Self-signed (in-process) ### Phantom checks #### ID phantom_check #### Trust model third_party_observation #### Signs The check id, the target URL, and the observation: whether it answered, with what status, how fast, and when we looked. #### Does not prove That the URL is up now, was up before, or will be up later. It is one look, from outside your infrastructure, about six hours after you asked, and unreachable is a finding rather than an error. #### Verify URL #### Trust model name Third-party observation ### Context anchors #### ID context_anchor #### Trust model custody_only #### Signs The anchor id, patron number, date, the summary exactly as the buyer wrote it, and the agent name if one was given. #### Does not prove Anything at all about whether the summary is true. The buyer wrote it; we filed it and dated it. We never read it as instructions and never will. #### Verify URL #### Trust model name Custody and timestamp only ### Visit stamps and Countermarks #### ID stamp #### Trust model self_signed #### Signs The stamp id, variant, ISO week, date, and where present the bearer's chosen name, the punched card, the consecutive-week count and the week's store condition. #### Does not prove That the bearer is any particular party. A name on a stamp is a name somebody chose. #### Verify URL #### Trust model name Self-signed (in-process) ### Luckies - **ID** — lucky - **Trust model** — self_signed - **Signs** — The whole lucky record, including its status and any keeper's note about a status change. - **Does not prove** — Luck. - **Verify URL** — - **Trust model name** — Self-signed (in-process) ### Trading card pressings, packs and day seeds #### ID card #### Trust model self_signed #### Signs The whole pressing — set position, key, name, type, tier, line, the path it cites, print number, source, slot, pack, certificate, seed commit, date, patron and holder — and separately the pack manifest binding the seed commit, the draw inputs and its five card ids, and the day seed record (commit at once, seed the day after). #### Does not prove Ownership by anybody in particular, or value of any kind. A card entitles the holder to a card. #### Verify URL #### Trust model name Self-signed (in-process) ### Gazette issues - **ID** — gazette_issue - **Trust model** — self_signed - **Signs** — The issue's markdown, exactly as printed. The copy you hold is the copy that went to press. - **Does not prove** — That anything reported in it is correct — only that it has not been altered since printing. - **Verify URL** — - **Trust model name** — Self-signed (in-process) ### Payout authorizations (bounty rewards and credit cash-outs) #### ID payout_authorization #### Trust model self_signed #### Signs An EIP-3009 TransferWithAuthorization over USDC on Base: from the store's declared field wallet, to a named recipient, for a stated amount, valid until a stated unix second, with a single-use nonce. Signed with the FIELD WALLET's secp256k1 key — not the ed25519 artifact key that signs everything else on this page, and not interchangeable with it. Anyone may submit it to the USDC contract; the contract checks the signature itself. The authorization permits a transfer; it does not establish that the recipient received payment. #### Does not prove That the store still holds the balance to honour it — an authorization is spendable only while the field wallet is funded, and the USDC contract, not this store, is the thing that decides. Expiry closes that authorization’s redemption window; it does not establish settlement or resolve an underlying obligation. A credit cash-out can only ever pay the wallet that earned it; a bounty reward pays the address the claim named, screened before signing. Neither is a certificate: they carry no verify URL and prove nothing about goods, only about money we authorized. #### Verify URL https://scvd.store(none — submit it to the USDC contract on Base; the token verifies it) #### Trust model name Self-signed (in-process) ## Money path ### Custody No smart contract this store controls ever holds a buyer's USDC, and no balance is kept on anyone's behalf. Settlement is one transfer, the buyer's wallet to the receiving address published inside the 402 offer itself. On Base it is an EIP-3009 transferWithAuthorization: the destination and amount sit inside the digest the BUYER signs, so the facilitator that submits it can fail to settle but cannot redirect or resize it. On Solana the buyer signs the whole transaction; same property, same reason. And delivery comes FIRST — the goods are produced before the payment is presented — so the window between the two is this store's risk, never a buyer's deposit. ### The check Every certificate carries settlement_tx and network inside the signature. Pick any one and read the transaction on chain: one USDC transfer, payer to the offered payTo, no intermediate contract of ours. The claim is per-settlement, so there are exactly as many independent checks available as there have been sales. ### What this does not cover The facilitator is a liveness dependency: settlement can fail while it is down, and those failures are booked on the decline desk faulted to the facilitator rather than hidden. USDC itself is a contract with an issuer who can freeze funds — true of every USDC payment everywhere, and not improved by us. And a statement about the money path is not an audit; the no-audit line under what this store does not have stands beside this one. ## Maker marks ### Keeper #### Label The keeper's hand #### Means A person chose or made this specific thing, for you, after your order. Not a template and not a draw: if two buyers ask on the same day they get different work, because a human did it twice. ### House #### Label The house's hand #### Means A person authored the pool and the odds; a machine chose which one you got. The herd, the drawer's contents and the weighting are the keeper's work, done before your order and not repeated for it. Nobody looked at your particular draw. ### Machine #### Label No hand at all #### Means No human is in this path at any point. The store observed something or computed something and signed what it found. That is the property that makes it worth anything — a human in the loop here would be a defect, not a feature. ## Maker mark policy One shelf carries a maker's mark in the certificate, signed with everything else: luckies, marked HOUSE — the keeper wrote the herd and weighted the odds, and a machine chooses which one a given buyer gets. He does nothing per order. (The drawer carried the same mark until it was retired on 2026-08-20; the cards it issued keep theirs forever.) The mark exists because those are the only shelves where a buyer could not otherwise tell. It is deliberately absent from settlement_attestation and phantom_check, whose own copy already says no human looked and says it more precisely than a mark could, and from the human-labor shelves, where the item IS the person and a mark claiming a person did it would be telling you what you paid for. Until 2026-07-30 the listing spec said luckies were graded by a person; they never were, and the question that found it was this one. ## Marked items - **Luckies** — house - **Pack** — house - **Window pick** — house ## Not built - No hash-linked continuity chain OVER SOLD ARTIFACTS. Each certificate is signed independently; there is no tamper-evident ordering between them, so we cannot prove that no artifact was withheld. (The store's own key history and ecosystem record are hash-chained and submitted for Bitcoin timestamping — /.well-known/anchor-log.json and /corpus.json. Their completed proofs can independently bound the historical bytes when verified; a pending submission cannot. Since 2026-09-05 each certificate also carries its own OpenTimestamps existed-by, served as `existence` on /api/verify, which bounds when that one receipt existed and still says nothing about what was withheld between one receipt and the next.) - Free tools export exact signed bytes and supplied hash-bound evidence, then verify them offline against a public key you establish independently. Missing evidence is named; Bitcoin timestamps need an independent OTS verifier. The verifier instructions cover source and package installation. Key-history snapshots are context. See /developers for installation and commands. - No successor key. One ed25519 key signs everything at a time — 1 retired, one in service — and if the live one is stolen every signature it produces is indistinguishable from ours; a backup is no defence against that and is not offered as one. Recovery from LOSS only: the key exists offline on paper in more than one place, so a destroyed secret does not end the store's ability to sign. That is the whole of it. The MECHANISM for a handover exists and has been used once, on 2026-07-31, under the protocol published the same day: key history, retirement dates, and an announcement signed by the outgoing key at /api/verify/handover_1. What does not exist is a successor to the key now in service. This is stated the same way on /stack, which calls it the one dependency with no substitute. - No threshold or multi-party signing. One key, one holder, one process. - No hardware security module. The key is a Cloudflare Worker secret. - No post-quantum signatures in production. Production artifacts use Ed25519, which a cryptographically relevant quantum computer could forge. A real Ed25519 plus ML-DSA-65 checkpoint has been tested in an isolated experiment; it is not independently audited or enabled here. Production migration still needs multi-algorithm artifact and verifier support, key registration and an independently timestamped continuity record before changing the signer. A handover alone does not make old signatures quantum-resistant. - No third-party audit of any of the above, and no patent. Both are sometimes offered as evidence of seriousness; neither is evidence that a signature checks out, which is the only thing this page is about. ## Held against us Disclosing a limitation is not the same as solving it. One key, one operator, no third-party witnessing, no recovery — that is still “trust this one key, this one operator, full stop,” and it is the exact single point of failure that co-signing, witness signing and transparency logs exist to remove. An outside reader put it best after checking the artifacts rather than the homepage: this is “a narrower, more honestly-scoped system, not a more capable one.” We agree, we did not write that sentence, and it stays in their words. ## Criteria page ## Honest limit ONE KEY IN SERVICE, ONE HOLDER, ONE ROTATION ON THE RECORD, no artifact-ordering chain and no audit, all listed above in their own words — weigh anything load-bearing against that before building on it. The store is evolving toward verifying more than its own shelf; that direction is tracked at /becoming with its triggers, and nothing here claims it early. What is offered today is that every claim on this page is checkable against the artifacts themselves in about a minute, and that the weakest trust model is named as the weakest rather than left for a reader to work out. If you find a signature that does not verify, or a field shown but not signed, the mailbox is free and it goes on /corrections with your name on it.