CRASH PROVABLY FAIR VERIFIER

No provably-fair game attracts more suspicion than Crash. The climbing rocket feels reactive — like it waited for your cash-out click before dying — but at Stake, Shuffle and BC.Game the bust point comes from a chain of hashes generated before the round started, salted with a Bitcoin block hash nobody knew in advance. The animation is theatre; the number is math. This page strips away the theatre and computes the number.

Not sure which to choose? See what we recommend for each type of player.

ONE GAME, TWO KINDS OF INPUT

Before comparing numbers, know which kind of Crash you played. At Stake, Shuffle and BC.Game, Crash is a hash-chain game: the operator generated millions of SHA-256 hashes in advance, each one the hash of the next, and plays them in reverse, so every player in a round busts at the same multiplier. Your client seed and nonce play no part in it. That is why a seed-based verifier cannot reproduce a crash round, and why this page asks for the game hash shown in the round details instead. Seed-based games (Dice, Limbo, Mines and so on) are covered by the multi-game verifier.

HOW CRASH RESULTS ARE CALCULATED

Stake, per its own seeding post on bitcointalk (topic 5162888, read 22 Oct 2026):

1. Compute HMAC-SHA256(key = game hash, message = salt). The salt is the hash of Bitcoin block 584,500: 0000000000000000001b34dc6a1e86083f95500b096231436e9b25cbdd0075c4.
2. Take the first 8 hex characters and read them as a 32-bit integer.
3. Apply max(1, (2^32 / (int + 1)) × 0.99), shown to two decimals. The 0.99 is the 1% house edge.

BC.Game, per its open-source verifier (github.com/bcgame-project/verify, crash.html, read 22 Oct 2026): HMAC-SHA256(key = salt, message = game hash as bytes), take the first 52 bits as X / 2^52, then max(1, floor(99 / (1 − X)) / 100). Its current salt is pre-filled; games before #9,614,372 use an older salt.

Shuffle publishes its chain and its salt (Bitcoin block 779,588) but not the formula that turns a game hash into a multiplier (help.shuffle.com 9286069, read 22 Oct 2026). For Shuffle the tool checks the chain link only.

Worked example with an illustrative input, not a real Stake round: game hash e2b65f21…52d50864 (the SHA-256 of the text “provenlyfair-crash-example”) with Stake’s salt gives an HMAC starting edcfeae2, the integer 3989826274, and a crash point of 1.06x.

Chain check: SHA-256 of a round’s game hash (hashed as text) must equal the previous round’s game hash. Shuffle’s help article gives a real pair you can test: game 1323185’s hash 2f824ebb…52825ac0 hashes to game 1323184’s 20f42ccc…ec280265. The tool shows this value for every round you paste.

WHY VERIFY CRASH?

Because Crash is exactly where paranoia peaks. Instant 1.00x busts, a rocket that dies a tick after you doubled your stake, five sub-1.20x rounds in a row — all of it happens under an honest 1/x-shaped distribution, where low multipliers are simply common. Recomputing a suspicious round from the committed seeds settles the question with arithmetic instead of vibes: either the bust point follows from data fixed before your bet, or you have caught something real. Being able to check is the point.

Two honest caveats. Verification cannot address the 1% edge baked into the 0.99 factor, and it cannot vouch for casinos running a different Crash scheme than the one you select. Our provably-fair primer covers the commitment cryptography; the multi-game verifier covers the other Originals.