Verify the Pick of the Day record
Every pick, up to six a day, is sealed as a sha256 hash in a public repository before its game starts, and opened once the market settles. The track record on this site comes out of our own database, so on its own it is a claim about ourselves. The hash lets you check when each sealed pick was fixed without taking our word for it. The hash cannot vouch for a pick that was never sealed, or for whether a pick was a good one.
What is committed, and when
A commitment is a hash you publish before you reveal what it covers. Publish early, open later, and the early publication is what proves the pick existed then. The construction is sha256(canonical_json(payload) || nonce).
- 01Before each game
A day carries up to six picks, one per game, ranked Pick 1 down. Each is sealed on its own clock, because each game starts at a different time. Sealing means a sha256 hash of the pick goes into a public repository before that game starts, and GitHub records the commit that carries it. The hash gives nothing away on its own. A pick is low entropy: one market, one of two sides, a price on a one-cent grid. Try every combination and a bare hash opens, which would hand out a live pick. So the hash covers the pick plus a 256-bit nonce from the operating system's random source, and that nonce stays unpublished while the game is still open.
- 02After it settles
Once Polymarket resolves the market, we publish the pick and its nonce. You recompute
sha256(canonical_json(payload) || nonce)and compare the result against the hash in the commit from before the game. The canonical form is specified byte for byte, so a checker you write in another language lands on the same bytes. - 03What that rules out
Nobody can add a pick after its game, edit one after it publishes, or drop one out of a day without leaving a gap in that day's rank sequence. All three need the earlier commit to change, and changing a commit rewrites every commit after it.
One commitment, opened
The whole chain on one pick, so you read it end to end once before checking a real one. The payload is the pick's frozen identity: which market, which side, at what price, for what game, and which of the day's six slots it holds. The outcome is deliberately absent. A market corrected after settlement re-maps the pick, and surviving that unchanged is the case the commitment exists for.
- Canonical payload, 199 bytes
- {"backed_price":"0.545000","condition_id":"0xabc","kickoff":"2026-09-20T23:05:00Z","pick_date":"2026-09-20","pick_outcome_index":1,"pick_outcome_label":"Lakers","pick_rank":1,"platform":"polymarket"}
- Nonce, 256 bits
- 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
- sha256 of the payload and the nonce
- 44d18fa5e2aa3a2bf3c971dcc9317c8ccbdfd5480a4773b6d8ffd5fbeeea84dc
- The commit that sealed it
- 0xinsider/picks
8 fields, sorted by key, no whitespace between them. Each is write-once before kickoff, so the commitment is stable from the moment it is sealed.
- backed_price
- The frozen pre-game price of the side we backed.
- condition_id
- Polymarket's own id for the market.
- kickoff
- The game's start time, in UTC, whole seconds.
- pick_date
- The Eastern product day the pick belongs to.
- pick_outcome_index
- Which of the market's two outcomes we backed.
- pick_outcome_label
- That outcome's name, as it reads on the card.
- pick_rank
- The pick's slot in the day, 1 through 6.
- platform
- The venue the market is on.
What this does not prove
The commitment proves when each sealed pick was fixed, but it does not establish 3 things.
Unsealed picks carry no pre-game proof
Every pick published before the commitment shipped has no hash from before its game, and neither does a later pick that reached kickoff unsealed. The ledger marks both pre_commitment. Those picks stay in the record with their results. What is missing is the part that would let you check them, and nothing can be added after the fact. That is the reason to commit in advance.
The proof covers the pick, not whether it was a good one
It shows the market, the side and the price were fixed before the game and have not moved since. It says nothing about whether backing that side was the right call. A record that verifies in full can still be a losing one. Win rate, ROI and closing line value on the stats page are the numbers that answer that question.
It rests on the history not being rewritten
A commit's own timestamp is written by whoever makes the commit. What carries the weight is the history around it: the commits pushed on top, and the copies other people hold. main is branch-protected, and a rewritten history is this design's remaining attack. What catches that is a copy we do not hold, so clone the repository.
Three ways to check
Easiest first. Each checks the same thing and costs more effort than the last.
01Read the ledger in the browser
Open a settled pick's file in 0xinsider/picks. The payload, the nonce and the hash are plain text. GitHub's history on that file shows when the hash first appeared, which is the check that catches a backdated record. Nothing to install.
02Ask an assistant
Copy one and paste it in. Each asks for an independent check and never for agreement: recompute the hashes, confirm every seal predates its kickoff, look for gaps where a pick was sealed and never opened, recount the record from the raw ledger, and report any mismatch with what this site publishes. Both close by asking what the scheme does not prove and what an operator could still get away with under it.
For an assistant that can clone the repository and run code.
For a chat that browses but may not be able to clone or execute.
03Run verify.py
Clone the repository and run it over the whole ledger. It reports an exit code and one line per pick. VERIFY.md specifies the canonical form precisely enough for you to write your own checker in any language, and the vector above is what you pin it against first.
