Provably fair verifier — check crash, Mines & Plinko rounds

Commit, reveal, verify

Provably fair systems run in three steps. First, commit: before you play, the operator publishes the hash of a server seed it has already chosen but not revealed — usually SHA-256, recorded somewhere you (or anyone) can point back to later. Second, play: each round combines that hidden server seed with a client seed (yours, or one generated for you) and a nonce that counts up by one every round, producing the outcome through a fixed formula. Third, reveal and verify: later, typically when you rotate to a new server seed, the old one is published. Hashing it should reproduce the commitment from step one, and re-running the formula should reproduce every round you played.

A failed check — a computed hash or result that doesn't match — is a mismatch, not automatic proof of cheating: it can just as easily come from a typo in a seed, the wrong nonce, a hash that was never actually published in advance, or checking a round from a different scheme (wrong byte layout or formula) with this tool. Treat a mismatch as a reason to double-check your inputs and the scheme first, and as evidence of tampering only once those are ruled out — ideally against a commitment you (or an independent third party) can show was recorded before the round was played.

The server seed is the half only the operator knows until reveal — it is what keeps results from being predictable in advance. The client seed can stop the operator from quietly picking a server seed that favours the house for a specific player, but only under two conditions: the hash commitment has to be recorded somewhere verifiable before the round, and the client seed has to be chosen independently of that commitment (ideally by you, after the hash is already public) rather than supplied or overwritten by the operator afterwards. The nonce is a round counter: each new nonce feeds a different message into the HMAC step below, so it produces a separate result alongside the same two seeds — it doesn't make results unpredictable on its own, and reusing the same seeds and nonce will always reproduce the same result (that repeatability is expected, not a flaw).

What HMAC-SHA256 does

HMAC-SHA256 takes a secret key (the server seed) and a message (clientSeed:nonce:counter) and produces a 32-byte block that is deterministic but looks like noise unless you know the key. Our verifier builds that message with counter 0, computes the HMAC, and converts the bytes to hex for the step shown above. The block (and further blocks if a round needs more bytes, with the counter incremented) is then read as big-endian 32-bit integers and fed into the result formula — nothing here is hidden or randomised beyond the server seed itself.

cashoutodds reference scheme v1 (documented)

Because real providers rarely publish full specifications, this verifier implements and documents its own open scheme so every step is checkable:

• Crash: take the first 13 hex characters of block 0 as a 52-bit integer h, then bust = max(1, floor(100·(1−e)·2^52 / (2^52 − h)) / 100), where e is the house edge — this verifier always uses e = 3% (0.03), the same value as our simulators. Larger h values push the bust higher; the formula is exact integer arithmetic, not floating point.
• Mines: mine positions are drawn with rejection-sampling Fisher–Yates over the remaining tiles — each 32-bit integer from the stream is only accepted if it falls below the largest multiple of the tile count, so every remaining tile stays equally likely and there is no modulo bias.
• Plinko: each row consumes one 32-bit integer and reads only its top bit — 1 means right, 0 means left — because a 32-bit range splits into two exactly equal halves, again with no bias.

Every one of these rules is reversible: given the revealed server seed, client seed and nonce, you (or anyone) can recompute the exact same bust, mine layout or Plinko path shown above — that's what this tool does, entirely in your browser. Seeds can be typed in directly or passed through the URL fragment (the part after #), which your browser never sends to a server — nothing is transmitted anywhere.

What verification proves — and what it doesn't

A passing check means: the claimed result is consistent with the seed the operator committed to before the round, using the scheme this tool implements. It rules out the server silently swapping in a different, more favourable-to-the-house outcome after it already knew your bet — provided the commitment hash was actually recorded somewhere before the round (not just claimed afterwards) and the scheme matches. A failed check is a mismatch, not proof of manipulation by itself — a wrong input, a mistyped nonce, or checking a third-party round against the wrong scheme can all produce the same "no match" result that genuine tampering would. It does not remove the house edge, does not mean the payout table is generous, and is not a guarantee of winning — a game can be flawlessly provably fair and still return less than it takes in, by design. If you're asking whether a specific branded game is "rigged," the honest answer is: provably fair checking (when a provider implements it correctly, and when you're checking it against that provider's own scheme) answers the narrow question of result-vs-seed consistency, not the broader question of expected value, which you can estimate instead with our expected loss calculator or crash simulator.

Test vectors

Three fixed inputs and their outputs from the engine, so you can sanity-check an independent implementation against ours:

More tools: crash simulator · Mines odds calculator · Plinko distribution · risk of ruin calculator · methodology.