Provably Fair Verifier
A trust claim is only as good as your ability to check it. Enter a disclosed server seed, your client seed and the nonce, and this tool independently recomputes the outcome with the same HMAC-SHA256 arithmetic the casino runs. Nothing is transmitted — the computation happens entirely in your browser.
Last updated: August 2026
◆ Bet Details
Safe to paste only once the casino has rotated away from this seed and disclosed it.
Which bet this is, counted within the current seed pair.
Result index. Leave at 0 for Dice and Limbo.
Copy this from that round's entry in the bet history.
Defaults to Bitcoin block 584,500 — the block hash Stake committed to 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
Of everything on this page, this single check matters most. The operator publishes SHA-256 of the server seed before you place a bet, then hands you the seed itself once it rotates out. Drop both values in below: agreement confirms the seed was locked in advance; a mismatch means it was swapped mid-stream and nothing computed under it can be trusted. The same fields double as a crash game-hash check, since that chain commits forward the same way.
Computed SHA-256
—
The Maths, Step by Step
◆ From seeds to bytes
The casino signs the message clientSeed:nonce:roundwith HMAC-SHA256, keyed on the server seed. That produces 32 bytes. The round counter starts at 0 and only advances when a game needs more than 32 bytes of randomness — so a single dice roll's message is literally your client seed, a colon, the nonce, a colon, and a zero.
◆ From bytes to floats
Each group of four bytes collapses into a single value in [0, 1) by weighting them in descending powers of 256: b0/256 + b1/256² + b2/256³ + b3/256⁴. A 32-byte signature therefore carries eight usable floats. The four-byte grouping matters: one byte alone would quantise every outcome to 256 steps, coarse enough to be visible in the payout distribution.
◆ Dice and Limbo
Both games read only the first float. Dice maps it to a roll withfloor(float × 10001) / 100, which spans 0.00 to 100.00 inclusive — 10,001 equally likely outcomes rather than 10,000. Limbo maps the same float with1e8 / (floor(float × 1e8) + 1) × 0.99. The 0.99 factor is the 1% house edge expressed directly in the payout formula, and the +1 in the denominator exists to make a float of zero well-defined.
◆ Crash breaks the pattern
One round is dealt to every player at once, so a per-player client seed would make no sense. The public input is a Bitcoin block hash instead, signed with the round's own game hash as the HMAC key; the leading 4 bytes read as a 32-bit integer feedmax(1, 2³² / (int + 1) × 0.99), floored to two decimals. The integrity argument is the chaining: every game hash SHA-256s forward to its predecessor, so the whole sequence was determined before the first bet of the chain was placed.
Fair does not mean beatable
Provably fair proves the operator did not tamper with the outcome after the fact. It does not touch the house edge — Stake-style dice and limbo retain 1% of every wager by design, and that same 1% is the literal 0.99 multiplier in the maths above. Verify the round, but read our review methodologybefore treating "verifiable" as a synonym for "beatable".
Sources
Stake does not expose a machine-readable spec — its documentation pages actively block automated fetches — so we assembled this implementation from Stake's own public announcement of the crash seeding mechanism plus two independently maintained open-source verifiers, then cross-checked all three against known-answer test vectors pulled from real bets before trusting any of it. The dice, limbo and crash maths agree across all three sources.
- Stake's crash seeding announcement on Bitcointalk— where Stake published the chain's final hash, the Bitcoin block 584,500 salt, and the crash-point formula, before that chain was ever put into use.
- lucasholder/fair— a Rust verifier whose test suite is the origin of the byte-stream, float, dice and limbo known-answer vectors this page's self-test runs against.
- lotuseuy/stake-provably-fair-verifier— a separately written JavaScript verifier whose test suite contributed 49 real dice rolls, 40 real limbo rounds and 9 real crash rounds, each one matched to its published server seed hash.
Last updated: August 2026. One ambiguity is worth recording. Stake's published description of limbo divides by float × 1e8; the client implementation floors that product and adds one. At two decimal places the two agree on every real round in our test set, and they part company only at extremely small floats — where the floored form is what Stake's own calculator returns. We implement the floored form for that reason.
See how provably fair factors into our scoring on theCasino Safety Index, read our Stake review, or dig into the cryptography behind it in ourprovably fair guide.
---- ◆ Reference ◆ ----
Provably Fair, Explained
What does "provably fair" actually mean, mathematically?
The casino commits to a random value before the bet and discloses it afterward, so the result is independently recomputable. It picks a server seed and publishes only its SHA-256 hash in advance. You supply a client seed. Each bet runs both seeds and a bet counter (the nonce) through HMAC-SHA256. Because the server seed was locked in by its hash before your client seed was chosen, the outcome could not have been retuned after the casino saw your bet — a claim this page lets you verify directly rather than take on faith.
Why does the server seed get hashed before play, rather than shown outright?
The hash functions as a commitment. SHA-256 is one-way, so the hash alone reveals nothing about the seed, but once the seed is disclosed, anyone can hash it and compare. If the casino swapped seeds mid-session, the disclosed seed would fail to reproduce the previously published hash. That mismatch is exactly what the hash-check tool on this page tests — if it fails, nothing downstream can be trusted.
What do "nonce" and "cursor" refer to?
The nonce counts bets under the current seed pair — it starts at 0 or 1 depending on the platform and increments each bet. The cursor addresses a position within one bet's random output. A single HMAC-SHA256 signature yields 32 bytes, which converts to eight 4-byte floats; a game that needs more than eight numbers (Plinko, Keno, a shuffled deck) advances a round counter and signs again. Dice and Limbo only consume the first float, so their cursor sits at 0.
Why does Crash use a Bitcoin block hash as its salt?
Crash is a shared round — every player at the table sees the same multiplier — so a personal client seed will not work. Instead, Stake pre-generated a chain of 10,000,000 SHA-256 hashes, published only the final one, then salted the calculation with the hash of Bitcoin block 584,500, a block that had not yet been mined when the chain was announced. Nobody, the operator included, could have known that block hash in advance, which fixed the entire future sequence of crash points while keeping it unguessable. Each game hash also hashes forward to the previous round's hash, so the whole chain is independently auditable.
Which operators in our rankings actually run provably fair games?
As of our August 2026 review pass, Stake, BC.Game, Cloudbet and Wolf.bet each run provably fair "originals" alongside licensed third-party slot libraries. The third-party titles are not provably fair anywhere in the market — those studios rely on audited RNGs instead. One caveat worth stating plainly: provably fair only proves the result was not tampered with after the fact. It does not remove the house edge built into the game.
Does this tool verify BC.Game, Cloudbet, or Wolf.bet rounds too?
This page implements the specific scheme Stake publishes. BC.Game, Cloudbet and Wolf.bet each publish their own provably fair schemes, and while several crypto casinos share a broadly similar HMAC-SHA256 seed-and-nonce structure, we have not independently confirmed their exact byte-to-outcome conversions here. The SHA-256 server-seed hash check further down this page is universal, though — it works for any operator that commits to a hashed server seed, regardless of how it converts bytes into a game result. For the game-specific maths at a non-Stake operator, use that operator's own published verifier.
Does anything typed into this page leave my browser?
No. Every computation runs client-side through the WebCrypto API. There is no network call, no logging, and no server component — load the page, disconnect from the internet, and it keeps working. One caution regardless: never paste a server seed the casino has not yet rotated. A seed is only safe to share once the casino has disclosed it and moved to the next one.