Docs menu
Interop

Interop: the TRACE Registry

The TRACE Registry is a public, append-only registry of anchors for signed TRACE Trust Records, maintained in the open by its own project. Its checkpoint layer uses the Checkpointed Local Log (CLL). This page lists what the registry records, which parts of CLL it uses, and how anyone can check one of its entries with the published tools.

What the registry records

Each entry is one line of newline-delimited JSON in registry/YYYY/MM/DD.ndjson, recording the Merkle root of a batch of signed Trust Records: a timestamp, the batch root, the leaf count, the producer and a batch id. Entries are validated against the registry's schema and are append-only. A claim's membership in its batch is shown by an RFC 6962 inclusion proof into that batch root — the registry's own construction, specified in its anchor format, not a CLL part.

At the time of writing the registry holds two entries, and its README states that neither is a production Trust Record.

Which parts of CLL it uses

CLL partUsedHow the registry uses it
Append-only MMR over the logyesEntries anchored through the registry’s aggregator fold as one leaf each into a single registry-wide Merkle Mountain Range (log id trace-registry/v1). Today that is one entry: the 2026-06-12 example predates this layer and is deliberately never folded in.
Signed checkpointyesAn entry anchored this way carries an mmr_checkpoint: size, root, the previous size and root, an Ed25519 key id and signature. One exists so far, on the 2026-09-01 entry (MMR size 1). The registry reuses the field set and MMR construction of the CLL reference implementations, pinned against the same 39-node test vector.
Consistency proof between checkpointsimplemented, not yet exercisedEach later checkpoint is to carry a proof that it extends the previous one; with a single checkpoint there is no earlier one to extend yet. The verifier also rebuilds the MMR from the entries themselves and compares it with each checkpoint.
Witness receipt over a checkpointyes, onceCheckpoint 1 was registered with the public witness at witness.agentactioncapsule.org, and the returned receipt is published in the registry as an evidence packet. Later checkpoints are not yet submitted automatically.
MMR inclusion proof per recordnoPer-claim inclusion uses the per-batch RFC 6962 proof described above.

The registry documents its CLL layer in docs/mmr-checkpoint.md.

Check an entry yourself

Three questions, one command each, using the registry's published verifier. Nothing here needs an account or a key of your own; the two public keys in the last command are pinned as arguments and never fetched.

pip install "trace-verify[witness]"
git clone https://github.com/agentrust-io/trace-registry && cd trace-registry

# 1. Is this claim in its batch, under a valid producer signature?
trace-verify --claim samples/example-trust-record.json \
  --proof samples/inclusion-proof.json --entry registry/2026/06/12.ndjson
OK: claim is included in batch '2026-06-12-001' (root sha256:9279111218532d83…, ts 2026-06-12T18:09:41Z, …), signature valid

# 2. Is the checkpoint chain consistent, and does it match the entries?
trace-verify chain registry/2026/06/12.ndjson registry/2026/09/01.ndjson
OK: 1 checkpoint(s) verified, chain-consistent and matching the raw entries (mmr_size 1, …)

# 3. Does the witness receipt cover checkpoint 1?
trace-verify receipt \
  --checkpoint docs/evidence/witness-2026-09-07/checkpoint-1.json \
  --response docs/evidence/witness-2026-09-07/witness-post.json \
  --expected-log-id trace-registry/v1 \
  --registry-key bc133259c094f63694b4ec48a295d7501a9a0cd536df5631fb4663c155f7bc90 \
  --witness-key 39bb654c9dc0afe1c0edef0deffaa69099b8518836c9ba26e0491535840f96b5
{ "verified": true, …, "limits": { "witness_time_established": false, "registry_continuity_established": false, … } }

Each command exits 0 on success and non-zero otherwise (1 when a check fails). Output above is from trace-verify 0.4.2 against registry commit 4ae8c491ee1a2063b01780021dd31abe3f5560f9, abbreviated with …. A claim with one changed field fails the first check, and a receipt checked against a different witness key fails the third.

What a pass does not establish

  • Not the claim's contents. An anchor shows a signed Trust Record existed in a particular form and was committed at a particular time — not that the agent behaved correctly or that the record's description of its runtime is accurate.
  • Not a witness time, and not continuity. The receipt check reports these as limits, and both read false for this capture.
  • Not more than one Transparency Service. Registering the same checkpoint with several is supported; one operator is demonstrated so far.

The registry's own LIMITATIONS.md states these boundaries in full.

Read more

This is a technology interop note, not an endorsement or a commercial relationship. It describes how one independent project uses CLL, as that project documents it in its own public repository.