Provably fair dice: how randomness is verified

Dice games are among the most transparent crypto-style instant games, because most of them are provably fair. The system lets you verify yourself that each roll was random and was not changed after you placed your bet. This guide explains how it works and how to check a roll.

A provably fair dice game publishes the inputs of each roll so you can rerun them. The casino commits to its secret before the bet. Your browser supplies a second secret the casino sees only after you have chosen it. A counter separates one bet from the next under the same pair of secrets. Those three values go into one formula, and the formula returns one number on a scale the game then maps to a dice face or a point on a slider.

The check happens after the session, when the casino reveals the secret it hashed at the start. You hash that revealed secret and compare it with the hash you saved. A match means the secret is the one the casino committed to. The same three values, run through the published formula, should reprint the roll on the screen. For the bet controls and the fairness panel, read the dice game guide.

Two terms come up throughout this guide. A commitment is the hash the casino shows before you bet. A reveal is the server seed the casino discloses later, either after the round or when it rotates to a new pair of seeds.

A check only works when both terms refer to the same seed pair. Keep the commitment and the reveal together, and treat a reveal as valid only when it belongs to the bets you placed under that commitment.

Provably fair rests on two inputs: the server seed and the client seed. Before a round, the casino's server creates a secret seed and shows you a cryptographic hash of it. Your browser or app creates its own seed, which you can usually change. The two seeds are combined, together with a counter for each bet, to produce the roll.

Neither side can steer the result. The casino has committed to its seed before the round, so it cannot change it afterwards, and your seed adds input the casino could not know in advance.

The server seed is a long random string stored on the casino's side. The casino hashes that server seed with SHA-256 and shows you the hash in the fairness panel before the first bet of the pair. The client seed is a string your browser generates, and the fairness panel usually lets you type a replacement before the next bet. A nonce, sometimes labelled bet number or cursor, is an integer that increases by one for every bet that uses the same server seed and client seed. The roll function reads the server seed, the client seed and that nonce as one input.

Changing the client seed does not alter the results of earlier bets. It sets the input for the bets that follow the change. A client seed you type yourself is useful for an independent check, because you choose it after the casino has committed to its server seed.

The nonce keeps bets apart. Each bet under the same seed pair uses a different nonce, so no two bets share the same input. A roll can only be reproduced when you know the nonce that produced it.

The server seed's hash is made with SHA-256, a one-way function: it turns any input into a fixed-length string, and the string cannot be turned back into the seed. Showing you the hash first locks the seed in without revealing it.

After the round, or when you rotate to a new seed pair, the casino reveals the original seed. Hash it yourself with SHA-256 and compare. If the hashes match, the seed was not changed, and the roll was fair.

1. Note the hashed server seed and your client seed before you bet.
2. After the round, copy the revealed server seed from the game's fairness tab.
3. Run it through any SHA-256 tool; several work in a phone browser.
4. Check that the result matches the hash you saw before the round.
5. Optionally, enter both seeds and the bet number in the casino's verifier or an independent one to recreate the exact roll.

SHA-256 always returns 64 hexadecimal characters for any input, including a short seed and a long one. The function is one way, so the hash does not reveal the seed. A match after the reveal is evidence that the seed string is unchanged, character for character.

A mismatch means the revealed seed is a different string from the one hashed before you bet. Keep a screenshot of the earlier hash. The fairness tab should show the nonce that belonged to that bet. A verifier asks for the server seed, the client seed and that nonce, which are the three inputs the game used.

The timing of the copy matters. Save the hash before the first bet of the pair, because a hash copied after the reveal only shows that the seed matches what you already have. A hash saved in advance is the evidence that the casino could not change its seed later.

Hash functions are deterministic, so anyone with the same seed gets the same 64 characters. You do not need an account, a download or the casino's permission to run the test. Any tool that supports SHA-256, or a short script on a computer, returns the same output.

Once combined, the seeds go through a fixed algorithm that turns them into a number, which becomes the dice result. The same seeds always give the same result, so anyone can reproduce a roll and check it. Because both inputs are needed, no one could have set the outcome in advance.

The usual dice formula takes a keyed hash of the server seed, with the client seed and the nonce as the message. The first bytes of that hash become an integer. The game scales that integer into the dice range shown on the screen, and that scaled value is the roll. The same three inputs always produce the same roll, which is why a public verifier can reprint the result without asking the casino to roll again.

Your choice of over or under decides whether the roll wins. The game compares the roll with the target you picked, and the paytable sets the payout for that choice. The paytable applies the house edge afterwards, which is a separate step from the fairness check.

A worked check follows the same order every time. First, collect the server seed, the client seed and the nonce for one bet. Second, run them through the formula or a public verifier. Third, compare the output with the roll that appeared on screen.

If the numbers agree, the roll is confirmed for that bet. If they disagree, one of the three inputs is wrong, so check each input before you judge the game. The most common cause is a nonce that belongs to a neighbouring bet.

In many traditional RNG games the randomness is a black box: you trust the casino and the testing lab. Provably fair dice lets you verify every roll yourself. That matters most at crypto casinos, where players often cannot check a licence as easily. The game is simple enough that the check is easy to follow, which makes it a good place to learn how provably fair works.

Keep in mind what it proves. Provably fair shows the result was random and not changed. It does not change the game's RTP or house edge.

A certified random-number generator is tested in a lab, and the lab's report is what a regulator sees. You do not receive the seed of each spin. Provably fair dice hands you the seed after the session so you can run the check on your own phone. The trade-off is scope. The check covers the rolls that used the revealed seed. It does not audit the casino's wallet, its bonus terms or the return-to-player figure printed beside the slider.

Read the return-to-player figure on the game screen beside the slider. The house edge is the share of each bet the paytable keeps. A verified roll can still lose money on average, because the check only shows that the number was fixed before you clicked bet.

A certification and a provably fair check answer different questions. A lab certificate says that a generator passed statistical tests at the time of testing. A provably fair check says something about one specific roll. A casino that offers both gives you two kinds of evidence, and you can weigh each one against what it covers.

A provably fair check starts from data the casino chooses to reveal. If the fairness panel never shows a server-seed hash before the bet, you have nothing to compare later. If the panel reveals a seed but hides the nonce, you cannot tell which bet the seed belonged to. Save the hash, the client seed and the nonce while they are on screen. A later reveal that does not match those three values fails the check.

After the casino reveals a server seed, that seed is spent, and a new hash should appear before the next session. The working order is hash first, bets under that hash, reveal, then a new hash.

The check also does not show whether the casino holds a valid licence, whether it pays winnings in full, or whether a withdrawal is processed on time. Those points sit in the casino's terms and in its licence records. Provably fair answers one question: whether the roll was fixed by the seeds before you bet.

A roll can only be checked later if you saved its inputs while they were visible. Take a screenshot of the fairness panel before you place the bet. The screenshot should show the server seed hash, the client seed and the current nonce. A second screenshot after the bet helps, because the bet history usually shows the outcome next to the nonce.

Store the saved values in one note with the date and the game name. A simple table with one row per seed pair works well. Each row lists the hash, the client seed, the first and last nonce used, and the revealed server seed once it appears. The table shows which bets a reveal covers, so a mismatch is easy to trace.

Most failed checks come from a small set of errors. The list below covers the ones that appear most often.

• Copying the hash after the reveal, which proves nothing about the earlier round.
• Mixing a client seed from one session with a server seed from another.
• Using the next bet number instead of the nonce of the bet being checked.
• Hashing the seed with a tool that adds a line break or a space, which changes the output.

Each mistake changes the input, so the output will not match even when the game was fair. Re-check the three inputs first, before you conclude that a casino changed a seed. If the inputs are correct and the hash still differs, the reveal is the problem, and your saved screenshots are the evidence to send to the operator's support team.

Dice is not the only one. Plinko uses the same client and server seed system, and so do crash games, Mines, Limbo, coin flip, wheel games and keno. Some card games and slots at crypto casinos use it too. If you can verify a dice roll, you can verify these too.

Each of those games still uses a server seed, a client seed and a nonce. Plinko maps the hash bytes onto a path through the pegs. A crash game maps them onto a rising multiplier. Mines maps them onto mine positions on the grid. The hash check stays the same. The game's fairness page should describe that last conversion in plain steps. For Mines specifically, see are Mines games really provably fair.