Independently verifiable
Verify our record.
When we publish a reading, we publish a commitment to it at the same moment: a fingerprint of the reading, written into a public log as the reading goes out. The commitment is what a later edit to that reading would have to contradict. This page explains what we commit, what a commitment does and does not prove, and how to check it without taking our word for it.
Why we anchor
Deleting an embarrassing miss wouldn't stay secret.
What this does
We commit each reading as we publish it: we take a fingerprint of the reading and append it to a public log, so the reading and its fingerprint go out together. The log only ever grows — entries are appended, never rewritten — so what we committed for a date stays there whatever we publish afterwards.
A date can be given a receipt more than once. Each run of the daily job that publishes a reading issues its own receipt with its own fingerprint. When that fingerprint is appended to the log, it is appended as its own entry. If a later run publishes for a date that already has a receipt, the earlier receipt, and its log entry where it has an entry, stay where they are. A later receipt is a further publication with its own publication time. It does not remove or change an earlier receipt. On the record, the receipt linked is the latest for that date, and any publication date shown is the date of the earliest publication.
This page also describes, below, how the log that carries these commitments is itself timestamped on the Bitcoin blockchain over time. Where the commitment for any individual reading currently stands is shown on the record itself, beside the reading.
The earlier frozen record
A fixed set of earlier published readings is frozen into a single fingerprint, and that fingerprint is timestamped on the Bitcoin blockchain. That record stands on its own, separate from the log above; what follows is the detail behind it, for a reader who wants to go further.
It fixes a specific set of readings — the dates shown below, and no others — against a timestamp on the Bitcoin blockchain. It also binds us going forward: anything we publish for those dates later has to match what was already timestamped, or the mismatch is public.
- Record root
- Frozen record root (SHA-256): 699ca7f132679ea95531866b271479124bf6a44d2a25154bdce65ef0f00f0e4b
- Tree size
- Tree size: 45 leaves (one per matured reading; no extra leaves)
- Readings covered
- Readings covered: 45 matured readings, 2026-04-26 to 2026-06-09
- Checkpoint id
- Checkpoint id: 393ecb756c11b290b9abbb5a0aa18176e947a750903b5f02e892bd0dc66db551
- Source ledger
- Source ledger (SHA-256): 2b9e43e96ea98ac290b739c2dc563f17c8758454658b79bd11ad27bae647da2f
- Bitcoin timestamp
- Confirmed on the Bitcoin blockchain in block 955,461, anchored as of 2026-06-26.
The ongoing commitment log
Separately from the earlier frozen record above, the log that carries the commitment for each reading is itself checkpointed on a rolling basis — roughly once a day — using the same construction described above for the frozen record. Each checkpoint root covers every entry appended up to that point, not just the entries added that day, so a single Bitcoin timestamp on a checkpoint covers everything beneath it.
A checkpoint only protects what it covers once its own Bitcoin timestamp is confirmed on-chain — a newer checkpoint existing does not by itself protect anything until its own timestamp is confirmed. Whether the covering checkpoint for a specific reading is confirmed or still pending is shown beside that reading on the record.
What this does and does not show
What it shows: our published readings through June 9, 2026 are fixed and cannot be quietly edited without changing the published fingerprint, and that fingerprint is timestamped on the Bitcoin blockchain — so the record is tamper-evident against back-dating.
What it no longer shows: the readings themselves have been withdrawn from publication. For this window a reader can check structure — that each published hash belongs to the anchored tree, in the position claimed for it — but not content: nothing published here reveals or confirms the entry behind any of those hashes, and what each leaf committed was the complete stored row for its date, including the internal run metadata kept alongside the reading, rather than a selected subset of its fields. That is a description of this window only, and nothing here describes how any later reading is committed. We are describing removal from publication, not erasure: we are not claiming these values have been deleted from every place they have ever existed.
What it does not show: nothing here is a forecast, a recommendation, or investment advice, and it says nothing about future performance. This is research tooling, shown pre-launch.
How to check it
To check a reading we publish now, open that reading on the record and follow it through to its receipt: the receipt shows the fingerprint we committed for it and where that fingerprint sits in the log, and the check runs in your browser.
Checking the earlier frozen record
Below is the check itself, written out in full, using files published on this site. It is technical on purpose: the exact steps are what let a stranger confirm the anchoring without taking our word for it. You do not have to follow them to have understood the rest of this page.
- Download the published proofs. Get the per-date inclusion proofs from the genesis directory — a file for each anchored date, plus an index — and note the published root from clean_anchor_manifest.json. Each proof file carries that date's leaf hash, its position in the tree, the audit path from that leaf to the root, and the root itself. It does not carry the entry behind the hash: those values were withdrawn from publication and are not served here. proofs/index.json · clean_anchor_manifest.json
- Check an anchored hash against the frozen root. Take any date's proof file and walk its audit path upward from the leaf hash, combining hashes as described below. The walk reaches the frozen record root printed above. That confirms the hash published for that date is among the hashes the timestamped root was built over, at the position claimed for it, and that neither the hash nor its position can have been changed after the timestamp without changing the root. It does not confirm which entry produced that hash: those values are no longer published, so that check is no longer available to a reader.
- (Optional) Confirm the construction. Each leaf is SHA-256(0x00 followed by the entry's bytes); each interior node is SHA-256(0x01 followed by the two child hashes). This is the standard RFC 6962 Merkle tree, built over 45 leaves. Because every node in the tree is a hash of fixed bytes, the walk is exact and language-agnostic: a Python, JavaScript, Go, or Rust implementation of the same rules reaches the same root.
- Confirm the Bitcoin timestamp. Download clean_genesis_root.ots — the OpenTimestamps proof. The OpenTimestamps proof commits that exact 32-byte root to Bitcoin block 955,461. Look up block 955,461 on any Bitcoin block explorer to see its on-chain timestamp; because the proof commits the root (not the readings file), it shows the root existed on or before that block — it could not have been back-dated. This makes the root itself tamper-evident against back-dating, which is what the inclusion check above is measured against.
Download the record
- proofs/ — the per-date inclusion proofs — each anchored date's hash, its position, and its audit path. The entries behind those hashes are not included: they were withdrawn from publication.
- clean_anchor_manifest.json — the frozen facts (root, tree size, checkpoint, source ledger).
- verify_clean_anchor.py — the self-contained verifier for the published-readings path. With the readings withdrawn there is no readings file left for it to check for this window; it stays published so the construction it implements remains inspectable.
- README.md — the full byte contract and construction, written out.
- clean_genesis_root.ots — the OpenTimestamps proof that commits the frozen root to the Bitcoin blockchain.