Provably fair is a design pattern that lets players verify that the casino could not change an outcome after you placed your bet. In practice, the operator commits to a hidden value (server seed) up front, combines it with your value (client seed) and a round counter (nonce), and later reveals the server seed so you can recompute and confirm the result. This mirrors the commit–reveal idea from cryptographic commitment schemes, which ensure a value is fixed at commit time and revealed later without being alterable.
The standard model: server seed, client seed, nonce
Before you play, the casino shows a hash of its server seed (the commitment). You set or accept a client seed. For each round, a nonce increments (0, 1, 2, …) to make inputs unique. The game derives randomness from these inputs using a cryptographic function such as HMAC with SHA-256/512, then maps bytes to a roll, card order, or outcome. After you rotate seeds, the casino reveals the previous server seed; you hash it to confirm it matches the earlier commitment, then reproduce each round using server seed + client seed + nonce. If your recomputation matches, the round was not altered post-bet.
A common worry is whether your client seed could be used to force wins. That only becomes possible if the casino reveals its server seed before you bet; properly implemented systems reveal only the hash prior to play, so you cannot know the server seed in advance. Verification happens only after the server seed is rotated.
Why hashes and HMACs are used
Hashes like SHA-256 provide a one-way commitment: you can publish a hash now and reveal the preimage later, proving you didn’t change it. HMAC wraps a hash with a secret key to generate deterministic, tamper-evident bytes for randomness. Both are well-specified primitives in open standards, which is why many provably fair systems lean on SHA-2 and HMAC.
Where this shows up in real games
Many crypto titles document their exact seed/nonce workflow. Examples include dice and “crash” games, as well as card/roulette variants that map generated bytes to shuffles or wheel sectors. Some systems pre-commit to long chains of hashes so future rounds are fixed and cannot react to your bets, with public verifiers to recompute outcomes.
Step-by-step: how to verify a round
Rotate or set your client seed; note the displayed hash of the server seed before play.
Play normally; record the nonce used for the round you want to check.
When you change seeds, the casino reveals the previous server seed. Hash it and confirm it equals the commitment you saw earlier.
Use a verifier or the casino’s documentation to recompute the outcome from server seed, client seed, and nonce; compare it with the game’s result. If they match, the round was fixed at commit time and not changed afterward.
Provably fair vs RNG certification vs on-chain VRF
| Fairness model | What it proves | Typical where | Player verification | Notes |
|---|---|---|---|---|
| Provably fair (commit–reveal) | Outcome was fixed pre-bet and not altered post-bet | Crypto casinos, off-chain RNG titles | Player recomputes with server/client seed + nonce | Requires careful seed rotation and transparent docs |
| RNG certification | Randomness engine and game implementation meet regulator or industry standards | Licensed online casinos; most digital table games and slots | Players rely on approved labs/test houses | eCOGRA and others test unpredictability, bias, and compliance; separate from provably fair checks |
| On-chain VRF | Random value and proof are generated and verified on-chain before use | Web3/native smart-contract games | Proof verified by smart contracts automatically | Chainlink VRF publishes randomness plus cryptographic proof on-chain |
Independent testing labs describe RNG scopes and compliance duties, while UK regulators require approved test houses and submission of game/RNG results. For on-chain use, VRF provides a verifiable random value with an on-chain proof that consuming contracts must check before proceeding.
What provably fair does not guarantee
Provably fair proves the casino didn’t change results after you bet; it does not change house edge or RTP. It is compatible with any house advantage the operator publishes, and you should still check licensing and testing pages for the games you play. It also does not apply to live-dealer games, where outcomes come from a physical shoe and oversight relies on licensing and studio controls rather than per-round cryptographic proofs.
Common pitfalls and best practices
Do not confuse a visible server seed hash with the seed itself; you cannot derive the seed from the hash. Only after rotating seeds is the server seed revealed for verification.
If documentation doesn’t specify seeds, nonces, and a determinism recipe (e.g., HMAC input and mapping to game events), you cannot reproduce results—treat that as a red flag. Community and vendor write-ups show what good disclosures look like.
Crash/dice implementations often publish a verifier or chain of hashes so you can check that future rounds were predetermined and not reactive to bets.
Quick glossary
Server seed: secret value chosen by the casino, committed via hash before play and revealed after rotation for verification.
Client seed: value under the player’s control; combined with server seed to prevent the house from grinding favorable outcomes.
Nonce: per-round counter ensuring each outcome uses unique input material, even with the same seeds.
HMAC: keyed hash construction used to turn seeds and nonces into deterministic bytes for randomness.
Commitment scheme: two-phase commit/reveal primitive that underpins the design.
VRF: verifiable random function that outputs randomness plus a proof checked on-chain.
FAQs
Is provably fair the same as being licensed or RNG-certified
No. Provably fair gives you per-round transparency; licensing and RNG certification cover system-level integrity under regulatory standards and approved testing. Ideally you want both.
Can a casino game react to my bet in a provably fair system
Proper designs commit to outcomes in advance (or to a seed chain), so the result cannot change in response to wager size or timing. Some projects expose public verifiers or hash chains to demonstrate this.
If client seeds are user-chosen, couldn’t I pick a winning one
Not if the server seed is hidden. Since you only see a hash of the server seed beforehand, you cannot compute the server seed to search for a winning combination. The server seed is revealed only after rotation for verification.
Do live-dealer games support provably fair
Not in the cryptographic sense. Live streams rely on licensing, studio procedures, and regulator audits; per-round proofs are for digital RNG or on-chain games.
What about on-chain casinos
On-chain games often use VRFs so each random value includes a cryptographic proof that smart contracts verify on-chain before using it.
