Skip to main content

License TRACE Spec Discord

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-verify is 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)

Source distribution for trace-verify 0.3.1
File Size Uploaded
trace_verify-0.3.1.tar.gz 64.7 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for trace-verify 0.3.1
File Interpreter ABI Platform
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 log

Release 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

Release history Release notifications | RSS feed

0.4.2

2 release files

0.4.1

2 release files

0.4.0

2 release files

This release

0.3.1 This release

2 release files

0.3.0

2 release files

0.2.0

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page