THE AUDIT
Don't trust the desk.
Check it.
RUNS IN YOUR BROWSER · NOTHING TO INSTALL · NOTHING TAKEN ON FAITH
The whole claim of the record is that every session's levels were published before the tape played out and scored after — and never quietly rewritten. Claims like that are cheap. So the desk commits to its record cryptographically, and this page is where anyone can catch it lying.
Every time the record changes — a print lands, a session resolves — the server writes a new link in a hash chain: a SHA-256 of the entire record in a fixed canonical form. Since chain v2, each link also carries a link hash that folds in the link before it, and the server refuses to seal any record that rewrote what an earlier link committed: levels are frozen at the print, an outcome once scored never changes, and no row ever leaves. The current link is public. Right now, your browser is downloading the public record, rebuilding the canonical form from scratch, hashing it, and comparing.
What just happened
This page fetched two public endpoints: /api/prints (the record, the same data the table draws) and /api/vault (the commitment). It rendered every session into the canonical form — fields in a fixed order, sessions in date order, pipe-separated — hashed the result with SHA-256 using your browser's own crypto, and compared it to the hash the server committed to. It then pulled the whole chain from /api/vault?chain=1 and checked every link against the one before it — each link's stated previous-hash must be that link's actual hash, and the session count must never shrink. For v2 links it goes further: it recomputes each link hash from the one before, then downloads the committed record behind the newest links, hashes each one against its link, and compares them row by row — every session the earlier link held must still be there, its print untouched, its outcome (once it had one) identical. The verdict above says how many links and transitions were checked. The code is in this page's source, unminified, for reading. Canonical form v2 since AUG 15, 2026 — the pocket-event fields joined the commitment; links sealed earlier committed the v1 form, and each link states its version.
Being exact about what that proves. Links sealed before chain v2 are weaker than this page once said: each is a fresh snapshot of the whole record, and its previous-hash was stored beside the hash, not inside it. So a v1 link proves its own snapshot has not changed since it was sealed — it does not prove that snapshot agrees with the one before. A past row rewritten and re-sealed would have produced a perfectly valid-looking v1 link; the pointer check above cannot see that, and never could. Anyone can compare the v1 snapshots themselves — every one downloads from /api/vault?canonical=<n>. From v2 on, the rewrite is refused at the seal and caught here if it ever got through. What no self-reported structure can catch is a chain rebuilt end to end, and any page claiming otherwise is overselling. That is precisely what the Bitcoin anchors are for: a rebuilt chain cannot acquire a timestamp that already exists in someone else's blockchain. The two together are the argument; either alone is not.
A match means the record you can see is byte-for-byte the record the desk most recently committed to — nothing altered, removed or slipped in since that seal. Whether that seal agrees with every one before it is the chain's job, above. A mismatch would mean the record was edited after commitment, and no explanation from us would matter. That is the point: the check works without trusting the desk, and it is why the losing sessions stay on the page.
The Bitcoin anchor
The chain proves the record hasn't been rewritten since it was committed. It cannot, by itself, prove when it was first committed — a desk could theoretically build a flattering record this morning and seal a fresh chain over it. So since AUG 14, 2026 every commitment hash is also submitted to the public OpenTimestamps calendars, which aggregate it into a Bitcoin transaction. A Bitcoin block timestamp cannot be backdated by us, by Netlify, or by anyone else.
CHECKING THE ANCHOR…
To verify independently: download both files, then drop them into the verifier at opentimestamps.org (or run ots verify). The .txt is the canonical record; the .ots is Bitcoin's receipt for its SHA-256. A v2 link anchors its link hash instead, so it comes with a third file — two lines: the previous link hash, then this record's hash — and the .ots is the receipt for that. One receipt then pins the record and, through the link hashes, every v2 link behind it. Sessions dated before an anchor whose Bitcoin timestamp you can check yourself existed by that timestamp — that is the whole point. Anchors confirm on-chain within hours of submission.
What this still does not prove
Anchoring began Aug 14, 2026; sessions recorded before that date are proven to have existed by their first anchor, not by their session date. And no anchor proves the 22:03 publication minute — for that, the print is pushed to member desks at publication, and the share cards posted publicly carry the day's hash. Chain, anchor, push and post together are the claim. The desk states plainly what each leg can and cannot carry.
THE RECORD ITSELF: EVERY SESSION, SCORED →