What is provably fair?

The problem it solves

When you play an online game of chance, the result comes from a computer you cannot see. Traditionally you have to trust the operator, the game provider and whoever tested the software. Provably fair systems, which grew up alongside Bitcoin gambling, replace part of that trust with mathematics: you can check each result yourself.

The goal is narrow and precise. Provably fair shows that the casino committed to its randomness before you bet and could not change it afterwards to make you lose. It does not make games generous, and it does not prove a casino will pay you.

The three ingredients

Every common provably fair scheme combines three inputs:

Some games also use a fourth value, a round or cursor, when they need more random data than one hash provides.

How it works, step by step

1. The casino commits

Before you play, the casino generates a random server seed and shows you its SHA-256 hash. SHA-256 is a one-way function: you cannot recover the seed from the hash, so the seed stays secret. It is also collision resistant: the casino cannot find a different seed with the same hash. Showing the hash locks the casino into that seed.

2. You add your seed

You set a client seed. Casinos usually generate one by default and let you change it to any text. Because you can choose it after the casino has committed, the casino cannot pick a server seed that produces bad results for your seed in advance.

3. Each bet is computed

For each bet, the casino computes HMAC-SHA256 using the server seed as the key and a message built from the client seed, the nonce and a round number:

HMAC-SHA256(serverSeed, clientSeed:nonce:round)

The 32-byte output is turned into numbers between 0 and 1, and the game converts those into a dice roll, a limbo multiplier, plinko bounces or mine positions. The nonce then increases by one for the next bet.

4. The casino reveals

When you rotate to a new seed pair, the casino reveals the old server seed and commits to a new one. Now you can check two things: that SHA-256 of the revealed seed equals the hash you were shown, and that every bet you made with it reproduces exactly.

Why both seeds matter

If only the casino supplied randomness, it could generate millions of candidate server seeds, simulate typical player behaviour, and commit to one that performs badly for players. The hash commitment would still match. Your client seed prevents this, because it enters the calculation after the commitment and the casino cannot know it in advance.

This is why the ability to change the client seed is essential. A casino that fixes the client seed, or ignores changes, has removed the player's half of the protection.

Why seeds must be rotated before reveal

The server seed can only be revealed once no more bets will use it. If you could see the active seed, you could compute the next result before betting. So you verify in batches: play, rotate, then check. That delay is by design.

What provably fair proves

• The result of each verifiable bet was determined by seeds committed before the bet.
• The casino did not swap the server seed after seeing your bets.
• The casino did not alter individual results.
• The nonce sequence shows whether bets were skipped or replayed.

What it does not prove

• It does not change the house edge. A dice game with a 1% edge remains a 1% edge. Verification only confirms the game formula was applied honestly.
• It does not cover every game. Third-party slots, live dealer tables and sportsbooks generally use other systems and cannot be checked with your seeds.
• It does not prove the formula is fair. You can verify that results follow the published formula; you must separately check that the formula's payouts match the advertised RTP.
• It does not prove solvency or payouts. A casino can run fair games and still refuse withdrawals.
• It only works if you check. A system nobody verifies offers little protection.

Implementations differ

The scheme above is the most common, but not universal. Casinos differ in:

• Whether the hash is computed over the seed as text or as raw bytes.
• The order and format of the HMAC message, or whether the client seed is the key.
• Whether the nonce starts at 0 or 1.
• How bytes become floats, and each game's formula.
• Whether multiplayer games such as crash use per-player seeds or a shared hash chain.

Always read the casino's own fairness documentation. Our audits document each casino's exact scheme.

How to start checking

1. Before playing, note the hashed server seed somewhere outside the casino.
2. Change your client seed to something of your own.
3. Play as normal.
4. Rotate your seeds and copy the revealed server seed.
5. Use our verifier to confirm the hash and recompute a few bets. Our guide on how to verify a provably fair bet walks through each step.

Provably fair and responsible play

Fair does not mean favourable. Verifiable games are often fast, which means you can wager a large total in a short time, and the house edge applies to every bet. Set limits before you play, and see our responsible gambling page if it stops being fun.

Red flags in an implementation

Not every system called provably fair offers the same protection. Warning signs include:

• No way to change the client seed, or changes that do not appear in bet records.
• No hash shown before play, or a hash that is only shown after you rotate.
• Missing or vague documentation, with no formula you can reproduce.
• Nonces that skip or repeat in your bet history.
• The whole lobby labelled provably fair, including third-party slots and live tables.
• Verification only through the casino's own tool, with no way to check independently.

Any one of these weakens or defeats the purpose. Our audits check for each.

A note on terminology

Casinos use different names for the same parts: "server seed" may appear as "house seed", the "client seed" as "player seed", and the "nonce" as "bet number" or "game number". The "round" may be called "cursor" or "iteration". The concepts are the same.

Where provably fair came from

The idea grew out of early Bitcoin gambling sites, where operators were anonymous and players had no regulator to turn to. Publishing a hashed seed in advance was a way to give players something they could check without trusting the operator. Over time the HMAC-SHA256 approach with server seed, client seed and nonce became the most common pattern, and many crypto casinos now use close variants of it for their in-house games.

The underlying building blocks are standard and well studied. SHA-256 is specified by NIST in FIPS 180-4, and HMAC is specified in RFC 2104. What varies between casinos is how they combine these into game results, which is why documentation matters as much as the cryptography.

Sources

• https://pigmo-doc.gitbook.io/pigmo.com/fairness/implementation
• https://docs.rs/crate/fair/latest/source/src/rng.rs
• https://datatracker.ietf.org/doc/html/rfc2104
• https://csrc.nist.gov/pubs/fips/180-4/upd1/final