Verification model

Don’t trust. Verify.

A registry that asks for trust is just another database. RCX-Registry publishes the proof instead: signed, hash-chained receipts over the whole set, reproducible from open-source code and public schemas. Here is exactly what that means — and how to check it.

Read the source ↗Point a client here

The chain, interactive

One flipped byte, and the chain says so

Four receipts on a sealed spine — a snapshot, a rights verification, a publisher declaration, another snapshot. Flip one byte and verification pinpoints the exact record that broke.

rcx-registry verify --chain --strict ok: true · 4 receipts · chain intact

Each CROWN receipt is ed25519-signed (via Vault Transit) over both its id and the BLAKE3 hash of its payload, so a receipt cannot be edited in place or transplanted elsewhere; ordering is carried by the chained hash on the spine. Anyone can replay the registry's history from these receipts and detect a single flipped byte — that is what makes the registry independently verifiable rather than merely trusted.

The model

Four properties, each one checkable

Canonical form, then hash

Every server envelope is serialised to a canonical CBOR/JSON form and hashed with BLAKE3. Canonicalisation means two parties that hold the same data compute the same hash — no ambiguity about whitespace or field order.

A Merkle root per snapshot

Each sync builds a Merkle tree over the full canonical set and signs the root. One root commits to every server in that snapshot at once: change any single entry and the root changes.

Signed via Vault Transit

The root is signed ed25519 with a key that never leaves Vault Transit. The signature binds the receipt id and the payload hash together, so a receipt cannot be edited in place or moved onto a different snapshot.

Chained, so history is append-only

Each receipt carries the id of the one before it. That turns individual signatures into a spine: to forge one record you would have to re-sign every record after it, which you cannot do without the Vault key.

Verify it yourself

The shape of a snapshot receipt

A snapshot receipt commits to the whole mirrored set through its Merkle root, names the signer, and points at the previous receipt. Nothing here is secret — that is the point.

{
  "kind": "RegistrySnapshot",
  "id": "crown:e6b1…88f2",
  "merkle_root": "b3:9f4c…e21a",
  "server_count": 17439,
  "prev": "crown:8802…6f11",
  "signer_kid": "rcx-registry-2026-04",
  "alg": "ed25519",
  "sig": "base64…"
}

Recompute it from public data

Because the mirror API is public and the receipt schemas are published at static.rcxprotocol.org, verification is reproducible. The steps:

# 1. pull the mirrored set + snapshot metadata
curl -s 'https://registry.rcxprotocol.org/v0/servers?limit=100&cursor=...' > page.json

# 2. canonicalise each server envelope, BLAKE3-hash it
# 3. rebuild the Merkle root over the full set
# 4. compare it to merkle_root in the signed snapshot receipt
# 5. verify sig against the published signer key (signer_kid)
# 6. walk prev -> prev back through the chain; any break = tamper

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.

Verification is a feature, not a promise.

Publishers who claim a namespace get their own receipted history — and a badge that links straight to it.

Claim your namespace Get the badge