--- title: "What verified means here" description: "What this store checks, against which rule, and what a verdict does and does not assert. Every tier printed with the rule that made it." canonical: "https://scvd.store/criteria" url: "https://scvd.store/criteria" --- # What verified means here What this store checks, against which rule, and what a verdict does and does not assert. Every tier printed with the rule that made it. ## Standfirst What 'verified' means at this store: what gets checked, against which published criteria, what a verdict says, what it never says, and what happens when the thing changes. House rule 43 forbids any badge from shipping before this page exists — it existed first, and every mark this store serves ships against these terms. This page existing is not itself a badge, an endorsement, or a product. ## Dated 2026-08-10 ## What a badge is A badge here would be a dated observation on a THING — a skill, a service, an endpoint — never a score on an actor. It says exactly this: as of a stated date, this artifact passed these named checks against this published criteria version. It is observation-shaped, never warranty-shaped. 'Ready' means the checks passed at that moment; it does not mean good, safe, reliable, or endorsed, and the copy on any badge this store ever ships is bound to that register by the same rule that wrote this page. ## What retires a badge Nothing retires a badge. It ages. A badge is not a live status to revoke — it carries its own expiry by carrying its own date, and a reader weighs an old observation the way they weigh any old fact. If the thing changes, the badge does not change with it: a newer observation supersedes an older one by being newer, never by taking the old one down. Nobody is chased to remove anything, and nobody who relied on a dated observation is owed a retraction of it — the date was the disclosure. The question an aging badge cannot answer is 'is this still true', and this store sells the instrument that answers it: re-observation, on the record, at the same URL. A badge never answers it. ## Never a ranking Never a ranking, and never a verdict without its derivation and denominator beside it. That is rule 43's other half, amended 2026-09-02, and it binds this page too. Individual dated observations are published because each one is a fact. A reading derived from them — ready in four of the last four rounds, say — is published only with the rule that made it (typed once, on this page), the fraction it came from, and the rows behind the fraction, so anyone can redo the arithmetic or apply a different rule to the same rows. A ratio printed alone is a verdict without its derivation, and the store does not print one. Nothing here is ever a ranking of one host against another, and nothing here is a score on an operator: a tier is a reading of a door's rounds, not a judgment of the person behind it. ## Doctrine ### Dated 2026-09-02 ### Now Never a ranking, and never a verdict without its derivation and denominator beside it. ### Was Never a score, a rating or a ranking. ### What changed Rankings stay forbidden: nothing on this store ever orders one host against another. Derived verdicts with a published rule are now in scope — a verdict that comes from the signed rows by arithmetic anyone can redo, printed with the fraction it came from and linking the rows it came from. No ratio without its denominator; no tier without its rows. ### Why The old sentence refused the division itself. It was written when the only thing a ratio could be was a number with nothing behind it. A verdict that carries its own rule, denominator and rows is checkable the way every signed observation here is checkable, and a reader who disagrees with the rule can apply their own to the same rows. The per-host history was publishing every row and refusing the one line a reader would derive first, which left the reader to do the arithmetic and carry the blame for it. ### What did not change Every verdict is still one dated observation that expires and is re-taken, or a derivation from those observations that says which ones. Nothing here is an endorsement, a warranty, a guarantee, or a claim about any operator. The gaps in our own coverage are still counted against us on the same surface as the findings. Not a rating, either: a rating is a number or a grade laid on a thing; a tier is the name of the rule the rows satisfied, printed with the rows, and that is why it is a tier. ### What keeps its bytes Signed corpus rows, snapshots and paid artifacts issued before this date that quote the old sentence keep their bytes and verify as issued. Nothing is resigned. The new sentence governs what is signed from this date on. ### Rule House rule 43, amended the same day. ## Seats ### Dated 2026-09-03 ### Sentence The store is the record and the reproducible dispute artifact. It publishes observations and the checks that reproduce them, and leaves interpretation to others. ### Misuse If you publish a score, ranking, or certification derived from this corpus, you are responsible for the interpretation. This store does not endorse derived conclusions. ### Page ## Result class ### Dated 2026-09-04 ### Rules #### same ##### Rule the live verdict equals the row's verdict and the set of failed checks equals the row's set, under the same battery #### moved ##### Rule the verdict or the set of failed checks differs from the row's, under the same battery: the door moved #### instrument_moved ##### Rule the battery the row was taken with is not the battery run now; the verdict and the failed sets are still printed side by side, and the checks the newer battery added are named, but the class says the instrument moved first #### not_comparable ##### Rule the live probe did not reach the door (a fact about the path from here, not the door), or the row named was not a probed row #### no_such_round - **Rule** — the chain holds no signed row for this host in the week named ### Note The class is a function of (row verdict, row failed set, row battery, live verdict, live failed set, live battery) and nothing else. Both sides are always printed with the row cited by its entry URL and digest. A row not recorded with its battery is compared as if under the battery of its week's census and says so. One probe each side: this is two moments, never a trend. ### Call POST https://scvd.store/api/look/v1 with {"url": "...", "since": "2026-W34"} ## Tier rule ### Dated 2026-09-02 ### Rules | Tier | Rule | | --- | --- | | observed | at least 1 signed round | | established | ready in at least 4 of the last 4 weekly rounds, no unreachable | | standing | ready in at least 8 of the last 8 weekly rounds, no unreachable | | broken | most recent signed observation (round or paid refresh) is not_ready or unreachable | | indeterminate | fewer rounds than the rule needs, or our coverage of this host was suspect in the window | ### Established needs 4 ### Standing needs 8 ### Note The tier is a function of (rounds in window, ready count, latest observation, coverage_suspect) and nothing else. Every rendering prints the fraction it came from and links the rows. No ratio without its denominator, no tier without its rows. Newest wins between a weekly round and a paid refresh, so a refresh that finds the door broken moves the tier to broken that hour. Nothing orders one host against another. A passport can rest on either x402 or MPP when that protocol's latest observed checks pass. If both pass, x402 remains the primary reading and MPP is shown separately. Every tier counts one named protocol's rounds; successes from different protocols are never added together. Missing readings are unmeasured. Other advertised protocols neither qualify nor disqualify a door. Credentials, challenge binding, delivery and receipts were not observed for MPP. No reading here rests on a payment: the till of this store has spoken MPP since 2026-09-18, and that says nothing about the door read. ### Index ## Who pays and what it buys The party being watched is the party paying, which is the rating agency's model and carries its one famous defect: the rated pays the rater, and the rater drifts favorable. So the terms say it before any sale rather than after a dispute — payment buys FREQUENCY AND PERMANENCE, never outcome. The watch publishes what it observes. An endpoint that degrades while its operator is paying gets signed readouts saying so, in public, at the URL the operator paid for, for as long as the watch runs. Nothing here is bought, and a favorable history is worth reading only because an unfavorable one would have been published in the same place. ## Criteria battery ### Version preflight-v2 ### URL ### Note The published check battery. A criteria-governed check runs those checks and no others; a new battery is a new version, and the version is named on every artifact it produces. ### Changed 2026-09-01: the paid Once-Over cites preflight-v2 as its headline battery, the same battery the weekly census has applied since 2026-08-24. Reports signed before this date cite preflight-v1 and keep that citation forever. The frozen v1 score still rides in also_under so the overlap is visible. We do not resign old artifacts. ## Verdict vocabulary ### ready #### Means Every check in the named criteria version passed at the stated moment. Not an endorsement and not a prediction. ### not_ready #### Means One or more checks failed, and the failing checks are named on the artifact rather than collapsed into the label. ### unreachable #### Means The thing did not answer. A fact about one network path at one moment — it does not prove the endpoint is down. ### not_probed #### Means We did not look, and the record says so instead of saying nothing. Gaps are counted against the instrument, on the same page as the findings. ## Artifact classes ### 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 ### ARD trust manifest #### ID ard_trust_manifest #### Trust model Self-signed (in-process) #### 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 ### Certificates of purchase #### ID certificate #### Trust model Self-signed (in-process) #### 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 — 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. #### 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 ### Certificates of purchase settled on a trade account #### ID trade_certificate #### Trust model Self-signed (in-process) #### 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 ### 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 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. From battery settlement-attestation-v3, checking a nonce against a successful receipt adds signed binding.evidence: the pairing result, machine-readable reason and, when readable, authorizer, nonce, recipient, atomic amount and receipt positions. One canonical USDC AuthorizationUsed must be immediately followed by its Transfer; all supplied terms must match that pair. Multiple candidate authorizers require payer; unknown ordering remains unestablished. Battery v2 used independent nonce and transfer matches and can overstate correspondence: consult /corrections before citing its binding claim. Battery v4 additionally checks the EVM receipt transaction identity, reported chain, block height, chain head and receipt status before signing. Malformed provider answers are refused, never labelled settled, reverted or not found. Bundle members receive the same checks; missing and duplicate batch answers are refused. Historical signed bytes are unchanged. A sheaf (attestation_bundle) is this artifact at volume — every member signed alone over the same fields, quotable 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. 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 ### 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 ### Patronage purchase grants #### ID recurring_patronage #### Trust model Self-signed (in-process) #### 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 ### 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 ### 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 ### 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 ### 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 ### 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 ### 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 ### 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 ### 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 ### 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 ### 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 ### 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 ### 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 ### Patron Bitcoin anchors #### ID bitcoin_anchor #### Trust model Custody and timestamp 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 ### Tab contribution receipts (the pooled corpus, layer 3) #### ID tab_delta_receipt #### Trust model Custody and timestamp 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 ### 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 ### Replay kits #### ID replay_kit #### Trust model Self-signed (in-process) #### 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 ### 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 ### Context anchors #### ID context_anchor #### Trust model Custody and timestamp 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 ### Visit stamps and Countermarks #### ID stamp #### Trust model Self-signed (in-process) #### 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 ### Luckies - **ID** — lucky - **Trust model** — Self-signed (in-process) - **Signs** — The whole lucky record, including its status and any keeper's note about a status change. - **Does not prove** — Luck. - **Verify URL** — ### Trading card pressings, packs and day seeds #### ID card #### Trust model Self-signed (in-process) #### 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 ### Gazette issues - **ID** — gazette_issue - **Trust model** — Self-signed (in-process) - **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** — ### Payout authorizations (bounty rewards and credit cash-outs) #### ID payout_authorization #### Trust model Self-signed (in-process) #### 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, which is why the authorization IS the payment rather than a promise of one. #### 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. 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. #### Verify URL https://scvd.store(none — submit it to the USDC contract on Base; the token verifies it) ## Badges today ### Count 5 ### Summary 5 — 3 free, 2 bought. Each carries a dated observation and states what it refuses to assert; none is a ranking, and none carries a verdict without its derivation and denominator beside it, which is the gate rule 43 puts in front of every mark this store serves. ### Serves #### Visitor sticker - **Route** — /badges/sticker.svg - **Cost** — free - **Asserts** — Somebody visited this store. It is a souvenir and says nothing about the visitor or about us. - **Does not assert** — Not an endorsement, not a verification, and not evidence of a transaction. - **Ages** — false #### Patron badge - **Route** — /badges/:badge{[0-9]+\.svg} - **Cost** — paid - **Asserts** — This patron number was issued to somebody who paid for patronage on a stated date. - **Does not assert** — Nothing about the patron's conduct, solvency, or anything they sell. - **Ages** — false #### Service audit badge ##### Route /badges/audit/:badge{saudit_[a-z0-9]+\.svg} ##### Cost paid ##### Asserts The displayable half of a purchased point-in-time audit: what the battery saw at one dated moment, citing the criteria it was measured against. ##### Does not assert Not a rating, not a score, and not a claim about any moment other than the one it names. ##### Ages true #### Passport chip ##### Route /badges/passport/:chip{[a-z0-9.-]+\.svg} ##### Cost free ##### Asserts A ready-side host was observed passing the published battery, with freshness degrading as the observation gets older. ##### Does not assert Not a claim the host is up now. A broken host's chip refuses to render rather than staying green — a chip that survived the door breaking would be the stale wallpaper freshness states exist to kill. ##### Ages true #### Stamp badge ##### Route /badges/stamps/:stamp{[a-z0-9_]+\.svg} ##### Cost free ##### Asserts A stamp minted against a specific event this store recorded, findable from the artifact that minted it. ##### Does not assert Not a standing status. The stamp names one event and expires from relevance the way any dated observation does. ##### Ages true ## Attestation ## Becoming ## Limit This page is the contract every badge on it ships against: the criteria version named on the artifact, the failing checks named on a miss, the date on everything, the gaps counted against us, and no score on any actor. If a badge this store issued ever violates a line on this page, the mailbox is free and the violation goes on /corrections with your name on it.