{"namespace":"scvd-attestation","version":"v1","title":"The scvd-attestation format, v1","summary":"The interchange contract for every signed artifact this store issues: canonical forms, encodings, the certificate binding convention, and verification steps that need nothing from us but a published key. A tool that implements this page can verify any scvd artifact offline and cite the result by name.","url":"https://scvd.store/spec/scvd-attestation/v1","publisher":{"name":"SCVD General Store","what":"A human-run general store selling small signed goods to autonomous agents, paid in USDC over x402 v2 on a network offered in the current payment quote (see /rails). Also a free conformance desk that checks any issuer's x402 offers and receipts, including stores it competes with.","homepage":"https://scvd.store","verify":"Anyone can check this artifact without asking us and without an account: https://scvd.store/api/verify/{id}, free and permanent. The signing key is at https://scvd.store/.well-known/scvd-signing-key, and the offline verifier is MIT-licensed. The conformance desk is POST https://scvd.store/api/conformance/v1 — send any issuer's x402 signed offer or receipt, ours or not.","feedback":"What this store's clients said about it, at an address this store cannot write to: ERC-8004 agent 86957 in the Reputation Registry at 0x8004BAa17C55a88189AE136b182e5fdA19dE9b63 on Base (eip155:8453). Buyers write from their own addresses; the contract rejects the agent owner, so none of it is ours. Read it with getClients, or leave your own — the call and a pre-filled proof-of-payment ride every purchase response. This store turns none of it into a number, about itself or anyone.","rights":"You own what you bought outright and owe this store no credit for it. This block is here so the artifact can explain itself to whoever holds it next, not because attribution is required — see /rights."},"stability":{"promise":"Within v1, changes are additive only: new artifact types and new OPTIONAL fields may appear, and signed field lists may be APPENDED to, never reordered or truncated — the certificate list's first eight positions have been frozen since the store opened, and every addition since is an append with a dated note in the signing code. Anything that would break an existing verifier is a v2 at a new URL, with v1 continuing to serve. This page carries its version in its path for exactly that reason.","versioning_of_artifacts":"Artifacts do not carry this spec's version; they are dated, and the spec states its rules as of those dates (the certificate's legacy form below is the worked example). A verifier should key on the artifact's served fields, not on an assumed vintage."},"signing":{"external_envelopes":{"ard_trust_manifest":{"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.","profile":"https://scvd.store/attestation#ard_trust_manifest","note":"ARD uses its declared detached-JWS profile instead of the house hex signature and dual-emit rules below."}},"algorithm":"ed25519","encoding":"signature and public_key are lowercase hex strings; the message is the UTF-8 encoding of the canonical form; digests are lowercase hex sha256 unless stated otherwise.","the_uniform_rule":"Except for the external_envelopes declared above, for every artifact that carries its own signature, the signed message is the JSON serialization of the artifact's fields IN THE ORDER SERVED, stopping above `signature` — JSON.stringify of exactly those fields, no whitespace, no re-sorting. Fields absent from the artifact are omitted entirely, never null (the certificate's canonical form skips undefined fields). Where a wrapper serves the artifact (the certificate, the context anchor), the response also carries signed_payload: the exact string the signature covers, so nothing has to be rebuilt — prefer the served bytes; the recipe here is for when you only kept the artifact.","verification_steps":["1. Obtain the key: the live and retired keys, with service dates, at https://scvd.store/.well-known/scvd-signing-key. Match the artifact's public_key against that history; a key not in the history did not sign for this store.","2. Reconstruct the message per the artifact's canonical form below (or take signed_payload verbatim where served).","3. ed25519_verify(utf8(message), hex_to_bytes(signature), hex_to_bytes(public_key)).","4. Compare the fields inside the message against the artifact as displayed: a field shown but not signed is not vouched for, and honest surfaces here say so themselves."],"key_history_integrity":"The key history above is ours and editable by us; the same history is committed where we cannot reach it: https://scvd.store/.well-known/anchor-log.json — a hash chain over key states, each digest timestamped into Bitcoin via OpenTimestamps. It proves WHEN a key state was committed, never WHO SHOULD HAVE held the key.","relation_to_jcs_rfc8785":"This namespace's PRIMARY canonical form is DECLARED-FIELD-ORDER serialization, not RFC 8785 (JCS). JCS derives byte order by sorting keys; this spec derives it from the field lists published on this page, which are part of the contract. The two disciplines are equally deterministic and NOT byte-compatible: re-canonicalizing an scvd artifact's primary signature through JCS produces different bytes and a failed verification. This is deliberate and permanent for artifacts already issued — this store's signatures are forever, and migrating a preimage discipline would orphan every one of them (the frozen_prefix rule below is the same commitment at field level).","jcs_dual_emit":"SINCE 2026-08-18 every house-format artifact minted here ALSO carries `signature_jcs`: a second ed25519 signature, same key, same field subset, over the RFC 8785 (JCS) canonicalization — sorted keys, ECMAScript number and string serialization, no whitespace. Verify it with any RFC 8785 implementation: jcs(signed_fields_as_object) -> utf8 bytes -> ed25519_verify against the same public_key. The primary signature remains the authoritative one; signature_jcs is interop, so any tool that verifies raw RFC 8785 bytes can check scvd artifacts without knowing our field lists. That is the JCS byte primitive only: the IETF receipt drafts that build on RFC 8785 add pre-canonicalisation rules our artifacts do not meet (integer-millisecond timestamps, NFC strings), and none of them assigns a role to an ed25519 signature, so signature_jcs verifies under RFC 8785, not under any draft — see relation_to_other_x402_receipt_work. Artifacts minted before 2026-08-18 carry no signature_jcs, exactly the way certificates minted before 2026-07-30 lack later fields: history, not a defect. Where served, signature_jcs_covers states this in place, and /api/verify reports the JCS signature's own validity separately from the primary's — never collapsed into one boolean.","relation_to_other_x402_receipt_work":{"as_of":"2026-09-03","standing":"Three Internet-Drafts on the IETF datatracker overlap this namespace's territory. What each defines, what this store's format shares with it, and where the two do not align, stated per draft at the revision read. All three are drafts, not standards; nothing on this page is bound by any of them.","drafts":[{"draft":"draft-hopley-x402-canonicalisation-jcs-v1","revision_read":"-04","url":"https://datatracker.ietf.org/doc/draft-hopley-x402-canonicalisation-jcs-v1/","defines":"A canonicalisation discipline for agentic-payment receipts: JCS (RFC 8785) as the canonical preimage form, plus pre-canonicalisation schema-normalisation rules (integer-millisecond timestamps, pinned field names, preserved array order, type validation before canonicalisation) and an in-band canon_version pin, identified as urn:x402:canonicalisation:jcs-rfc8785-v1.","shared":"The RFC 8785 byte discipline itself, carried here by signature_jcs (dual-emitted on every artifact minted since 2026-08-18); SHA-256 over canonical JSON with lowercase-hex digests; field names and ordering treated as load-bearing.","not_aligned":"Our primary canonical form is declared-field-order serialisation, not JCS, and that is permanent for artifacts already issued; our artifacts carry ISO 8601 date strings, which this draft's Substrate Rule 2 (section 4.1) forbids in canonical preimages; our artifacts carry no canon_version field. The draft defines no receipt fields of its own (what a receipt binds is left to the formats that reference it) and specifies no anchoring and no post-quantum discipline; we have no post-quantum discipline either, and our anchoring is OpenTimestamps into Bitcoin for the records that anchor at all."},{"draft":"draft-hopley-x402-compliance-receipt","revision_read":"-02","url":"https://datatracker.ietf.org/doc/draft-hopley-x402-compliance-receipt/","defines":"A categorical compliance-screening receipt for agentic payments: ALLOW, REFER or DENY recorded at admission time under named statutory retention obligations, with six required fields (payer_ref, screen_result, screen_timestamp_ms, screen_provider_did, jurisdiction_flags, canon_version) and a hash-linked audit chain, canonicalised under the same jcs-rfc8785-v1 discipline.","shared":"The RFC 8785 layer via our signature_jcs; SHA-256 content hashing of canonical bytes; the issuer named by a resolvable key reference (their screen_provider_did; our published key and did:web document).","not_aligned":"A different artifact class. Theirs records a screening decision about a payer before money moves and binds payer_ref, outcome, provider, jurisdictions and time: no recipient, no amount, no resource, no settlement. Our certificate binds payer, recipient (asset, network, payTo), amount (paid_usdc), resource (item), time (date) and the settlement transaction. We emit no screening receipt, our canonical forms differ as above, anchoring is out of scope there (ours is OpenTimestamps into Bitcoin), and neither format carries any post-quantum discipline; we have none."},{"draft":"draft-vauban-x402-consolidated","revision_read":"-00","url":"https://datatracker.ietf.org/doc/draft-vauban-x402-consolidated/","defines":"A negotiable receipt-format extension with three variants (a Stwo Circle STARK proof; a hybrid ES256K + ML-DSA-65 dual signature; a classical ES256K JWS fallback) over a JCS preimage discipline, a two-axis post-quantum discipline mapped to the NIST PQC migration roadmap, and a Starknet on-chain anchor format with a canonical anchor tuple and Cairo event layout. The claim algebra, the payment-lifecycle FSM and the delegation binding are deferred to companion documents with no normative content in this draft (section 1.3).","shared":"The RFC 8785 preimage discipline under the same jcs-rfc8785-v1 marker (our signature_jcs layer); the same design goal, a self-contained receipt a stranger verifies offline; and their 32-byte action_ref, binding a payment artifact to a work-layer artifact, is the same construction as our attests digest, differing in name and in that ours states what was digested per item class.","not_aligned":"Signature scheme: theirs is ES256K, ML-DSA-65 or a STARK proof; ours is one ed25519 signature. Canonical form: as above, our primary form is declared-field-order, and our ISO date strings fail their integer-timestamp_ms and NFC rules (sections 3.4, 3.6, 3.7). Anchoring: theirs is a Starknet on-chain tuple verified over the Starknet JSON-RPC; ours is OpenTimestamps proofs committed into Bitcoin (the key-state log on each state change, the corpus weekly). Post-quantum: they specify a full two-axis discipline with a 2025 to 2030 migration window; we have none: one classical ed25519 key at a time, no STARK, no ML-DSA, no migration plan, said here rather than implied."}],"conformance_desk":"The conformance desk does not parse either draft family's receipt format today; it checks artifacts under the x402 offer-receipt extension, not these drafts. Whether it should is a separate decision, not made on this page.","corrected":"2026-09-03: this block replaces a 2026-08-20 paragraph that described the vauban family by a scope its consolidated draft defers, and said signature_jcs already verified under the drafts' discipline. Neither was right; the entry is on /corrections."}},"test_vectors":{"what":"A fully worked example of both signature disciplines, with a PUBLISHED throwaway key. Run it before trusting your verifier: if your implementation cannot reproduce these two verifications, the bug is on your side of the wire, and finding that out costs nothing.","key_warning":"The vector key below signs NOTHING real. It appears in no key history and never will; a real artifact presenting it must fail step 1 of verification (key not in the store's history).","vector":{"seed_hex":"4242424242424242424242424242424242424242424242424242424242424242","public_key":"2152f8d19b791d24453242e15f2eab6cb7cffa7b6a5ed30097960e069881db12","served_payload_exact_bytes":"{\"note\":\"This vector signs nothing real; its key is published on purpose and appears in no key history.\",\"artifact\":\"test_vector\",\"issued_at\":\"2026-08-21T00:00:00.000Z\"}","primary_signature_over_served_bytes":"194853ba44ed91d5f178d0ac225c5aed912c21f969118233f1e40dda9caa9f4af38cea1b2834ddd9cb99e8b2347c3025738d64e41eb5b725ee7ccee2ce4fd60e","jcs_canonicalization_of_same_payload":"{\"artifact\":\"test_vector\",\"issued_at\":\"2026-08-21T00:00:00.000Z\",\"note\":\"This vector signs nothing real; its key is published on purpose and appears in no key history.\"}","signature_jcs_over_jcs_bytes":"532f58e1723cf5d9227b54cf8aaf809a6104cdc8fa2173d264d95920b7ffe05a6c4ecc7998e1f090165e3fa2c6057388be5a61468a99fbbaf5523f84acc5c009","the_lesson":"The payload's keys are served UNSORTED on purpose: the two disciplines produce different bytes and different signatures over the same object. A verifier that conflates them will pass one and fail the other, and this vector catches it."},"reference_verifier_js":"async function verify(message, signatureHex, publicKeyHex) { const hex = (h) => Uint8Array.from(h.match(/.{2}/g).map((b) => parseInt(b, 16))); const key = await crypto.subtle.importKey(\"raw\", hex(publicKeyHex), { name: \"Ed25519\" }, false, [\"verify\"]); return crypto.subtle.verify({ name: \"Ed25519\" }, key, hex(signatureHex), new TextEncoder().encode(message)); } // WebCrypto Ed25519 (Node 19+, Deno, Cloudflare Workers, modern browsers). message is signed_payload verbatim for the primary, or your own RFC 8785 canonicalization for signature_jcs.","incident_policy":"Stated as facts about what exists. ONE live signing key, one operator; a stolen live key would sign indistinguishably from the store — every artifact-selling surface says so. On suspected compromise, what the machinery already supports: the key is retired in the directory with an end-of-service date, a new key enters with its start date, the state change is committed into the Bitcoin-anchored key chain (which proves WHEN, never WHO SHOULD HAVE), and a corrections entry names the incident window. Containment is the service window: artifacts attribute to the key that signed them WITHIN its dated service, so a compromise bounds the doubt to the window between last-known-good anchor and retirement, never to the whole history. What does NOT exist yet, said plainly: a pre-announced successor key (the single-point-of-failure every outside read names; open ruling F3), and any co-signer or independent witness.","revocation_story":"There is no revocation registry, and this spec does not pretend one. Three mechanisms do the honest work instead: (1) EXPIRY — artifacts that age (passports) carry their own expiry and freshness arithmetic, and verifiers should refuse expired evidence without asking anybody; (2) WITHDRAWAL — a claim this store no longer stands behind is withdrawn IN PUBLIC at its original URL, the notice leading both dialects while the signed bytes stay byte-identical and the withdrawal rides OUTSIDE the signed payload (precedent: the August 2026 field report — a retraction must never rewrite what the signature covers); (3) KEY RETIREMENT — see incident_policy. /api/verify reports what a signature IS (valid over these bytes, by this key, in this service window), never that the claim remains endorsed."},"assurance_levels":{"what":"Every artifact verifies identically; its LEVEL says what a valid signature claims. Levels describe this store's claim, never the subject's quality.","levels":[{"level":1,"name":"novelty","claim":"This store sold this artifact, with these bytes, on this date. Provenance and nothing else.","not_claimed":"Nothing about the world outside the store. A signed blessing is a real blessing, not a true one.","examples":["hello","small_blessing","lucky artifacts","zodiac readings"]},{"level":2,"name":"observation","claim":"At a stated moment, our instrument looked at one thing outside the store and recorded what it saw, with the evidence cited so you can re-look.","not_claimed":"Nothing before or after the moment, and nothing the cited evidence does not itself support. An observation is a photograph, not a warranty.","examples":["settlement_attestation","bitcoin_anchor","the fresh set's rows","reconcile_card_statement"]},{"level":3,"name":"monitored","claim":"Observations on a standing cadence, with the gaps recorded — a missed check appears as a hole, never papered over.","not_claimed":"Continuous coverage. The cadence is stated; between checks the world is unwatched and the record says so.","examples":["conformance_watch","the weekly census and its corpus"]},{"level":4,"name":"audited","claim":"A full named battery ran against the subject at a point in time; every criterion and its verdict is in the report, including the failures.","not_claimed":"Anything past the audit's date, and anything outside the named criteria. An audit ages from the moment it is signed.","examples":["service_audit","launch_check"]},{"level":5,"name":"witnessed","claim":"A named human stood in the loop and attests to what the machine cannot: that a person looked.","not_claimed":"Institutional assurance. One store, one keeper, one key — the ceiling of this ladder until independent co-signers exist, and the spec says so rather than implying otherwise.","examples":["the_collab"]}],"human_room":"https://scvd.store/trust"},"certificate":{"what":"The purchase receipt every sale mints; the wrapper most other artifacts bind into.","signed_fields_in_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"],"canonical_form":"JSON.stringify of the object built by walking signed_fields_in_order and copying each field THAT IS PRESENT on the certificate, in that order. Absent fields are omitted, never null.","frozen_prefix":"The first eight positions (cert_id through win) are frozen forever: old signatures cover exactly that sequence. Everything after is a dated append.","legacy_form":"Certificates minted before 2026-07-30 were signed over the pre-append field set. /api/verify accepts both forms and names WHICH one verified (current | legacy | invalid), listing any served fields a legacy signature does not cover, rather than collapsing to a boolean.","verify_url":"https://scvd.store/api/verify/{cert_id}"},"attests_binding":{"what":"The convention that lets one verify endpoint answer for two artifacts: a certificate's `attests` field carries a lowercase hex digest of a second artifact, INSIDE the signed fields, so the store's dated signature covers the binding itself.","per_item":{"settlement_attestation":"attests = the observation's evidence_hash: sha256 of the JSON serialization of the observation's core fields (everything above evidence_hash — observed_at through query).","attestation_bundle":"attests = sha256 of the sheaf's evidence_hash values comma-joined in delivery order. Each member still carries and verifies its own hash and signature alone.","bitcoin_anchor":"attests = the buyer's own digest, lowercased. The store never saw the bytes; the same digest is independently committed into Bitcoin via the OpenTimestamps proof on the anchor record.","service_audit":"attests = the report's evidence_hash: sha256 of the JSON serialization of the report's core fields (audit_id through advisories)."},"rule":"An attests value is always a digest, never content; recompute it from the delivered artifact and compare. A certificate whose attests does not match the artifact it travels with is binding some OTHER artifact, and the mismatch is the finding."},"hash_chains":{"what":"Two of the store's own histories are hash-linked so WE cannot rewrite them: each entry carries the previous entry's digest, and entry digests are OTS-stamped into Bitcoin.","anchor_log":"https://scvd.store/.well-known/anchor-log.json — key-state history. Entries prove themselves by digest chain plus OTS proof; they are not separately ed25519-signed, because the chain exists precisely for the moments a signature of ours would be worthless (a stolen key signs lies just as validly).","corpus":"https://scvd.store/corpus.json — the weekly ecosystem record. Entries are BOTH chained and ed25519-signed over a fixed canonical field order (version, sequence, taken_at, previous_digest, source, week, round).","deliberately_unchained":"Patron Bitcoin anchors are NOT chained to each other or to our logs: a stranger's proof should not be coupled to our bookkeeping, and a Bitcoin-confirmed OTS proof carries its own time alone."},"ots_anchoring":{"what":"Where a record carries an `ots` block, it is an OpenTimestamps submission of a sha256 digest: status is pending (a calendar accepted it), complete (upgraded to a Bitcoin-confirmed proof), or failed (the store's hourly pass retries).","verify":"Base64-decode proof_base64 into a .ots file and run the standard `ots verify` client against the digest. A complete proof verifies against Bitcoin block headers alone — no calendar, no us."},"trust_models_note":"A valid signature means different things for different artifacts — the trust model per class, including where it is the weakest available, is stated at https://scvd.store/attestation and not repeated here. Model names used below: Self-signed (in-process); Custody and timestamp only; Third-party observation.","artifacts":[{"id":"contribution_acceptance","name":"Contribution acceptance receipts","trust_model":"Self-signed (in-process)","signature_covers":"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":"https://scvd.store/api/bounties/contributions"},{"id":"change_check","name":"Recorded-evidence comparison","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/api/verify/{cert_id}"},{"id":"batch_spot_check","name":"Batch of recorded host evidence","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/api/verify/{cert_id}"},{"id":"research_comparison","name":"Research endpoint comparison","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/api/verify/{cert_id}"},{"id":"ard_trust_manifest","name":"ARD trust manifest","trust_model":"Self-signed (in-process)","signature_covers":"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":"https://scvd.store/.well-known/ard.json"},{"id":"certificate","name":"Certificates of purchase","trust_model":"Self-signed (in-process)","signature_covers":"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 <format>:<reference> 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":"https://scvd.store/api/verify/{cert_id}"},{"id":"trade_certificate","name":"Certificates of purchase settled on a trade account","trust_model":"Self-signed (in-process)","signature_covers":"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":"https://scvd.store/api/verify/{cert_id}"},{"id":"settlement_attestation","name":"Settlement attestations (single, or each member of a sheaf)","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/api/verify/{cert_id}"},{"id":"standing_watch_probe","name":"Standing watch rows (the Night Watch)","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/api/watch/{watch_id}"},{"id":"recurring_patronage","name":"Patronage purchase grants","trust_model":"Self-signed (in-process)","signature_covers":"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":"https://scvd.store/api/patronage/{pass_id}"},{"id":"operator_statement_pass","name":"Operator statement passes (the Operator's Statement)","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/api/operator-statement/{statement_id}"},{"id":"conformance_watch_pass","name":"Conformance watch passes (the Conformance Watch)","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/api/conformance-watch/{watch_id}"},{"id":"a2a_repair_kit","name":"A2A repair-kit observations","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/api/a2a/kits/{kit_id}"},{"id":"service_audit","name":"Service audit reports (the Once-Over)","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/api/service-audit/{audit_id}"},{"id":"onpage_audit","name":"On-page audit reports (the Shop Window)","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/api/onpage-audit/{audit_id}"},{"id":"launch_check","name":"Launch checks (one real purchase attempt, from the buyer's side)","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/api/launch-check/{check_id}"},{"id":"opening_day","name":"Opening days (one real purchase attempt, then a week of daily passes, then the passport, under one certificate)","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/api/opening-day/{cert_id}"},{"id":"provenance_check","name":"Provenance checks (which doors advertised a receiving address, and when)","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/api/provenance-check/{provenance_id}"},{"id":"the_mandate","name":"Mandates (claimed authorization, recorded before the acting)","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/api/mandate/{mandate_id}"},{"id":"the_statement","name":"Wallet statements (the chain's side of an agent's books)","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/api/statement/{statement_id}"},{"id":"settlement_reconciliation","name":"Settlement reconciliations (movement and attributable or declared limits)","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/api/reconciliation/{reconciliation_id}"},{"id":"the_case_file","name":"Case files (one purchase, every section present or absent by name)","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/case/{case_id}"},{"id":"bitcoin_anchor","name":"Patron Bitcoin anchors","trust_model":"Custody and timestamp only","signature_covers":"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":"https://scvd.store/api/bitcoin-anchor/{anchor_id}"},{"id":"tab_delta_receipt","name":"Tab contribution receipts (the pooled corpus, layer 3)","trust_model":"Custody and timestamp only","signature_covers":"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":"https://scvd.store/api/tab/pool"},{"id":"corpus_snapshot","name":"Corpus snapshots (the ecosystem record)","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/corpus.json"},{"id":"replay_kit","name":"Replay kits","trust_model":"Self-signed (in-process)","signature_covers":"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":"https://scvd.store/api/replay/{cert_id}"},{"id":"phantom_check","name":"Phantom checks","trust_model":"Third-party observation","signature_covers":"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":"https://scvd.store/api/verify/{check_id}"},{"id":"context_anchor","name":"Context anchors","trust_model":"Custody and timestamp only","signature_covers":"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":"https://scvd.store/api/verify/{anchor_id}"},{"id":"stamp","name":"Visit stamps and Countermarks","trust_model":"Self-signed (in-process)","signature_covers":"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":"https://scvd.store/api/verify/{stamp_id}"},{"id":"lucky","name":"Luckies","trust_model":"Self-signed (in-process)","signature_covers":"The whole lucky record, including its status and any keeper's note about a status change.","does_not_prove":"Luck.","verify_url":"https://scvd.store/api/verify/{lucky_id}"},{"id":"card","name":"Trading card pressings, packs and day seeds","trust_model":"Self-signed (in-process)","signature_covers":"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":"https://scvd.store/api/verify/{card_id}"},{"id":"gazette_issue","name":"Gazette issues","trust_model":"Self-signed (in-process)","signature_covers":"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":"https://scvd.store/api/verify/gazette_{n}"},{"id":"payout_authorization","name":"Payout authorizations (bounty rewards and credit cash-outs)","trust_model":"Self-signed (in-process)","signature_covers":"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)"}],"watch_row_canonical_form":"The watch families are the exception to the omission rule above: absent optional fields serialize as null rather than being omitted, so every row is the same shape and any row is quotable alone. Standing watch rows sign JSON.stringify({watch_id, url, at, verdict, status, latency_ms, failed}); conformance watch passes sign JSON.stringify({watch_id, url, at, verdict, status, failed, advisories}) — exactly those keys, exactly that order, null for an absent status or latency.","key_surfaces":{"public_key":"https://scvd.store/.well-known/scvd-signing-key","did_web":"https://scvd.store/.well-known/did.json","externally_anchored_history":"https://scvd.store/.well-known/anchor-log.json","liveness":"https://scvd.store/.well-known/liveness.json"},"related":{"whose_word":"https://scvd.store/attestation — trust model per artifact class, key custody, and what is NOT built here, in its own words.","x402_artifacts":"The signed offers and receipts this store emits during payment follow the x402 offer-receipt extension, not this namespace; conformance vectors at https://scvd.store/.well-known/conformance/offer-receipt-vectors.json and a free checker at POST https://scvd.store/api/conformance/v1.","reference_verifier":"https://github.com/seancrecord/scvd-general-store-repo/tree/main/verifier — MIT, zero dependencies, works on any issuer's x402 artifacts; the certificate checks in it implement this page.","what_is_not_claimed":"https://scvd.store/.well-known/trust.json"},"honest_limit":"This spec is published by the party whose artifacts it describes, and one key signs everything at a time. Naming a format does not make its issuer trustworthy; it makes its issuer CHECKABLE, which is smaller and worth having. Weigh anything load-bearing against /attestation's stated limits before building on it."}