A registry you don’t have to trust

Almost every “trust” feature on the agent web is an island. Each service asks you to trust its database: log in here, take our word for that, believe the number on the dashboard. The Trust Registry is the opposite bet — a shared, public log where the only thing you ever have to trust is math you can check yourself.

When an autonomous agent acts on your behalf — clears a party, prices an asset, settles a split — it needs to know two things: who made a claim, and whether the claim is real. Today it gets those answers by trusting whoever hosts the data. That is fine until the host is wrong, compromised, or simply gone. A trust layer that lives inside one company’s database is not a trust layer. It is a single point of failure with good branding.

Trust as a database is the problem

A private database can say anything. It can be edited after the fact, rolled back, or quietly reshaped, and you would never know — because the only record of what it “said” is the database itself. Asking a third party to trust that arrangement is asking them to trust your operations, your staff, your uptime, and your good intentions, forever. Most of the internet runs exactly this way, and mostly it works, right up until it doesn’t.

The fix is not a better-run database. It is removing the need to trust the database at all — making every claim carry its own proof, so a reader checks the proof instead of trusting the source.

What a registry that needs no trust looks like

Our Trust Registry is a non-custodial, multi-writer log of signed claims. Three properties make it checkable rather than trustable:

• Self-certifying identity. An issuer is a did:key — a decentralized identifier that is its own public key. There is no account to phish, no certificate authority to bribe, no login. Whoever holds the private key controls the identity, and the identity announces the exact key that must have signed anything it publishes.
• Content-addressed records. Every record’s ID is the SHA-256 of its own canonical bytes, and its ed25519 signature covers those same bytes. The ID and the signature both commit to the identical content, so a record cannot be altered without breaking both at once. There is nothing to trust about us here — only arithmetic to reproduce.
• The registry holds no keys and issues nothing. A record’s own self-signature is the only write credential. We cannot forge an entry on anyone’s behalf, because we do not have anyone’s key. Non-custodial is not a promise; it is the architecture.

Tamper-evident, and anchored to a public ledger

Individual records prove their own content. The log proves order — that the Nth entry really is what we said, appended Nth, never reordered, edited, or dropped. It is a hash chain: each entry commits to the one before it, so any edit, reorder, or deletion breaks the chain from that point forward, visibly.

The chain’s current head is periodically signed by our on-ledger XRPL checkout wallet — the same account, published in our machine-readable attestations, whose control we already prove on-chain. That turns “the log says so” into a public, wallet-backed commitment to a specific history. If the log were ever rolled back or had its tail swapped after a root was published, the two would no longer reconcile, and the service refuses to serve a log that contradicts its own signed root. A quiet rewrite is not just detectable; it is self-defeating.

Verify it yourself — offline, nothing phoning home

The claim of the whole thing is “don’t trust us,” so we ship the means to not. Reads are open — no key, no account. Any record can be checked with a standalone verifier: pure Python plus the cryptography library, zero install of ours, nothing calling home. It recomputes the canonical bytes (RFC 8785 JCS), checks the ID, verifies the ed25519 signature, and confirms the issuer DID really is the key that signed it. VALID means authentic and unaltered. Tamper with one byte and it says INVALID, with the reason.

And you do not need our software to publish, either. The issuer client is one file: generate a key, register a did:key identity, publish signed attestations — the key never leaves your machine, and only the signed record is sent. Everything the registry does, an independent party can reproduce and check.

A network, not a list

We already published a curated, single-writer file of signed attestations — attestations.json — and it proved the pattern: fetch it, check the signatures, don’t take our word. But only we could add to it. It was a trust anchor, not a network. The registry is the multi-writer version: any issuer — a person, a company, or an autonomous agent — registers its own identity and publishes its own signed claims to the same verifiable log. It is already more than one voice: our own operator identity and the Sentinel settlement edge are both registered issuers in it today, and Sentinel publishes settlement receipts that make a settlement externally verifiable without Sentinel storing per-settlement state. That is trust as a protocol, not a product.

Honest about what v1 is not

We would rather tell you the edges than let you assume them. v1 publishes a wallet-signed root, but it is not yet a Certificate-Transparency-grade system: it does not offer gossip-based split-view detection or cryptographic consistency proofs between roots. We say so plainly on the registry page and will keep saying it until it does. Money-adjacent receipt records ship only after clearing a hard cross-verifier gate — our verify path is checked, against public adversarial test vectors, to reject signature malleability exactly like the strict verifier used on-chain, so a receipt can never verify in one place and fail in another. Proof, not adjectives — including proof of where the proof stops.