TRACE Registry
The public accountability layer for TRACE claim anchors. Each entry records the Merkle root of a batch of signed TRACE Trust Records, committed to this repository as an append-only record. Git's commit history is the tamper-evidence layer: any rewrite of a published entry diverges the commit hashes that auditors and mirrors have already observed.
Current Registry State
The registry currently contains one entry (registry/2026/06/12.ndjson). It is
a software-only example anchor with advisory enforcement and a zeroed measurement,
committed as a launch-day example. It does not represent a production Trust Record,
and no production entries have been anchored yet.
The anchoring pipeline is live and runs on a schedule, verifying producer signatures before it anchors anything. A scheduled run with nothing to anchor is a no-op, so the gap since June reflects claim volume rather than a stalled pipeline.
The anchor construction (canonical claim bytes, leaf hashing, RFC 6962 Merkle tree, inclusion proofs) is specified in docs/anchor-format.md. A third party can implement a verifier from that document alone; the reference tools in tools/ are one implementation.
Status. The format, reference tooling, schema validation, and a first real entry (registry/2026/06/12.ndjson) are live. Scheduled anchoring is operational and
trace-verifyis published on PyPI. What is missing is volume: one entry, one producer, and no mirror we do not operate. See ROADMAP.md for what that means and what would change it.
Why this exists
Anyone holding a TRACE trust record and its inclusion proof can verify that the record was anchored in this registry without trusting the operator who issued it, using only this public git history and the verifier below. No single operator controls the audit trail.
Registry Format
Each daily file in registry/YYYY/MM/ is newline-delimited JSON, one anchor
entry per line, validated by CI against
schema/registry-entry.schema.json:
{"ts": "2026-06-12T18:09:41Z", "merkle_root": "sha256:9279...bada", "leaf_count": 1, "producer": "cmcp-gateway/0.1.0", "batch_id": "2026-06-12-001"}
Entries are append-only. See docs/anchor-format.md for field semantics.
Verifying a claim
You need three things: your signed claim (Trust Record), the inclusion proof your producer gave you, and the registry entry for the batch. Then:
git clone https://github.com/agentrust-io/trace-registry.git
cd trace-registry
python tools/verify_inclusion.py \
--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:9279..., ts 2026-06-12T18:09:41Z)
Exit code 0 means the claim is proven included; 1 means it is not. The
verifier is a single standard-library Python file, so you can audit it (or
reimplement it from the spec) rather than trust it. The samples/ files above
are a real anchored example you can use to exercise the tooling.
Inclusion verification proves the signed claim bytes were anchored at the entry's timestamp. Validating the claim's signature against the producer key is a separate TRACE step.
Anchoring claims
Producers batch signed claims and anchor them with:
python tools/anchor.py claim1.json claim2.json \
--producer my-gateway/1.0 --proof-dir proofs/ \
>> registry/2026/06/12.ndjson
This emits the registry entry line and writes one inclusion proof per claim to hand back to claim holders.
Canonical Registry
This repository exists for independence: TRACE claim anchors can be checked without trusting any single operator's infrastructure, and the git history is auditable by anyone.
Community
Questions, feedback, integration help: Discord.
License
Dual: Apache-2.0 for code (src/, tools/, aggregator/, tests/, .github/) and
CC BY 4.0 for registry data, proofs, schemas and documentation. See LICENSE.
The code was previously under CC BY 4.0, which Creative Commons itself recommends against for software: no patent grant, no software-tailored warranty disclaimer, and not OSI-approved. Mirroring this registry means running that code, so it needs a license written for software.
Release files for trace-verify 0.3.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| trace_verify-0.3.1.tar.gz | 64.7 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| trace_verify-0.3.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 77.9 kB
Release files / trace_verify-0.3.1.tar.gz
| Download URL | trace_verify-0.3.1.tar.gz |
|---|---|
| Size | 64.7 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
ce51991338543d45517102c820175df74aa8d7f7417bbb6a8909e7ccf9ebd7b6
|
|
BLAKE2b-256 checksum How to use checksums |
10b7ab7fa722c643d9bdb6f2a611d54efea2d24aee44924b931d620d67b19718
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 21, 2026.
Transparency logRelease files / trace_verify-0.3.1-py3-none-any.whl
| Download URL | trace_verify-0.3.1-py3-none-any.whl |
|---|---|
| Size | 13.1 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
243f8edc36bc94ed65eaab9abb8b9be9f7e84458c71f85ef6ceb15017de62c72
|
|
BLAKE2b-256 checksum How to use checksums |
611883514d9a802276c93df5cd13c2952e30333aa0e5270ecd569319713e3950
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 21, 2026.
Transparency log