You open the game history, copy a server seed, a client seed, a nonce, and a long hash string, then hit a wall: which part actually turns into the dice number?
For a provably fair dice game, the roll is usually derived from a cryptographic function that combines those values in a fixed order. The exact layout can vary by implementation, but the underlying pattern stays the same: the game commits to a hidden server seed first, mixes it with your client seed and a nonce, then maps the resulting hash output to a roll range.
That is what people usually mean by the provably fair formula for dice roll. It is not one universal equation shared by every site. Instead, it is a family of verifiable methods built on the same parts.
What the four inputs do
Start with the pieces shown on the fairness page or in the bet log.
| Input | Role in the formula | Why it matters |
|---|---|---|
| Server seed | A secret value generated before play | Used to create the hidden basis for outcomes |
| Server seed hash | A hash of the server seed published before reveal | Lets you check later that the server seed was not swapped after the bet |
| Client seed | A value supplied by the player or interface | Adds player-side input to the calculation |
| Nonce | A counter that increases each bet | Prevents the same seed pair from producing the same result every round |
The server seed stays hidden while you are betting. Only its hash is shown in advance. After a seed rotation or reveal, you can hash the disclosed server seed yourself and compare it with the old published hash.
If they match, the operator did not change that seed after publishing the commitment. That is the first thing the system proves.
Step 1: The hash commitment happens before the roll
Before any visible result is produced, the game generates a server seed such as a long random text string. It then applies a hash function, commonly SHA-256, to that seed.
Imagine the hidden server seed is:
server_seed = "m7Kx9..."
After hashing, the game might publish something like:
SHA256(server_seed) = 9f4c...e21a
You see only the hash, not the underlying seed. That matters because cryptographic hashes are designed so that publishing the hash does not reveal the original input in any practical way, but changing the input later would produce a different hash.
As a result, the game can commit to one hidden seed before the round and disclose it later for verification.
Step 2: The client seed and nonce are added
A dice game still needs a fresh result every bet. Reusing the same input would repeat the same output.
That is where the client seed and nonce come in. The client seed is often editable by the player. The nonce is usually an integer starting at 0 or 1 and increasing by one for each wager made under that seed pair.
One common input layout looks like this:
message = client_seed + ":" + nonce
Then the game computes a keyed hash, often:
HMAC_SHA256(key = server_seed, message = client_seed + ":" + nonce)
Some implementations reverse the order or include extra separators, round IDs, or cursor positions. Others use plain SHA-256 on a combined string instead of HMAC-SHA256. That variation is why a verifier must know the exact formula used by that specific game.
Still, the structure is broadly recognizable: hidden server seed, visible client seed, visible nonce, deterministic hash output.
Step 3: The hash output is turned into a roll
The hash function produces hexadecimal characters, not a dice number. A conversion step is needed.
For a 0.00 to 99.99 dice format, a common approach is to take part of the hash output, convert it from hexadecimal into an integer, then reduce it into the target range.
Here is a simplified example:
hash = HMAC_SHA256(server_seed, client_seed + ":" + nonce)first_8_hex = hash[0..7]number = hex_to_int(first_8_hex)roll = (number % 10000) / 100
If first_8_hex converted to decimal were 58321467, then:
58321467 % 10000 = 1467roll = 14.67
That is a readable example, not a universal formula. Some dice games use five decimal places internally. Some output integers from 0 to 99, from 1 to 100, or from 0 to 9999 before formatting. Others avoid simple modulo steps because of distribution concerns and instead read chunks of the hash until they get a value inside an accepted range.
The verification page should state which method is used. Without that mapping rule, you cannot reproduce the exact roll even if you have all four inputs.
Why some formulas use HMAC instead of plain hashing
HMAC-SHA256 appears often because it is a standard way to combine a secret key with a message. In this setup, the server seed acts as the key and the client-seed-plus-nonce string acts as the message.
That gives a deterministic output. Enter the same server seed, client seed, and nonce again, and you get the same hash again.
Equally, change just one character in the client seed or move the nonce from 12 to 13, and the output changes drastically. A tiny input difference produces a completely different result, which is exactly what a fairness checker wants.
A full worked example of the verification flow
Suppose a dice round shows these fields after reveal:
| Field | Example value |
|---|---|
| Published hash before play | ab12...9cfe |
| Revealed server seed | R4vN2pL8xQ |
| Client seed | player-27 |
| Nonce | 41 |
You would verify it in this order.
First, hash the revealed server seed with the stated algorithm, commonly SHA-256. If the output equals the hash that was published before the round, the commitment checks out.
Next, rebuild the game formula exactly as documented. For example:
hash = HMAC_SHA256("R4vN2pL8xQ", "player-27:41")
Then apply the roll-conversion rule stated by that game. If the reproduced roll matches the recorded roll in the bet history, the result was generated from the disclosed inputs rather than altered afterwards.
The check is mechanical. Either the numbers match, or they do not.
What provably fair does prove
The phrase sounds broader than it is. In a dice game, this mechanism verifies a narrow but useful claim about round integrity.
- The revealed server seed matches the earlier published hash commitment.
- The recorded roll can be reproduced from the server seed, client seed, nonce, and stated formula.
- A bet result was not changed after the seed commitment, assuming the disclosed formula is the one actually used.
That is why the nonce matters so much. It creates a distinct input for each bet, making the sequence auditable one round at a time.
What provably fair cannot prove
This is the part many readers miss.
Provably fair does not prove that every part of a gambling service is honest, financially sound, or independently audited. It does not verify balances, withdrawal handling, account restrictions, or whether every game on the site uses the same method.
Nor does it mean the player can predict future results. Because the server seed stays hidden until reveal, the hash commitment lets you check the past, not see ahead.
A few limits matter in practice:
- It does not prove solvency.
- It does not prove that support decisions or account actions are fair.
- It does not prove that a different unpublished formula was never used unless you can verify the exact implementation provided for that game.
- It does not guarantee favorable outcomes in any session.
For the same reason, provably fair is different from RNG certification. An RNG determines outcomes in many digital games, and independent testing laboratories are commonly used to certify RNG behaviour. Provably fair, by contrast, is a cryptographic verification method for individual rounds. One is an external testing model; the other is a player-side reproducibility model.
Common formula variations you may see
Not every dice checker uses the same notation. Small differences can break a verification attempt, so the details matter.
| Variation point | One possible form | Another possible form |
|---|---|---|
| Hash method | HMAC-SHA256 | SHA-256 on concatenated text |
| Input order | server seed as key, client seed:nonce as message | client seed:nonce:server seed as one string |
| Nonce start | 0 | 1 |
| Roll range | 0.00 to 99.99 | 1 to 100 or 0 to 9999 |
| Chunk reading | first 8 hex characters | read successive chunks until valid range found |
One missing colon is enough to produce a different result. So is assuming the nonce began at 1 when the game began at 0.
That is why the safest approach is to copy the platform's own formula description exactly, then reproduce it in a local script or a trusted hash tool.
How to read a fairness page without getting lost
The practical question is usually not “what is hashing?” but “where did my 62.48 come from?”
Look for these items in the round record:
- the pre-published server seed hash
- the revealed server seed after rotation or reveal
- your client seed
- the nonce for that bet
- the exact hash algorithm and roll-mapping rule
If any one of those pieces is missing, a complete independent check becomes harder or impossible.
Across the sites surveyed, cryptocurrency options and interface layouts varied a lot, which is one reason fairness pages also vary. The formula itself, however, is usually built from the same core ingredients described above even when the labels or formatting differ.
FAQ
What is the usual provably fair formula for dice roll?
There is no single universal formula. A common pattern is HMAC-SHA256 using the server seed as the key and a message built from the client seed and nonce, followed by a rule that converts part of the hash output into the game's roll range.
Can I predict the next dice roll from the published hash?
No. The published hash is a commitment to the hidden server seed, not the seed itself. You can usually verify a roll after the server seed is revealed, but the hash alone does not let you calculate future outcomes in advance.
Does provably fair mean the whole casino is fair?
No. It verifies that a specific game round can be reproduced from stated inputs and that the committed server seed was not changed after publication. It does not by itself prove anything about payouts, balances, account decisions, or overall business conduct.
Play responsibly
Gambling should be treated as paid entertainment, never as a way to earn income or recover losses.
18+ or 21+ depending on where you are; follow the minimum age that applies to you.
Help line (US): 1-800-MY-RESET (1-800-697-3738)
This article is general information about how these mechanics work. It is not legal advice and not a recommendation to gamble or to use any particular operator. Availability and legality differ by jurisdiction — check the rules that apply where you are.