How Provably Fair Dice Works

Everything starts with the casino generating a long random string, the server seed. A typical seed is 64 hexadecimal characters, for example:

8f3b0f1c2a9d4e6b7c5a1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f60718293a4b5c6

The site keeps that secret but immediately publishes its SHA-256 hash:

9cf672cc9b46bca8417a823e93e7c8528531fcc1b456a7473f6f5ec195467578

SHA-256 is a one-way function with two properties that matter here. First, it is preimage resistant: nobody can work backward from the hash to the seed, so seeing the hash tells you nothing about upcoming rolls. Second, it is collision resistant: the casino cannot find a second, more profitable seed that hashes to the same value. Publishing the hash is therefore a binding commitment, the digital equivalent of sealing the deck in a tamper-evident envelope before the game starts.

Record this hash before you bet. It is the anchor of the entire proof: every later verification step compares against it. If a site never shows a seed hash, or shows one that changes without a rotation event, there is no commitment and nothing to verify. That is not provably fair, whatever the marketing page says.

A commitment alone is not enough. Imagine the casino generated millions of candidate server seeds, simulated the rolls each would produce, and committed to the one where you lose most. The hash would verify perfectly and you would still be cheated.

The client seed closes that hole. It is a string you control, editable in the fairness settings of any legitimate dice site, and it is mixed into every roll calculation. The order of operations is the whole defense:

1. Casino generates the server seed and publishes its hash. The seed is now frozen.
2. You set or change your client seed, for example btcdices2026.
3. Rolls are computed from both values together.

Because your seed arrives after the commitment, cherry-picking server seeds is useless: the casino would need to predict your exact string in advance. Change it to anything, a song lyric, random keystrokes, a number you rolled on a physical die, and the entire future roll sequence changes with it.

Practical habit: always overwrite the default client seed before your first bet on a new seed pair. Defaults are almost certainly not exploited at reputable sites, but typing your own string makes the guarantee unconditional, and it costs you five seconds.

If rolls were computed from the server seed and client seed alone, every bet would produce the identical number. The nonce fixes that: it is simply your bet count under the current seed pair. First bet, nonce 0 or 1 depending on the site's convention. Second bet, one higher. And so on.

The nonce does double duty:

• Uniqueness: each (server seed, client seed, nonce) triple maps to exactly one roll, so a single commitment covers an entire session.
• Completeness: because nonces are sequential, you can verify that the casino did not skip or reorder outcomes. If you placed 500 bets, nonces 1 through 500 must reproduce your exact history, with no gaps where an unfavorable roll might have been quietly dropped.

That second property is underrated. A subtle cheat would not fake individual rolls, it would selectively discard them. Sequential nonces make the roll history an append-only log: every entry is fixed the moment the seeds are, and the whole sequence is checkable end to end.

One caution for auto-bettors: your interface bet counter and the fairness nonce can drift apart if some bets fail or get rejected. When verifying, trust the nonce recorded in the site's bet detail view, not your own count.

With all three inputs fixed, the roll is pure arithmetic. The standard core is HMAC-SHA256(key = server seed, message = clientSeed:nonce). Using our example seed, client seed btcdices2026, and nonce 1, the HMAC output is:

4b9895dfe5bb1bd4855fc2902b7af68fcf18277ca563378c1520715cae8b13ed

Construction 1: mod 10000 (the classic). Take the first 5 hex characters, 4b989, and convert to decimal: 309641. If that value were 1,000,000 or more, you would slide to the next 5 characters and repeat. Here it is fine, so take 309641 mod 10000 = 9641, then divide by 100. The roll is 96.41. The reroll rule for values at or above 1,000,000 exists to keep every outcome from 0.00 to 99.99 exactly equally likely.

Construction 2: the Stake-style float. Take the first 4 bytes of the same HMAC: 75, 152, 149, 223 in decimal. Build a fraction: 75/256 + 152/256² + 149/256³ + 223/256⁴ = 0.295297. Multiply by 10001, floor, divide by 100: the roll is 29.53 on a 0.00 to 100.00 scale. Stake's message string also appends a round counter, and byte-based games draw further bytes from extra HMAC rounds when needed.

Same inputs, different published constructions, both deterministic. A site is fair as long as it documents its construction precisely and your recomputation matches. Both of the above are checkable with ten lines of Python or any HMAC calculator.

The proof completes when you rotate. Requesting a new seed pair forces the site to reveal the retired server seed, and from there verification is mechanical:

1. Check the commitment. SHA-256 the revealed seed. It must equal the hash you were shown before betting. Our example seed hashes back to 9cf672...7578, matching the commitment exactly.
2. Recompute the rolls. For each bet, compute HMAC-SHA256 with the revealed seed, your client seed, and that bet's nonce, then apply the site's documented conversion. Nonce 2 in our example yields hex c063d, decimal 788029, roll 80.29. Nonce 3 yields 47935, roll 79.35.
3. Compare against history. Every recomputed number must equal the roll the site displayed at the time. One mismatch is proof of tampering, not bad luck.

You do not need to code any of this: paste the revealed seed, client seed, and nonce into our free provably fair dice verifier and it recomputes rolls in both constructions instantly.

Two honest caveats. Verification is retroactive; it proves past rolls were untampered but cannot bless future ones, which is why you rotate and re-check periodically. And fair generation says nothing about payouts: a site can roll honest numbers and still refuse withdrawals. Fairness tooling is one pillar of our reviews of the best bitcoin dice sites; cashout testing is the other.

It is worth being precise about the boundary of the guarantee, because both scammers and cynics blur it.

Guaranteed:

• The server seed existed, unchanged, before your first bet against it.
• Your client seed entered every calculation, so outcomes were not selected against you.
• Every roll is recomputable by anyone, and any discrepancy is cryptographic evidence of cheating.

Not guaranteed:

• Positive expectation. The 99-over-chance payout table bakes in a 1% edge on perfectly fair rolls. Provably fair means honestly random, not favorable.
• Predictability. The unrevealed server seed means you cannot compute future rolls either. Anyone selling a tool that claims to predict provably fair dice is lying by definition.
• Solvency and conduct. Licensing, withdrawal reliability, and support quality live entirely outside the protocol.

Read it as a division of labor. Cryptography handles the one question math can settle: were the numbers straight? Everything else, from bankroll discipline to choosing an operator that pays, remains ordinary due diligence. A dice site that offers real seed controls, documents its construction, and passes recomputation has cleared the highest bar available in online gambling; the rest of the checklist is covered across our other guides below.