Provably Fair & RNG Certification
'Provably fair' and 'certified RNG' are two very different guarantees, and neither is a promise that the game pays you back. This lesson takes apart the commit–reveal cryptography and the lab-certification chain to show exactly what each one proves — and the house edge both leave untouched.
- Distinguish what a lab-certified RNG (GLI-19, NIST SP 800-22) proves from what a provably-fair commit–reveal scheme proves.
- Walk through commit–reveal step by step and explain why a hash published before the bet, plus a player-supplied client seed, prevents post-hoc tampering and operator-predetermined outcomes.
- State precisely what each model does NOT establish — neither removes the house edge, and provably fair says nothing about how the server seed was generated.
- Explain why fairness of process (integrity, statistical randomness) is not the same as a fair-to-you payout, and read a certificate for what it actually attests.
Two proofs that are easily confused
Digital games settle outcomes with a random number generator, and two very different regimes try to earn your trust in it. In licensed markets, a certified RNG is examined by an accredited laboratory that reviews its source code and runs statistical batteries against its output; you trust the licence and the certificate. In crypto casinos, a provably-fair scheme instead lets you verify each individual result yourself, using cryptography. Both are routinely misread as a promise that the game is a fair deal. It is not. Start from the house edge: every one of these games is built to keep a percentage of each wager over the long run. Certification and provable fairness govern how honestly the result is produced — never whether the payout is tilted in your favour.
Commit–reveal, step by step
Provably fair rests on a commit–reveal design. Before you bet, the server generates a secret server seed and publishes only its cryptographic hash — the commitment. You contribute a client seed, which you can set or change, and each bet increments a counter called the nonce. The outcome is computed deterministically as hash(serverSeed : clientSeed : nonce); on the iGamer crash demo that hash becomes a crash multiplier. Because the result is fixed the instant the round is dealt, it exists before you act. After you retire the seed pair, the server reveals the server seed. Anyone can re-hash it to confirm it matches the published commitment, and re-hash the full triple to reproduce every outcome exactly — a real verification you can run in your own browser.
Why the maths binds the operator
Two cryptographic properties do the work. A secure hash is one-way and collision-resistant, so once hash(serverSeed) is public the operator is locked to that exact seed: finding a different seed that reproduces the same commitment is computationally infeasible. It therefore cannot swap the seed after seeing your bet without the re-hash check failing. The client seed closes the other gap. Because the outcome mixes in a value the operator does not control when it commits, it cannot cherry-pick a server seed that forces a particular result for you — doing so would require knowing your client seed in advance. The nonce lets one seed pair generate a fresh, unpredictable outcome per round without re-committing. Together they make post-hoc tampering and pre-selected outcomes detectable by anyone who checks.
What provably fair does NOT prove
The verification is genuine but narrow. First, it proves integrity, not generosity: the mapping from hash to payout still contains the house edge. The Lab's crash game is provably fair and still keeps about 1% of every bet (≈99% RTP) by design. Second, it does not prove the server seed was generated fairly. If the client seed were predictable or operator-chosen, a dishonest operator could grind through many valid server seeds offline and keep the least favourable one — each still matches its own commitment. Provable fairness only defeats this when the client seed is genuinely outside the operator's control. Third, it says nothing about licensing, solvency, or whether you will actually be paid. It is a statement about one round's maths, not about the business behind it.
Certified RNGs: a different kind of proof
Certified RNGs answer a different question. Under GLI-19 (Interactive Gaming Systems, v3.0), an accredited lab reviews the generator's source code and subjects its output to statistical and independence testing; batteries such as NIST SP 800-22 — fifteen tests for detectable bias — are a common tool. Labs like GLI, eCOGRA and iTech Labs hold ISO/IEC 17025 accreditation to do this credibly, and FIPS 140-3 may validate any underlying cryptographic module. What the certificate attests is narrow but valuable: on the day of testing, the output showed no detectable statistical bias and the game behaved as declared, including its stated RTP. NIST is explicit that passing means no detectable non-randomness — not proof the source is truly random, and certainly not a promise about your session.
Fair process is not a fair-to-you payout
Line the two up and the pattern is clear. Provable fairness proves a result was committed before your bet and not altered; certification proves an RNG is statistically sound and behaved as declared when tested. Both are guarantees about the fairness of the process. Neither changes the sign of the house edge, and neither describes your particular session. A certificate does not even tell you which configurable-RTP build the operator deployed to you — same game, same seal, different maths. Treat 'provably fair' and 'lab-certified' as answers to 'was the result produced honestly?', never to 'is this a good deal for me?'. The edge is present by design; these games are entertainment with a built-in cost, not a way to make money.
Key terms
Check yourself
Fact-checks (6)
- Verified: Provably-fair systems use a commit–reveal design — the server publishes hash(serverSeed) before the round, the player adds a client seed, and after the round the revealed server seed is re-hashed to confirm the outcome = hash(serverSeed : clientSeed : nonce) was fixed in advance and not altered. Source: standard provably-fair dice/crash verifier implementations and the iGamer glossary entry 'Provably Fair'.
- Verified: Provable fairness guarantees the integrity of the randomness, not the odds — it does not remove or reduce the house edge; a provably-fair crash or dice game can be honest about its RNG and still be built so the operator wins on average (the iGamer Lab crash demo keeps about 1% of every bet, roughly 99% RTP). Source: iGamer glossary 'Provably Fair' and the Provably-Fair Verifier tool.
- Verified: GLI-19 (Interactive Gaming Systems), current version v3.0, is Gaming Laboratories International's technical standard for online/interactive gaming systems and includes RNG requirements covering source-code review and statistical and independence testing. Source: Gaming Laboratories International, GLI-19 Interactive Gaming Systems v3.0 (gaminglabs.com).
- Verified: NIST SP 800-22 Rev. 1a (April 2010) defines a suite of fifteen statistical tests for random and pseudorandom number generators; NIST states that passing indicates only no detectable non-randomness — not proof that a generator is truly random or secure — and announced in 2022 a decision to revise it. Source: NIST CSRC, SP 800-22 Rev. 1a.
- Verified: Accredited gaming test labs — GLI, eCOGRA and iTech Labs — hold ISO/IEC 17025 accreditation and test RNGs and return-to-player figures; eCOGRA additionally issues the consumer-facing 'Safe and Fair' seal and acts as an approved Alternative Dispute Resolution provider. Source: ISO/IEC 17025:2017 catalogue and the eCOGRA, GLI and iTech Labs lab profiles.
- Verified: FIPS 140-3 (effective September 2019, superseding FIPS 140-2) is the US/Canadian standard for validating cryptographic modules through the Cryptographic Module Validation Program; in gaming it is referenced for crypto-module or HSM assurance rather than as a whole-game fairness standard. Source: NIST CSRC, FIPS 140-3 and the CMVP.