Checking a sealed record
This page supplies a record and the chain of fingerprints (SHA-256 hashes) that joins it to a single daily fingerprint, the root of a Merkle tree. It does not supply the root that chain must reach. Your browser fetches the root from a public GitHub repository, at a fixed commit, and does every calculation itself.
The figure is a baseline. It is not the project’s judgment. It is a 70:30 blend of the Polymarket price at the time (59.15 per cent, recorded inside the record) and a base rate of 45 per cent, rounded and kept between 15 and 85. The base rate belongs to the class the project’s classifier assigned: technology questions in prediction markets. It can show that a record existed unchanged by a certain time. It says nothing about forecasting skill.
Written, by the record’s own account, at 16:00:15 UTC on 18 July 2026. That time comes from the project’s own clock. Step 6 gives one the project does not control.
The question has been decided. The final was played on 19 July 2026, and Polymarket settled the market Yes at 01:14 UTC on 20 July 2026 (read from Polymarket on 26 September 2026). This page does not score the record against that outcome.
Show the record’s 878 canonical bytes
(computed in your browser when the check runs)
- 1Canonical bytesCheckingWritten out in one fixed byte order (canonical JSON), under the project’s older recipe (sorted keys, then JSON): 878 bytes. For plain JSON this is byte-identical to RFC 8785.
- 2FingerprintCheckingSHA-256, computed by your browser, compared with the leaf in the proof.
- 3Path to the rootCheckingCombined with 7 neighbouring fingerprints, each pair sorted and hashed.
- 4The published rootCheckingFetching from raw.githubusercontent.com, repository cberzins1973/luu-attestation-anchors, commit 0c0b29d8, file daily-seals/2026-07-18.json… view this file on GitHub
- 5Shape of the treeCheckingThe published file gives the number of leaves and the depth of the tree. A proof in a tree of depth d needs d minus 1 steps. This proof has 7.
- 6An outside clockCheckingAsking GitHub when commit 0c0b29d8 was pushed…
Change one character
Edit the record. Steps 1 to 3 run again as you type. The published root in step 4 does not move.
The whole day’s tree
The figure is a baseline. It is not the project’s judgment. The record’s reference figure is 50 per cent, a fixed value the project stores for every Metaculus question, because the project does not read Metaculus’s community forecast. Blended with a base rate of 50 per cent it gives 50 per cent. It can show integrity and timing only. It says nothing about forecasting skill.
The record’s content gives 15:59:36 UTC on 3 February 2026 as the time its reference figure was captured. This older record carries no creation time of its own inside the hashed bytes, so the database’s time is not offered as evidence. The capture time comes from the project’s own clock. Step 6 gives one the project does not control.
Show the record’s 551 canonical bytes
(computed in your browser when the check runs)
- 1Canonical bytesCheckingWritten out in one fixed byte order (canonical JSON), under the project’s older recipe (sorted keys, then JSON): 551 bytes. For plain JSON this is byte-identical to RFC 8785.
- 2FingerprintCheckingSHA-256, computed by your browser, compared with the leaf in the proof.
- 3Path to the rootCheckingCombined with 15 neighbouring fingerprints, each pair sorted and hashed.
- 4The published rootCheckingFetching from raw.githubusercontent.com, repository cberzins1973/luu-attestation-anchors, commit ed193c78, file daily-seals/2026-09-08.json… view this file on GitHub
- 5Shape of the treeCheckingThe published file gives the number of leaves and the depth of the tree. A proof in a tree of depth d needs d minus 1 steps. This proof has 15.
- 6An outside clockCheckingAsking GitHub when commit ed193c78 was pushed…
It was sealed late because a September 2026 audit found 43 per cent of forecast records unlinked to any seal. The catch-up seal of 8 September 2026 folded 17,502 records into one tree. In the anchors repository, 77 of the 162 daily seals were first committed more than a day after their date, 75 of them dated before the repository was created on 31 May 2026 (measured on 26 September 2026 from the repository’s history, whose commit dates are written by the project and are not independent).
Change one character
Edit the record. Steps 1 to 3 run again as you type. The published root in step 4 does not move.
What this shows, and what it does not
- It shows membership: this record’s fingerprint is one of the leaves under a root that GitHub received at a recorded time.
- It does not show position or count. Each pair of fingerprints is sorted before it is hashed, and a record’s fingerprint is hashed the same way as the fingerprints above it, so a proof cannot show where in the tree the record sits or how many records the tree holds. Step 5 compares the proof’s length with the published depth, which is the check this construction allows.
- The commits are unsigned, so the dates inside them are the project’s own. GitHub’s record of when a commit reached the repository is the only outside clock here, and it is an upper bound: the record existed no later than that.
- The records that can be shown are baselines built mostly from a market price, or from a fixed prior where no price was read. They demonstrate integrity and timing. They do not demonstrate skill, and a forecast built from a market price cannot be scored against that price.
- Not every record can yet be checked from this site. Given only a question’s identifier, the site’s proof lookup (/api/public/forecast-integrity-proof) finds the first leaf for that question on a day, which leaves most repeated records of the same question unreachable that way. The examples here were exported directly from the sealed trees.
- The same trees also seal records about the project’s private reference feeds and other project records. Their contents are not published here, and only their fingerprints appear, as leaves.
Run it on your own machine
Download the record and its proof, and a script of about 130 lines with no dependencies. With Node 18 or later, run: node verify-inclusion.mjs record-and-proof.json. It repeats steps 1 to 5, fetching the published file from GitHub itself, and, as an extra check, asks GitHub whether the commit is on the anchors repository’s main branch. Those two requests need the network. The script trusts only the anchors repository named inside it, never one named in the file. It does not read the push time, which stays with step 6 in your browser or on GitHub’s activity page.
The download is the record on the tab you have open: 2ea74522…514e, sealed in the tree of 18 July 2026.