Provably Fair Verifier
Don't take the casino's word for it. Paste a revealed server seed, your client seed and the nonce, and this page recomputes the outcome from scratch using the same HMAC-SHA256 maths the casino used. Everything runs in your browser — nothing is sent anywhere.
♠ Bet Details
Only paste a seed the casino has already rotated and revealed.
The bet number for this seed pair.
Result index. Leave at 0 for Dice and Limbo.
The hash shown for that crash round in the bet history.
Pre-filled with the hash of Bitcoin block 584,500, the salt Stake published for its crash chain.
♦ Result
Dice Roll
—
HMAC-SHA256 output (hex)
—
Message signed
—
Bytes used (first four of this result)
—
Floats from this round
—
♥ Server Seed Hash Check
This is the check that matters most. The casino publishes SHA-256 of the server seedbefore you bet, and reveals the seed after. Paste both and confirm they match — if they don't, the seed was swapped and every result under it is worthless. The same box also checks a crash game hash against the previous round's hash, since that chain is built the same way.
Computed SHA-256
—
How the Maths Works
♠ From seeds to bytes
The casino signs the message clientSeed:nonce:roundwith HMAC-SHA256, using the server seed as the key. That produces 32 bytes. The round counter starts at 0 and only advances when a game needs more than 32 bytes of randomness — so for a dice roll the message is literally your client seed, a colon, the nonce, a colon, and a zero.
♥ From bytes to floats
Bytes are taken four at a time and folded into one number between 0 and 1:b0/256 + b1/256² + b2/256³ + b3/256⁴. That gives eight floats per 32-byte round. Using four bytes instead of one is what stops the results from clustering on coarse steps.
♦ Dice and Limbo
Dice takes the first float and computesfloor(float × 10001) / 100, giving a roll from 0.00 to 100.00 inclusive. Limbo takes the same float and computes1e8 / (floor(float × 1e8) + 1) × 0.99, floored to two decimals — the 0.99 is the 1% house edge, and the +1 is what keeps a float of zero from dividing by zero.
♣ Crash is different
Crash rounds are shared by every player, so there is no per-player client seed. Stake signs a published Bitcoin block hash with the round's game hash as the HMAC key, takes the first 4 bytes as a 32-bit integer, and computesmax(1, 2³² / (int + 1) × 0.99), floored to two decimals. Because each game hash SHA-256s to the previous round's hash, the entire sequence was fixed in advance.
A fair result is still a losing bet on average
Provably fair proves the casino did not tamper with the outcome. It does not remove the house edge — Stake-style dice and limbo keep 1% of every wager by design, and the verification maths above literally contains that 1% as the 0.99multiplier. Verify your bets, but read ourreview methodology before you assume "verifiable" means "beatable".
Sources
Stake's own documentation pages block automated fetches, so the implementation on this page was built from Stake's public announcement of the crash seeding event plus two independent open-source verifiers, then checked against known-answer test vectors taken from real bets. All three agree on the dice, limbo and crash maths.
- Stake's crash seeding announcement on Bitcointalk— the hash chain tip, the Bitcoin block 584,500 salt, and the crash point formula, published by Stake before the chain was used.
- lucasholder/fair— a Rust verifier library whose test suite supplied the byte-stream, float, dice and limbo known-answer vectors used by the self-test above.
- lotuseuy/stake-provably-fair-verifier— an independent JavaScript verifier whose tests supplied 49 real dice rolls, 40 real limbo rounds and 9 real crash rounds, each paired with its published server seed hash.
Last updated: August 2026. The two verifiers differ on one detail of the limbo formula: Stake's published page describes dividing by float × 1e8, while the reverse-engineered client floors that value and adds one. Both produce identical two-decimal results on every real round we tested; they only diverge on extremely small floats, where the floored version is the one that matches Stake's own calculator. This page uses the floored version.
See how provably fair factors into our scoring on thesafest casinospage, read ourStake review, or learn the maths behind the multiplier in ourcrash game strategy guide.
Provably Fair, Explained
What does "provably fair" actually mean?
It means the casino commits to a random value before you bet, and reveals it afterwards so you can recompute the result yourself. The casino picks a server seed and shows you only its SHA-256 hash up front. You pick a client seed. Every bet combines both seeds plus a counter (the nonce) through HMAC-SHA256. Because the server seed was locked in by its hash before you chose your client seed, the casino cannot retune the outcome after seeing your bet — and you can prove it by re-running the same maths in this page.
Why is the server seed hashed before I play?
The hash is the commitment. SHA-256 is one-way, so seeing the hash tells you nothing about the seed, but once the seed is revealed anyone can hash it and check it matches what was published. If the casino swapped the seed mid-session to kill a winning streak, the revealed seed would no longer hash to the published value. That is why the first thing this tool does is the SHA-256 check — if that fails, nothing else matters.
What are the nonce and the cursor?
The nonce is the bet counter for your current seed pair — first bet is nonce 0 or 1 depending on the casino, and it increments every bet. The cursor is the position within a single bet's random stream. One HMAC-SHA256 gives 32 bytes, which is eight 4-byte floats, and games that need more than eight random numbers (Plinko, Keno, a shuffled deck) roll the round counter forward and hash again. Dice and Limbo only ever need the first float, so their cursor is 0.
Why does Crash use a Bitcoin block hash as salt?
Crash is a shared round — every player sees the same multiplier — so it cannot use your personal client seed. Instead Stake pre-generated a chain of 10,000,000 SHA-256 hashes and published the last one, then salted the calculation with the hash of Bitcoin block 584,500, which had not been mined when the chain was announced. Nobody, including the casino, could know that block hash in advance, so the whole sequence of future crash points was fixed and unguessable at the same time. Each game hash also hashes to the previous game hash, so the chain itself is checkable.
Which of the casinos you review are provably fair?
Stake, BC.Game, Cloudbet and Wolf.bet all run provably fair in-house "originals" alongside their third-party slot libraries, as of our August 2026 review pass. Third-party slots from external studios are not provably fair anywhere — they use audited RNGs instead. Note that provably fair only proves the result was not tampered with; it does not remove the house edge.
Does this verifier work for BC.Game, Cloudbet and Wolf.bet too?
This page implements Stake's published scheme. BC.Game, Cloudbet and Wolf.bet each publish their own provably fair schemes, and while several crypto casinos use a similar HMAC-SHA256 seed-and-nonce structure, we have not verified their exact byte-to-outcome conversions here. The SHA-256 server-seed check at the bottom of this page is universal and works for any casino that commits to a hashed server seed. For the game maths at a non-Stake casino, use that casino's own verifier.
Does anything I paste leave my browser?
No. Every calculation runs in your browser through the WebCrypto API. There is no network request, no logging and no server involved — you can load this page, disconnect from the internet, and it will still work. That said, do not paste an unrevealed server seed anywhere, including here: a server seed is only safe to share after the casino has rotated it.