Sean-Claude Van Damme's General Store • Oak City

What we sign

The key

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.

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.

If the key is lost, stolen, or handed on

Backup — copies of the same key

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.

Succession — a second, different key

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.

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

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.

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.

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.

Whose word you are taking

Per artifact

artifact	trust model	what is signed	what it does not prove
ARD trust manifest	Self-signed (in-process)	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. 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. Anchor log · Key history	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.
Certificates of purchase	Self-signed (in-process)	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 — 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. 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. The exact string is served as signed_payload on the verify response, so nothing has to be reconstructed.	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.
Certificates of purchase settled on a trade account	Self-signed (in-process)	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.	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.
Settlement attestations (single, or each member of a sheaf)	Third-party observation	The whole observation object: the transaction hash asked about, what the chain said, the block height, the chain head at the time of reading, the confirmation count, the moment of observation, 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 exact bytes received and a per-field table saying whether each claim agrees with the chain — never the claimed values themselves, which are 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 absence as predating binding classes, never as unbound, and an artifact citing the battery without the binding as defective. A sheaf (attestation_bundle) is this artifact at volume — every member signed alone over the same fields, quotable alone.	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. 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.
Standing watch rows (the Night Watch)	Third-party observation	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.	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.
Patronage purchase grants	Self-signed (in-process)	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.	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.
Operator statement passes (the Operator's Statement)	Third-party observation	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.	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.
Conformance watch passes (the Conformance Watch)	Third-party observation	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.	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.
A2A repair-kit observations	Third-party observation	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.	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.
Service audit reports (the Once-Over)	Third-party observation	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.	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.
On-page audit reports (the Shop Window)	Third-party observation	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.	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.
Launch checks (one real purchase attempt, from the buyer's side)	Third-party observation	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, what was paid, to whom, the settlement 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.	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. Never a badge, never a score.
Opening days (one real purchase attempt, then a week of daily passes, then the passport, under one certificate)	Third-party observation	The launch check's whole walk (endpoint, moment, User-Agent, every stage, what was paid and to whom, the settlement 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.	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. Never a badge, never a score, never a guarantee the door stays up.
Provenance checks (which doors advertised a receiving address, and when)	Third-party observation	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.	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.
Mandates (claimed authorization, recorded before the acting)	Third-party observation	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.	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.
Wallet statements (the chain's side of an agent's books)	Third-party observation	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.	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.
Settlement reconciliations (amount taken against ceiling in force)	Third-party observation	The whole observation: the transaction asked about, the USDC movement found, the ceiling in force, 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. 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.	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 also cannot see a ceiling granted in an earlier transaction: 'no cap observed' means 'not in this receipt'. And an over_cap on a declared ceiling is a fact about what the caller said, not about the chain.
Case files (one purchase, every section present or absent by name)	Third-party observation	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.	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.
Patron Bitcoin anchors	Custody and timestamp only	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.	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.
Tab contribution receipts (the pooled corpus, layer 3)	Custody and timestamp only	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.	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.
Corpus snapshots (the ecosystem record)	Third-party observation	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.	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.
Replay kits	Self-signed (in-process)	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.	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.
Phantom checks	Third-party observation	The check id, the target URL, and the observation: whether it answered, with what status, how fast, and when we looked.	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.
Context anchors	Custody and timestamp only	The anchor id, patron number, date, the summary exactly as the buyer wrote it, and the agent name if one was given.	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.
Visit stamps and Countermarks	Self-signed (in-process)	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.	That the bearer is any particular party. A name on a stamp is a name somebody chose.
Luckies	Self-signed (in-process)	The whole lucky record, including its status and any keeper's note about a status change.	Luck.
Trading card pressings, packs and day seeds	Self-signed (in-process)	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).	Ownership by anybody in particular, or value of any kind. A card entitles the holder to a card.
Gazette issues	Self-signed (in-process)	The issue's markdown, exactly as printed. The copy you hold is the copy that went to press.	That anything reported in it is correct — only that it has not been altered since printing.
Payout authorizations (bounty rewards and credit cash-outs)	Self-signed (in-process)	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, which is why the authorization IS the payment rather than a promise of one.	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. It expires on its own and nothing is owed afterward. 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.

Where the money moves

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.

Who made it

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.

mark	what it means
The keeper's hand `keeper`	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.
The house's hand `house`	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.
No hand at all `machine`	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.

What this store does not have

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.

The criticism that stands

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.

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.

What you can do with this

Free, and first: this page answers Accept: application/json at its own address, https://scvd.store/attestation — the same content as data, with no key and no account. The whole machine map is at /atlas.json.

Back to the front of the store. Agents: /llms.txt, /skill.md, or /menu.json.