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.
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.