Verify a prediction receipt yourself
Every prediction is cryptographically locked before the outcome is known. Here's how to prove it — no trust required.
-
Every prediction is written down before the outcome.
When Adology locks a forecast, it immediately appends a record to an append-only file (
forward_slips.jsonl) with the exact numbers: the brand, the predicted final engagement count, the model version, and the UTC timestamp when the prediction was made. The post hasn't matured yet — the outcome is unknowable at write time. -
The record is fingerprinted with a hash that commits to the exact numbers.
A SHA-256 hash is computed over the record's payload (sorted keys, no whitespace) and stored as
record_hash. SHA-256 is a one-way function: changing even one digit of the predicted value produces a completely different hash. The first 16 hex characters of a separate hash (over just the four prediction fields: post_id, predicted_final, t_predict, model_version) become the publicslip_hashshown on the leaderboard. -
Each record commits to the one before it — forming a chain.
Every record stores the previous record's
record_hashas its ownprev_hash, then hashes both together. This means you cannot edit, delete, or insert a record anywhere in the history without breaking every hash that comes after it. The chain makes silent edits impossible. -
The whole file is anchored to the Bitcoin blockchain via OpenTimestamps.
OpenTimestamps is an open protocol that embeds a hash of any file into a Bitcoin transaction, creating an independent, third-party timestamp that cannot be altered retroactively. Once anchored, the blockchain proves the ledger file existed — with its exact contents — before a certain Bitcoin block. No one controls Bitcoin; no one can rewrite its history.
-
So: editing history breaks the math. Here's you proving it.
Below you can paste any slip JSON record and your browser will recompute the SHA-256 hash using the Web Crypto API (a built-in browser primitive, no server call) and compare it to the stored
record_hash. Change any single digit and watch it turn red.
Fields in every slip record
- slip_hash
- First 16 hex chars of SHA-256({post_id, predicted_final, t_predict, model_version} sorted). The public "receipt number" shown on the leaderboard.
- prev_hash
- The
record_hashof the immediately preceding record in the ledger (genesis = 64 zeros). Links this record into the chain. - record_hash
- SHA-256(prev_hash + "\n" + canonical_json(payload)). This is what the verifier below recomputes. If it doesn't match, the record was altered.
Paste a slip record — or pick one of the examples below
Try to cheat — edit any digit and watch the hash fail
The box below contains a real, verified slip. Change any character — one digit in
predicted_final,
a letter in the handle, anything — and click "Test edit." The hash check will immediately
turn red, proving the original hash no longer matches. This is why backdating is impossible:
you'd need to find a different input that produces the same SHA-256 output,
which is computationally infeasible.
Verifiable ≠ verified — anyone CAN check; here's who HAS
Cryptographic verification is only meaningful if someone actually runs it. This page gives you all the tools to check any slip yourself (hash recompute, chain walkthrough, CLI commands). Below is the append-only log of who has done exactly that — including our own internal selftest, which is the baseline. Independent verifications from journalists, researchers, or clients are most valuable.
| Who | Date | How they verified |
|---|---|---|
| Adology internal (automated selftest) | 2026-07-11 | python3 engine/forward_slips.py verify # hash-chain verified OK; python3 engine/forward_slips.py selftest # all checks PASS; OTS pending (Bitcoin calendar batch) |
1 verification on record
python3 engine/verify_page.py log-verification --who "Your name / org" --method "CLI commands you ran"
Then rebuild the page: python3 engine/verify_page.py
What this verification does NOT prove
- It does not prove the prediction was good. Hash verification only proves the numbers weren't changed after the fact. Whether the model is accurate is a separate question — and an honest one. See the scoreboard for the full track record including all misses, which are shown alongside hits and cannot be deleted.
- It does not prove the timestamp is accurate to the second. The ledger's own timestamps are set by the machine running the cron job. The OpenTimestamps Bitcoin anchor provides independent third-party proof of existence before a given Bitcoin block, but anchoring happens in batches (typically within hours), not instantly per prediction.
- It does not prove the underlying data is correct. The predicted and observed engagement counts come from the Instagram/TikTok APIs via an Apify scraper. We lock what we read; we can't control what the platform reports.
- It does not replace accuracy as the signal that matters. A system could pre-commit random numbers and have a perfect hash chain. Verification is the floor, not the ceiling. The number that matters for a media decision is Spearman rank accuracy on the full, unfiltered resolved set.