How Provably Fair Works: Seeds, Hashes and Nonces

KEY TAKEAWAYS

• Provably fair is a commit-and-reveal method: the game publishes a hash of its secret server seed before play, then reveals the seed so anyone can check it was not changed.

• Each result is typically derived from three inputs, the server seed, a client seed and a nonce (a counter), using a published, repeatable formula.

• SHA-256, specified by NIST in FIPS 180-4, produces a 256-bit digest; finding a different message with the same digest is computationally infeasible.

• The check proves the seed was not swapped after the commitment. It does not prove the seed was random, and it says nothing about the payout table.

• Provably fair is a different kind of assurance from independent lab testing of an RNG, and neither replaces the other.

CONTENTS

01How Provably Fair Works

02The Math Behind a Verification

03Walkthrough: Checking One Result

04Variations: Provably Fair Versus Lab-Tested RNGs

05Myths, Limits and Misconceptions

06Key Facts and What to Know

07Related Concepts and Next Steps

Provably fair is a method that lets a player check, after the fact, that a game result was not changed once play began. It does this with a hash, a fixed-length fingerprint of a secret value. Before any bet, the game publishes the fingerprint of its secret “server seed”. Afterward it reveals the seed itself, and anyone can recompute the fingerprint and the game result to confirm that nothing was altered in between.

The idea matters because a random number generator (RNG) normally runs out of sight on a server, so a player cannot watch it work. Provably fair adds a receipt for the randomness: a way to confirm that the result the game showed is the one its committed inputs produce. It is a narrower promise than the name suggests, and this guide explains exactly what it covers.

The sections below describe the inputs, the math, a worked example with fictional values, how it differs from lab-tested RNGs, and the common misunderstandings.

How Provably Fair Works

A provably fair game combines three inputs to produce a result. The server seed is a secret random value chosen by the game. The client seed is a value the player can see and usually change. The nonce is a counter that goes up by one with each bet, so every bet under the same seeds gets a different result. A hash is a function that turns any input into a fixed-length fingerprint, and a commitment is a hash published to lock in a value before it is revealed.

The usual order of events is a commit-and-reveal sequence:

The game generates a server seed and publishes its hash, the commitment.
The player sets or accepts a client seed after the commitment is visible.
Each bet uses the server seed, the client seed and the next nonce to calculate the result.
Later, the game reveals the server seed.
The player hashes the revealed seed to confirm it matches the commitment, then recalculates the results.

The calculation must be deterministic, meaning the same inputs always give the same output, and the method must be public. An academic course paper and a community draft whitepaper both describe these same requirements.

The Math Behind a Verification

Two standard tools do the heavy lifting. SHA-256 is a hash algorithm specified by NIST in FIPS 180-4. Its output, called a message digest, is 256 bits long, which is 64 hexadecimal characters. NIST states that for these algorithms it is computationally infeasible to find a message that matches a given digest, or to find two different messages with the same digest, and that any change to a message will, with very high probability, produce a different digest.

HMAC is a method of combining a hash with a secret key. RFC 2104 describes it as a mechanism for message authentication using cryptographic hash functions, and the name HMAC-SHA256 means HMAC built on SHA-256. Provably fair games commonly use it so the server seed acts as the key and the client seed and nonce form the message.

The commitment and the result then follow two formulas:

commitment = SHA-256(server_seed)
digest = HMAC-SHA256(key = server_seed, message = client_seed:nonce)

The digest must still become a game outcome, such as one of 52 cards. A common step is to read part of the digest as a whole number and reduce it with a remainder. This can introduce modulo bias if the range does not divide evenly. Reading 8 hex characters gives a number from 0 to 2^32 − 1, and 2^32 = 82,595,524 × 52 + 48, so 48 cards come up one extra time in 2^32 possibilities, a relative difference of about 0.0000012%. A careful design rejects the leftover values instead.

Walkthrough: Checking One Result

This is a worked example with fictional seeds, and the values were calculated with standard tools. Suppose a game commits to the server seed example-server-seed-0001 and the player uses the client seed example-client-seed. Here is how one verification goes:

Commitment: the game publishes SHA-256 of the seed, which is 02a2b419…dd0d77 (64 hex characters).
Bet: for nonce 0 the game calculates HMAC-SHA256 with the seed as key and the text example-client-seed:0 as message, giving ce5060b3…38aac6.
Mapping: the first 8 hex characters, ce5060b3, equal 3,461,374,131.
Result: 3,461,374,131 mod 52 = 7, so this example deals card number 7 on a 0 to 51 scale.
Reveal and check: after the game reveals the seed, the player hashes it, compares it to the commitment, then repeats steps 2 to 4.

If the hash and the result both match, the seed was not swapped after the commitment.

Variations: Provably Fair Versus Lab-Tested RNGs

Provably fair and independent testing answer different questions. Lab testing examines an RNG against a technical standard, for example GLI-19, which has a chapter of RNG requirements and describes independent technical analysis and certification. Provably fair lets individual players check individual results. The table compares them in general terms.

Question	Provably fair	Independent lab testing
Who checks?	Any player, using public tools	A test laboratory, then a regulator that relies on its report
When?	After play, round by round	Before release, against a standard
What is covered?	That results follow from committed inputs	RNG design and behavior as set out in the standard being applied
What is not covered?	Seed quality, payout tables, unverified rounds	Anything outside the tested system and version
Typical fit	Games whose full seed-to-result path is published	Systems regulators require to be tested; rules vary by state

Neither approach is a verdict on a particular site. They are complementary kinds of evidence, and which one applies depends on the product and on the rules of each state.

Myths, Limits and Misconceptions

Myth: provably fair means the odds are fair. The check recomputes a result from its seeds. It does not examine the payout table, so the house edge is a separate matter that the game’s published rules describe.

Myth: the commitment guarantees the seed was random. The MIT course paper notes that these schemes guarantee the server does not change seeds based on client seeds, but they are not a guarantee that server seeds were generated at random. That is why the order matters: the server commits first and the client seed comes after.

Myth: the published hash lets a player see the result in advance. It does not. NIST states it is computationally infeasible to find a message that corresponds to a given digest, and the published value is only a fingerprint. The hash alone therefore gives no way to predict outcomes; the AI explainer linked below covers the same limit for patterns.

Limit: only verified rounds are verified. A result nobody recomputes is accepted on trust, just as it would be in any other design.

Key Facts and What to Know

The essentials are in the list below, with the steps a player can legitimately take.

Provably fair uses a hash commitment, a client seed, a nonce and a repeatable formula.
A match proves the seed was not changed after the commitment; it does not prove seed randomness or fair payouts.
Anyone can recompute a SHA-256 hash with a standard tool, so a platform’s own verifier is not the only option.
If a verification does not match, save the seeds, nonce and result and contact the platform’s support team, and where there is a regulator, its complaint process.
Check which games on a platform use the method, because it only applies where the whole seed-to-result path is published.

For the foundations, read how casino RNGs work, which covers seeds, state size and how independent labs test generators. A card-focused example appears in how online poker software deals a hand, and the limits of pattern-finding are covered in why AI cannot predict random gambling outcomes. A logical next concept is how a hardware random number generator differs from the software generators described here.

Frequently Asked Questions

What does provably fair mean in gambling?

Provably fair means a game publishes a hash of its secret seed before play and reveals the seed afterward, so a player can confirm the results followed from that committed seed. It checks that results were not changed after the commitment. It does not, by itself, prove the odds or the payouts are fair.

What is the difference between a server seed and a client seed?

The server seed is a secret value chosen by the game, committed to with a hash before play. The client seed is a value the player can see and usually change. Combining them means neither side alone decides the result, which is why the server commits first.

What is a nonce in provably fair games?

A nonce is a counter that increases with each bet made under the same seed pair. Because it is part of the input, each bet produces a different result even though the seeds stay the same. A nonce should be used only once for a given seed set.

Does provably fair mean the house edge is zero?

No. Verification recomputes a result from its inputs. It does not examine the payout table, so a game can be fully verifiable and still pay out less than the true odds imply. The published game rules describe the payouts, and they are a separate matter.

Can the published hash be used to predict results?

No. NIST states that for SHA-256 and the related algorithms it is computationally infeasible to find a message that corresponds to a given digest. The published hash is a fingerprint of the seed, so it does not reveal the seed or any result before the reveal.

Is provably fair the same as a certified RNG?

No. Provably fair lets players check individual results against committed seeds. Certification means an independent laboratory tested an RNG against a technical standard. They answer different questions, and which applies depends on the product and the rules of each state.