Verify the chain

What the chain proves — and what it does not

It proves that a given root existed by a given time.

It does not prove that any measurement is true.

Those are two different claims and we never blur them. Anchoring stops a record being altered after the fact; it says nothing about whether the observation was correct when it was made. Anyone telling you otherwise about any anchored dataset — including ours — is overselling it.

The published snapshots

This list is current as of 2026-08-09. It is a dated list, not a live view — if you are reading it much later, there may be more snapshots than appear here. Compiled from the published snapshot manifests. Each entry is verifiable independently at https://gist.github.com/<gist_id>.

Each snapshot is cited by identifier only. An account-qualified link stops resolving if the publishing account is ever renamed, and a citation inside a permanent record should not depend on a name that can change.

Which columns the chain actually commits to. The published entry for each snapshot carries exactly these fields: snapshot_id, captured_at_utc, merkle_root, prev_root, method. So Captured and Root are checkable against the entry itself. Endpoints is not — it comes from our own manifest and is not part of the anchored commitment. It is shown because it is useful, and marked because presenting it identically to the checkable columns would imply a guarantee it does not carry.

Do not read the Endpoints column as a trend. The first snapshot was a capped sample, not a census, so the step from it to the second measures a change in what we looked at — not growth in the population. The selection rule it used is written out on the methodology page, where it is marked retired.

Check the chain links

Each snapshot names its predecessor's root. Fetch any two consecutive snapshots and confirm that the later one's prev_root equals the earlier one's merkle_root, byte for byte. A break anywhere means the sequence you are holding is not the sequence that was published.

For the most recent entry, REL-SNAP-004, the root is 1d0e1fe621dde25e3f15bf500f2e9e16c86fb184c5ada78a77c4374c93c7f872 and it follows 5f2db20bcf3a3f3c3760fa2f81b4cda130d3d1d6fc5d855d3ef4c9b4f6d9534f.

Recompute a root

The method is stated so it can be reimplemented without our code:

1. A leaf is the SHA-256 of the canonical JSON encoding of one record.
2. Leaves are sorted ascending as lowercase hexadecimal strings.
3. A parent is the SHA-256 of the two child hex strings concatenated as text.
4. A level with an odd number of nodes duplicates its last node.
5. A single leaf is its own root. An empty set is rejected rather than given a root.

Canonical JSON means: object keys sorted ascending, arrays left in order, integers only — a non-integer is rejected rather than rounded, because two implementations formatting the same float is a classic way to produce different bytes for the same value — undefined keys dropped, explicit nulls kept, no whitespace.

The limitation, stated rather than buried

The published export is a derived view of the archive. It deliberately omits the raw error text a server returned, because republishing a third party's own words on a page about that third party is not something a record should do. One consequence follows directly: an export record cannot be re-hashed into its own leaf.

So every exported record carries its leaf_hash instead, and the chain you can verify runs:

leaf_hash → inclusion proof → merkle_root → published snapshot

That establishes the leaf is committed to the published root. It does not establish that the leaf corresponds to the record shown beside it — proving that step requires the raw record, which the archive holds. This is the same shape as a transparency log, and the same limit applies to those. We would rather state it than let a reader discover it later.