Daily measurement roots

Every UTC day, Agenstry computes a SHA-256 Merkle root over 5 classes of measurement we recorded that day. Anyone with read access to the same source rows on the same date can re-compute the same root. If our DB ever diverged from a published root, the discrepancy would surface in seconds.

Algorithm

1. For each UTC day, collect rows from 5 append-only sources: agent_day_states (an immutable end-of-day capture of each agent's graded columns — v1 and v2 dates read the live agents table instead, which is why they are replayed under their own version), agent_card_snapshots (every card change), probe_runs (every probe), agent_revenue_snapshots (every per-window revenue settlement), and agent_passports (every passport issued that day).
2. Hash each row into a 32-byte leaf using SHA-256 over a NUL-separated, domain-prefixed serialisation of its key columns. The prefix (agent\0…, snapshot\0…, …) prevents cross-table collision.
3. Compute a Merkle root per sub-tree using the RFC-6962 odd-leaf-carry variant (no duplication, which avoids the second-preimage attack on classic Merkle).
4. Prefix each sub-root with its own label and a colon — sha256(label + ":" + sub_root_hex) — then Merkle-fold those 5 hashes, in the fixed order agents → snaps → probes → revenue → passports, for the day's top-level root. The order is append-only: a new tree kind goes on the end under a new version number, never inserted, or every prior root silently changes meaning.
5. Persist the root, the row counts, computed_at and the root_version in transparency_roots. The row is never updated; a mismatch on recompute is a flag, not a silent fix. Today's version is 3; every date is replayed under the version it was built with, and /api/transparency/<date>.json reports that version so you know which recipe to apply.
6. Anchor the root in Bitcoin with OpenTimestamps, so even an attacker with write access to our database cannot rewrite a published day. The timestamped value is the root itself: its 32 bytes, not a hash of its hex. We submit it to several public calendars, which fold it into a Bitcoin transaction within hours. A day reads pending until its proof carries a Bitcoin block attestation, and anchored in Bitcoin block N only after that attestation has been checked against the block header. A timestamp proves the root existed no later than that block. Roots computed before anchoring began were stamped later, so their block date is the day we stamped them, not the day they were computed.

Reproducibility kit

The reference implementation is the Algorithm section above — that prose is the specification, which is what /api/transparency/daily-root.json itself names as the source of truth (algorithm_url). The repository is private, so a link into it would 404 for every reader. The JSON API at /api/transparency/daily-root.json returns the latest root + row counts; per-date lookup at /api/transparency/<date>.json (replace <date> with any ISO YYYY-MM-DD).

Verify an anchor yourself. Download a day's .ots proof from the table below and run ots verify -d <merkle_root> agenstry-root-YYYY-MM-DD.ots with the OpenTimestamps client (pip install opentimestamps-client), passing that day's full 64-character root as the digest. The client checks the proof against a Bitcoin node, so you rely on neither us nor the calendars. A pending proof can be completed first with ots upgrade.

Published roots · last 30 days

Same data, machine-readable: /api/transparency/daily-root.json. Want to verify? Pull the source rows for a date via the federation feed (/api/feed/all.jsonl.gz), run the algorithm specified above, compare the root you compute with the row above.