Register as a producer
Publish anchors for your own signed trust records under your own key. The conventions, naming, and submission path are documented in the repository.
Read the contributor guide →Counted on main at commit 4697f2c. Two entries and one checkpoint is the true size of this log today, and we would rather publish the real number than a flattering one. Clone the repository and run python -m pytest to check the test count for yourself.
A registry's job is to be believed by strangers
Signatures prove that records are authentic. They do not prove that everyone is being shown the same set of records. A log operator who can quietly serve one history to an auditor and another to everyone else has defeated the point, and no amount of signing catches it.
So "trust our database" fails in exactly the situations a registry exists for: disputes, audits, and adversaries. The requirements that fall out of that are narrow and testable. The log must be append-only with cheap proofs. It must verify offline. Nothing sensitive should leave the producer by default. And its integrity should eventually be anchored somewhere the operator does not control.
Checkpoint 1, as published
This is the first signed checkpoint of the log, taken verbatim from registry/2026/09/01.ndjson. The key_id is the raw 32-byte Ed25519 public key in hex. A verifier needs nothing else from us to check the signature.
log_id trace-registry/v1
key_id bc133259c094f63694b4ec48a295d7501a9a0cd536df5631fb4663c155f7bc90
mmr_size 1
root 3af8ddf2c1f429bb4fc670437e48640887f60de809b18f8ccea55fefb0c6639a
prev_size 0
timestamp 2026-09-01T21:39:37Z
verify signature checks OFFLINE from key_id alone
Checkpoints carry commitments, never claim content. A checkpoint is a few hundred bytes describing the shape of the log: its size, its root, and the size and root of the checkpoint before it. Trust-record payloads stay with whoever produced them.
Four moving parts, none of which require trusting the operator
1
A producer signs a trust record
The record is signed where it is produced, under the producer's own key. The registry never sees a private key and does not sign on anyone's behalf.
2
Only a digest is anchored
What lands in the registry is an anchor leaf derived from the exact signed bytes under Anchor Format v1, not the record. Recomputing the leaf from a changed record produces a different value and stops matching.
3
The log appends, and never rewrites
Entries accumulate in an append-only Merkle Mountain Range. Appending never rebalances the structure, so proofs issued earlier stay valid, and inclusion and consistency proofs stay cheap as the log grows.
4
A signed checkpoint commits to the history
The scheduled anchor pipeline emits a signed checkpoint carrying the log's size and root plus the previous checkpoint's size and root. That chained pair is what lets a third party check that each checkpoint extends the last rather than replaces it.
The verification runs on your machine, not ours
There is no verification endpoint to call, because a verification endpoint you have to trust is not verification. The registry is files in a public repository and the verifier is a package you install.
1
Install the verifier
Terminal
python -m pip install trace-verify
2
Clone the registry
The entire published history is in the repository. There is nothing held back on a server.
Terminal
git clone https://github.com/agentrust-io/trace-registry cd trace-registry
3
Verify the checkpoint chain
Checks each checkpoint's signature from its own key_id, then checks that each one extends the last and matches the raw entries it claims to cover.
Terminal
python tools/verify_checkpoint_chain.py \ registry/2026/06/12.ndjson \ registry/2026/09/01.ndjson
What a registry entry is, and what it is not
Registration attests to inclusion and time. It is not an endorsement of content, a certification of the producer, or evidence that any claim inside a record is true. Four specific limits are worth stating here rather than leaving to be discovered.
| Limit | Why it stands |
|---|---|
| Consistency, not coverage | The checkpoint chain proves the consistency of what it covers. It does not prove that the registry covers everything it could have. Completeness is a property of producers keeping their own records, not something a log can assert about itself. |
| The June 2026 entry is outside the chain | It predates checkpointing and is deliberately not folded in retroactively, which is the same rule the chain verifier applies. Backdating an entry into a chain would make the chain say more than it checked. |
| No external witness receipt yet | Anchoring the registry's own history into a transparency service the registry does not operate is in progress in public, and no receipt has come back and verified offline yet. Until one has, the anti-split-view property is a roadmap item, not a feature. |
| One producer key is single-use by construction | The producer key behind the first anchored record verifies that record and will never sign another, because the demo that produced it generates keys per run and never persists private ones. That is a property of that entry, not a general guarantee. |
A witness attesting to more than it checked is worse than no witness. That principle is why the limits above are on this page instead of in a footnote, why the entry counts here are the real ones, and why an external receipt will be announced when it verifies rather than when it is arranged.
Three ways in
Run a mirror or a witness
Single-operator dependency is a weakness we name rather than hide. Independent mirrors and independent witnesses both remove it, and both are open to anyone.
Mirroring guide →Attack the claims
The most useful contribution is a demonstration that something on this page overstates what the code actually does. Open an issue in public.
Open an issue →