Ledger and verification · as of 2026-09-02
What you can check yourself, and what is only designed so far.
Two different mechanisms get confused with each other, so they are separated on this page. A run's record attests to its own bytes today. Anchoring a receipt into a public hash chain is designed and has never been used. Neither claim borrows credibility from the other.
A record that attests to its own bytes
Every run writes a durable record. Before it is written, the record seals a digest of itself: SHA-256 over its own canonical form with the digest field replaced by sixty-four zeros. The placeholder is exactly invertible, so the stated algorithm reproduces the check anywhere — you do not need our software to verify a record we gave you, only the record and the rule.
Verification has three verdicts. A record whose digest recomputes is ok. One whose digest does not is failed. A record written before this mechanism existed is unattested — not failed. Reporting an absent digest as tampering would teach a reader to ignore the check.
The written report a customer keeps states its own digest by the same trick and can be verified on
its own. If the record is not sitting next to it, the report reads unavailable, never
failed: a customer holds the page and none of our evidence, and a check that cannot run
should say so rather than accuse.
A hash chain that has been running in public
The chain itself is not new and is not a diagram. It has been carrying the M6E prediction ledger — every committed forecast, wins and losses alike — with the full recipe published so anyone can recompute it from the downloadable CSV. Each entry's hash covers the previous entry's hash plus the entry's own fields as they stood before the outcome was known, so settling a result can never alter the hash of the call that preceded it.
That record moved with the trading desk and lives at trading.vvdexops.com/ledger.html, together with the CSV, the raw JSON, the chain head and the verification code. It stayed there rather than being copied here because it is a live artifact with a live data pipeline behind it, and a second copy of a chain is a second thing to keep honest.
Zero eval receipts have been anchored.
The chain is intended to gain a second kind of entry beside the prediction rows: an anchor for an evaluation run. Not one has been written. There is no anchored entry to show you, no count to quote, and this page will not invent one to illustrate the idea.
What is decided about it, so it can be held against us when it ships: anchoring is opt-in per job and off by default; the chain carries hashes only, salted — never results, never a model's identity, never a customer's name; and disclosure stays with the client, forever. The point is a private result that becomes provable at the moment its owner chooses to prove it, and never before.
What it proves. That a specific record existed, unchanged, no later than the entry that carries it — because changing any earlier entry changes every hash after it. That is the whole claim, and it is a real one: it removes the option of quietly re-running until the number improves and presenting the last attempt as the first.
What it does not prove. Nothing about the quality of the result, nothing about the model, and nothing about a run that was never anchored. An unanchored run is not suspicious; it is the default.
Who can read it. Nobody, until the holder discloses. A salted hash on a public chain is a commitment, not a publication.
- Working today: per-record digests, verifiable from the record alone; a report that states its own digest; a public hash chain with a published recipe, running on the prediction ledger.
- Not working yet: anchoring an evaluation receipt into that chain. Designed, agreed, unbuilt, and used zero times.
- Never: a customer's results on a public surface. Anchoring is the opposite of publishing — it is how a private result stays private and stays provable.