Verification model

Don’t trust. Verify.

RCX-Registry publishes a byte-exact wire specification and conformance vectors for signed receipts and snapshot history. Those formats and test signatures are reproducible today, and production signs a snapshot receipt with Vault Transit ed25519 on each sync tick.

Read the source ↗Point a client here

Link semantics

Two histories, two different targets

The v1 wire format does not put every receipt type onto one generic chain. Verifiers must follow the field defined for the history they are checking.

RegistrySnapshot

Snapshot history

previous_snapshot_hash equals the prior snapshot's flat set digest, stored in snapshot_merkle_root.

EntryEnriched

Enrichment supersession

supersedes_prior equals the prior enrichment receipt's receipt_hash.

The model

Four properties, each one checkable

The canonical form is explicit

Mirrored server objects use the canonical JSON rules in Spec §3. CROWN receipts use canonical CBOR from §2. The spec pins the exact form per artifact instead of treating CBOR and JSON as interchangeable.

A flat set digest per snapshot

The historical field name is snapshot_merkle_root, but v1 computes one sequential BLAKE3 stream over sorted entries. It is not a Merkle tree and provides no inclusion or consistency proofs.

Hash and signature preimages are pinned

receipt_hash zeros three fields; the ed25519 signature then covers full canonical CBOR with only receipt_signature zeroed. The production implementation is designed to use Vault Transit; the published vectors use an obvious test-only key.

Link targets differ by receipt type

RegistrySnapshot.previous_snapshot_hash points to the prior snapshot set digest. EntryEnriched.supersedes_prior points to the prior enrichment receipt_hash. v1 does not define one universal receipt spine.

Verify it yourself

The shape of a snapshot receipt

These are the logical fields of a RegistrySnapshot. Byte strings are shortened hex for readability; the actual wire value is a canonical-CBOR map. The previous hash names the prior snapshot set digest, not a receipt id or receipt hash.

{
  "event_id": "11111111111111111111111111111111",
  "snapshot_id": "22222222222222222222222222222222",
  "scraped_at": 1784761200000,
  "server_count": 17439,
  "snapshot_merkle_root": "9f4c…e21a",
  "previous_snapshot_hash": "8802…6f11",
  "upstream_registry_uri": "https://registry.modelcontextprotocol.io/v0/servers",
  "upstream_snapshot_etag": null,
  "changes": { "added": 17439, "removed": 0, "modified": 0 },
  "receipt_hash": "4b2d…54d9",
  "receipt_signature": "e646…a004",
  "signer_kid": "vault:transit:rcx-registry-signing-key-1"
}

Reproduce the normative vectors

The published corpus freezes receipt bytes, hashes, signatures, negative cases, snapshot digests, and chains. An independent implementation can run these checks without reading the Rust reference implementation.

# Download the normative, test-only corpus
curl -fsS 'https://rcxprotocol.org/spec/v1/vectors/receipts.json' -o receipts.json
curl -fsS 'https://rcxprotocol.org/spec/v1/vectors/snapshot-merkle.json' -o snapshots.json

# 1. reproduce each canonical-CBOR receipt byte string
# 2. recompute receipt_hash after zeroing exactly:
#    receipt_hash, receipt_signature, and signer_kid
# 3. verify ed25519 over full canonical CBOR with only
#    receipt_signature zeroed, using the vector's TEST public key
# 4. reproduce the flat snapshot-set digest byte-for-byte
# 5. compare every result with the checked-in expected hex

The canonicalisation, hashing, and signature-verification logic lives in the rcx-registry-crown crate — Apache-2.0, so you can run the same checks the registry runs.

Current v1 boundary

Production signs and persists a snapshot receipt on each sync tick. Public publisher writes remain closed. The rights and enrichment storage paths retain deterministic BLAKE3 receipt-hash references rather than complete signed artifacts. The public /v0 API does not yet expose full receipt bodies, and signer_kid does not resolve a production public key through any normative endpoint — the key below is published informatively until that endpoint is specified. Complete artifact persistence, retrieval, and authoritative key discovery remain M1a work.

Signing key (informative)

Snapshot receipts carry signer_kid = vault:transit:rcx-registry-signing-key-1. That identifier resolves to this ed25519 public key, version 1, created 2026-07-18:

wP5P2LnvRCUQVpylgyMtopZ9C0dqB1SuZAbbvkdtcOg=

Published here so signatures can be checked today. This is documentation, not a normative protocol surface: Spec v1 defines no key-discovery endpoint, and a versioned, signed key document is M1a work. Treat a key learned from this page as trust-on-first-use.

A frozen format, with explicit boundaries.

Start with the normative specification and vectors. Production receipt retrieval, public key discovery, and real inclusion proofs remain visible follow-on work.

Read Protocol Spec v1 Download vectors