GUIDE

Provably fair, actually verified: how to check a dice roll yourself

The scheme is plain arithmetic once you see it: how to reproduce a dice roll, limbo multiplier or roulette pocket yourself, and what it never proves.

Dave WaskyAUG 29, 2026 · 6 MIN READprovably-fairhow-totools

Most players treat "provably fair" as a badge. It is not a badge. It is a claim you can test in about ninety seconds, and the test either passes or it does not. Here is what it says, how to check it yourself, and what it does not say.

What the claim actually is

Provably fair says one narrow thing: this round's outcome was fixed before you bet, and the operator could not have changed it afterwards.

That is all. It says nothing about whether the game is a good bet. The gap between those two ideas is where most players get misled.

The mechanism is a commitment scheme — in Shuffle's words, "a function that allows a player and the platform to securely commit to a chosen secret value while keeping it hidden from others." The casino commits to a secret, publishes proof of the commitment, then reveals the secret so you can check it never moved.

The three inputs

Server seed. A random string the casino generates, typically 64 hex characters, kept secret while in play. Crucially, the casino shows you its SHA-256 hash before you place a single bet.

Client seed. A string you control. Your browser generates one at random and you can replace it with anything. This is the part players ignore most.

Nonce. A counter incrementing by one with every bet on that pair. It makes bet #47 differ from #46 without changing the seeds.

Games needing more randomness than one hash provides add a cursor — a second counter producing extra blocks of bytes from the same pair.

From seeds to bytes to a number

The three values feed into HMAC-SHA256. The server seed is the key; the message is the other values joined. Shuffle's implementation page gives it plainly: an HMAC is created with the server seed as key, then updated with the client seed, nonce and round joined by colons.

Stake's originals use the same shape: HMAC-SHA256 keyed on the server seed, with clientSeed:nonce:cursor as the message.

SHA-256 outputs 32 bytes, sliced into eight chunks of four. Each chunk becomes a float between 0 and 1 positionally: first byte ÷ 256, second ÷ 256², third ÷ 256³, fourth ÷ 256⁴, summed.

That float is the raw randomness. Everything after it is arithmetic.

A worked example

Take a hypothetical four-byte chunk — 110, 25, 74 and 200. (Illustrative; do not expect these from a real bet.)

110 ÷ 256 = 0.4296875
25 ÷ 65,536 = 0.0003814697265625
74 ÷ 16,777,216 = 0.0000044107437
200 ÷ 4,294,967,296 = 0.0000000465661

Sum: 0.4300734270364046

Now map that one float into three games.

Dice. Multiply by 10,001, floor, divide by 100, giving a roll from 0.00 to 100.00. Here: 0.4300734 × 10,001 = 4301.164, floored to 4301, ÷ 100 → 43.01.

Limbo. The multiplier is the return-to-player constant times a large fixed divisor, over that divisor times the float plus one. With a divisor of 2²⁴ and an RTP of 0.99, that gives 2.30193, rounded down → 2.30.

Roulette. European single-zero wheel, 37 pockets. Multiply by 37 and floor: 0.4300734 × 37 = 15.913 → pocket 15.

Check the method against the operator's own example rather than ours: Shuffle documents a float of 0.43053962965495884 producing dice 43.05, limbo 2.29 and roulette pocket 15. Run those formulas by hand and you land exactly there.

Why the pre-published hash is the whole trick

Without a hash published in advance, the scheme collapses. The casino could pick a server seed after seeing your bet, choose one producing a loss, and show you a verification that checks out perfectly.

Two properties of SHA-256 stop this. Pre-image resistance means nobody can work backwards from the hash to the seed. Collision resistance means the operator cannot find a second, more convenient seed hashing to the published value.

Sequence matters more than maths: hash published, then you bet, then seed revealed. Any other order proves nothing.

Rotating seeds and checking a past bet

The server seed stays hidden while active — otherwise you could predict the next roll. To see it, rotate the pair. Per Shuffle's help centre:

Open the bet details and choose to rotate the pair.
Enter your next client seed and confirm. Finish in-progress rounds first.
Reopen the bet. The old server seed now shows unhashed; your client seed and nonce are unchanged.
Put the server seed, client seed and nonce into a verifier.
Confirm the output matches your bet slip.

Then do the step almost everyone skips: hash the revealed server seed with SHA-256 and compare it to the hash shown before you played. If those strings do not match character for character, the verification is worthless — the seed was swapped. This is the most important check in the process.

One caution: implementations differ between operators. The order and separators in the HMAC message vary, and some operators key HMAC-SHA512 rather than SHA-256. A generic verifier that "fails" may just be using the wrong recipe. Read the operator's own documentation before accusing anyone.

What it does not cover

Provably fair applies to in-house originals only. Shuffle states it directly: "Only Shuffle Originals currently offer full player verification. Shuffle does not have control of game mechanics on third-party games, which use separately certified RNG systems."

So third-party slots, live blackjack and game-show wheels are not verifiable by you. Those rely on RNG certification and RTP audits from labs like GLI, iTech Labs or eCOGRA, plus equipment inspection for live tables. Real assurance — but a statistical claim checked by a third party, not a per-round proof you can run yourself.

If a casino's trust pitch is "provably fair" while most of its lobby is third-party content, most of what you play is not covered by the pitch.

Provably fair is not a low house edge

Be blunt about this one: a game can be perfectly provably fair and still be a bad bet.

Look again at the limbo formula. The RTP term is hardcoded to 0.99. The house edge is not hidden somewhere the cryptography protects — it is written into the outcome function in plain sight. Verification confirms the maths ran honestly; it does not make the maths favourable.

Dice makes the same point. The payout identity is multiplier = 99 ÷ win chance. A 49.5% chance pays 2×: expected value 0.495 × 2 = 0.99. A 1% chance pays 99×: 0.01 × 99 = 0.99. Every setting returns 99 cents on the dollar — a constant 1% edge that provable fairness does not move.

Roulette is worse and equally verifiable: 37 pockets, a single number pays 36×, so 36 ÷ 37 = 0.973. A 2.7% edge, baked into the wheel.

How to read a published edge

RTP and house edge are one number stated two ways: they sum to 100%. A 99% RTP is a 1% edge. Check three things:

Per-game or lobby-wide average? An average is near meaningless; titles vary enormously.
For originals, is the edge in the formula? If the conversion code is published, read the RTP constant yourself, as with limbo's 0.99.
For third-party games, is there a named lab and a dated report? "Audited" without a certifier, scope and date is not an audit claim. It is a word.

An audited RTP describes aggregate behaviour across millions of rounds. It tells you nothing about your session.

Red flags

No server seed hash before you play. Non-negotiable. If the commitment is not published in advance, the scheme is decorative.

Seeds you cannot rotate, or rotation that never reveals the old server seed. If the secret stays secret, nothing is verifiable — you are trusting, not checking.

Verification that only works inside the casino's own tool. A closed verifier can be programmed to return "valid" for anything. Real provable fairness reproduces in any independent implementation.

"100% RTP" or "zero edge" marketing with no audit. Operators do not run games at zero margin out of goodwill. Where the claim is technically true, the cost has usually moved elsewhere — spreads, rake, fees, wagering conditions. Ask where.

A client seed you cannot change. If the casino controls both seeds, your contribution to the randomness is gone.

Site-wide "provably fair" branding covering only a handful of originals. Check the scope, not the banner.

Check it yourself

None of this needs taking on faith, including from us. 99Gamblers hosts a free client-side verifier on its Tools page covering dice, limbo, roulette and raw floats. The HMAC-SHA256 is computed in your browser — nothing leaves the page, and no seed you paste is transmitted to us.

We check our own arithmetic against the operators' published worked examples, and we fix it when it drifts: writing this piece is how we caught our own limbo conversion overstating very high multipliers by about 1%.

Rotate a pair, paste the values in, confirm your own bet. That is the entire point of the design.