Provably fair explained: seeds, hashes and how to check a bet

What provably fair means

A normal online casino asks you to trust that its random number generator is honest. A provably fair game replaces that trust with a check you can run yourself. The casino commits to its part of the randomness before you bet, you add your own part, and once the casino reveals its secret you can recompute every result from scratch.

The idea grew up with bitcoin gambling sites, where players were already used to verifying things with hashes. Today almost every crypto casino's in-house games (dice, limbo, plinko, mines, crash and similar "originals") use some version of it. Stake, Shuffle and BC.Game all publish their schemes.

The important word is "provably". It does not say the game is generous. It says the casino cannot quietly change a result after it has seen your bet.

The four ingredients

Every provably fair system is built from the same parts. Names vary slightly between casinos, but the roles are the same.

Ingredient	Who sets it	Visible when	Purpose
Server seed	Casino	Only after you rotate seeds	The casino's secret randomness
Hashed server seed	Casino	Before your first bet	A public commitment to the server seed
Client seed	You (or a random default)	Always	Your randomness, so the casino cannot pre-pick results
Nonce	Counter	Always	Makes every bet with the same seed pair different

Server seed and its hash

The server seed is a long random string the casino generates. Before you place any bets it shows you the SHA-256 hash of that seed, not the seed itself. SHA-256 is a one-way function: easy to compute from the seed, practically impossible to reverse. Publishing the hash locks the casino in, because any other seed would produce a different hash.

Client seed

The client seed is a string you control. Most casinos fill it in with a random value, but you can change it to anything you like in the fairness settings. Because the casino commits to its server seed before it knows your client seed, it has no way of choosing a server seed that produces bad results for you.

Nonce

The nonce is a simple counter. It starts at 0 (or 1 at some casinos) and goes up by one with each bet you place on that seed pair. Without it, every bet would produce the same number.

How a result is made, from seeds to a dice roll

Here is the scheme Stake documents for its originals, which our provably fair verifier follows. Other casinos use similar steps with small differences.

Step 1: HMAC-SHA256

The casino computes HMAC-SHA256, using the server seed as the key and a message built from your client seed, the nonce and a round number, joined by colons: clientSeed:nonce:round. HMAC is a standard way of mixing a secret key with a message. The output is 32 bytes, usually written as 64 hex characters.

Step 2: bytes to a float

Each group of four bytes becomes one number between 0 and 1:

float = b0/256 + b1/256² + b2/256³ + b3/256⁴

One HMAC gives eight floats. Games that need more random numbers, like a 16-row plinko board or a mines grid, increase the round number to 1, 2 and so on and hash again.

Step 3: float to a game result

Each game turns floats into an outcome with a fixed formula. For Stake-style dice it is:

roll = floor(float × 10001) / 100

That gives a roll from 0.00 to 100.00 in steps of 0.01. Plinko takes one float per row and goes left or right depending on whether it is below or above 0.5. Mines draws tiles one by one from the remaining grid.

A worked example

Suppose the revealed server seed is 3f9c1a7e5b2d8046c1e9f7a3b5d20c84e6a1f9b37d5c2e08a4f6b1d3c9e7a250, your client seed is my-own-seed-42 and the nonce is 7.

• The message is my-own-seed-42:7:0.
• HMAC-SHA256 gives 299a69c6e143630a…. The first four bytes are 41, 154, 105 and 198.
• float = 41/256 + 154/65,536 + 105/16,777,216 + 198/4,294,967,296 ≈ 0.162512.
• roll = floor(0.162512 × 10001) / 100 = floor(1625.28…) / 100 = 16.25.

Paste those values into the verifier and you will see the same bytes, the same float and the same roll. That is the whole trick: anyone with the inputs gets the same output.

How to verify your own bets, step by step

You cannot check bets made with the server seed you are currently using, because it is still secret. The routine looks like this.

1. Set your own client seed. Open the casino's fairness or seeds settings and type in a client seed you chose. Note the hashed server seed shown there.
2. Play as normal. Each bet's details in your history show the nonce used.
3. Rotate the seed pair. Use the "change seeds" or "rotate" button. The casino reveals the old server seed and starts a new pair.
4. Check the hash. Compute SHA-256 of the revealed server seed. It must exactly match the hash you noted in step 1. If it does not, stop there: the casino changed its seed.
5. Recompute results. Enter the server seed, client seed and a nonce into the casino's own verifier or an independent one, such as our provably fair verifier, which runs in your browser. Compare the result with your bet history.

Spot-check a handful of bets, including your largest ones. Because every result comes from the same committed seed, one mismatch would be enough to show a problem.

When results do not match

Most mismatches are input mistakes. Check that you used the revealed server seed rather than the hash, that the client seed has no trailing spaces, and that the nonce starts where the casino says it does. If the inputs are right and a different game formula is the cause, use the casino's own verifier, which applies its exact rules.

What provably fair proves, and what it does not

A matching result proves the outcome was fixed before you bet. It says nothing about whether the odds are good. The house edge is in the payout table, not the random number.

What it proves

• The casino committed to its server seed before you bet, and did not swap it.
• The result came from that seed, your seed and the nonce, using the published formula.
• The casino could not pick results to beat you, because it did not know your client seed when it chose its own.

What it does not prove

• That the game is a good bet. Stake-style dice pays 99 ÷ your win chance, which builds in a 1% edge. That 1% applies on every provably fair bet. Our house edge guide explains why that matters more than any single result.
• Anything about games outside the scheme. Third-party slots and live dealer tables use the provider's own certified random number generator or physical equipment.
• That you will be paid. Withdrawals, limits and account checks are a separate matter. See our crypto casino safety tips.

If you want to see what a 1% edge does over thousands of provably fair rolls, run a session in the dice simulator.

Crash and other multiplayer games work differently

Multiplayer games like Crash and Slide produce one result for everyone in a round, so they cannot use your personal client seed. Instead, many casinos use a hash chain.

The casino generates a long chain of hashes in advance: it picks a final secret value, hashes it, hashes that result, and so on, millions of times. Games are then played in reverse order, so each new round's hash is the value that, when hashed, gives the previous round's hash. The casino publishes the last hash in the chain (the first one used) before play starts. Since nobody can go backwards from a hash, the casino cannot change future rounds without breaking the chain.

To stop the casino from choosing a convenient chain, the hashes are usually combined with a public salt that did not exist when the chain was made, such as a future Bitcoin block hash announced in advance. You verify a round by hashing its revealed hash and checking that it matches the previous round, then applying the published crash formula. Because the formula and salt differ by casino, use that casino's own Crash checker. Our crash simulator shows how the multiplier distribution behaves over many rounds.

Good habits with provably fair games

• Always set your own client seed. A default seed still works, but choosing your own removes any doubt.
• Rotate seeds now and then and spot-check. It takes a few minutes, and it is the only way the "provable" part actually happens.
• Read the game's stated RTP. Fair randomness on a poor payout table is still a poor bet.
• Treat verification as one check among several. A casino can run honest dice and still have slow withdrawals or unclear terms.

Provably fair is a genuine improvement in transparency. It does not change the maths of the game, and it is no reason to bet more than you planned.

FAQ