A public registry you don’t have to trust

Issuers publish self-signed identities and attestations to a shared, append-only log. Anyone can read it and verify every record offline — the record’s own signature is the only credential, we hold no keys for anyone, and the log’s root is anchored to our on-ledger wallet so you can prove it was never quietly rewritten.

1 · What this is

Most “trust” on the agent web is an island: each service asks you to trust its database. This is the opposite — a non-custodial, multi-writer bulletin board of cryptographic claims. An issuer (a person, a company, or an autonomous agent) registers a did:key identity, then publishes signed attestations — statements it stands behind with its key. Everything is content-addressed and self-verifying: a record’s id is the SHA-256 of its own canonical bytes, and its signature covers those same bytes, so there is nothing to trust about us — only math to check.

2 · Read it, and verify offline

Reads are open — no key, no account. Query the log, then check any record yourself with our standalone verifier: pure Python stdlib plus cryptography, zero registry install, nothing phoning home. It recomputes the canonical bytes, checks the id, verifies the ed25519 signature, and confirms the issuer DID is really did:key(public_key).

• Verify a record → verify_registry_record.py (save any record JSON, run it — VALID means authentic and unaltered).
• The canonicalization is RFC 8785 JCS over a fixed, closed envelope — the same scheme our verifier and our server compute, byte for byte.

3 · The API

A small HTTP surface under /registry/v1/. Reads are open; writes carry no API key — a record’s self-signature is the credential.

4 · How the trust actually works

• Self-certifying identity. An identity is a did:key — the DID encodes the ed25519 public key directly. Whoever holds the private key controls the identity; there is no issuer to bribe and no account to phish.
• Key lifecycle. A holder can rotate to a successor key or revoke outright, each as its own signed record. State is computed by folding those records in log order — revocation is terminal.
• Sybil tax, not gatekeeping. Registration is open, but each identity must carry a small proof-of-work stamp — trivial once, expensive at flood scale — plus rate caps. Fail-closed: no valid work, no write.
• Anchored root. The append-only log’s root is signed by our XRPL checkout wallet (rJRUQ…tPNU), which is itself attested on-ledger. That turns “the log says so” into a public, wallet-backed commitment: a rollback or tail-swap after a root is published no longer reconciles, and the service refuses to serve a log that contradicts its own signed root.

5 · Honest about the scope (v1)

What v1 does: self-certifying identities, signed attestations, settlement receipts, offline verification, a tamper-evident log, and a wallet-signed root you can check. Money-adjacent receipt records are now live — cleared by a hard cross-verifier gate: our verify path is proven, against the Wycheproof and “Taming the many EdDSAs” speccheck ed25519 vectors, to reject signature malleability and non-canonical points exactly like the strict verifier used on-chain, so a receipt can never verify here yet fail there. What v1 does not claim yet: this is not a Certificate-Transparency-grade system — it publishes a signed root but does not yet offer gossip-based split-view detection or cryptographic consistency proofs between roots. We’ll say so plainly here until it does.

The fuller case for building this way: Verify, don’t trust → · Trust overview →