18+ --:--:-- UTC
By ·Extensions·14 min read·verified 2026-08-05

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.

Key takeaways
  • “Provably fair” and “certified RNG” are different guarantees, and neither is a promise that the game pays you back.
  • Commit–reveal publishes a hash of the outcome before the bet and mixes in a player-supplied client seed — so the operator cannot change or pre-determine the result after the fact.
  • A lab-certified RNG (GLI-19, NIST SP 800-22) proves statistical randomness and integrity; it says nothing about your chance of winning.
  • Fairness of process is not a fair-to-you payout — both models leave the house edge completely untouched.
By the end you can
  • 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.

Quick check
In a commit–reveal provably-fair scheme, what does the server publish before you place your bet?

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.

Quick check
Why can't a provably-fair operator cherry-pick a server seed that forces a losing outcome after seeing your bet?

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.

Quick check
A crash game is genuinely provably fair. What does that verification prove?

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

Check yourself · 1/3
A crypto crash game is 'provably fair' and you verify every result. What does that verification actually prove?
Check yourself · 2/3
In commit–reveal, why does the player-supplied client seed matter?
Check yourself · 3/3
A slot's RNG is certified by an accredited lab against NIST SP 800-22. What does that certificate establish?
Next → Finish the track with “Market Entry: Reading a Jurisdiction” — putting licence, tax and change-watch together like a professional.

Go deeper

Sources (5)

Verified 2026-08-05 · next review 2027-08-05 · high confidence

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.
Back to Learn →
Get the iGamer Briefing

A short, cited email when something in iGaming changes — plus one fundamental worth understanding. Independent, 18+, no hype.

18+. No spam, no operator ads. See our privacy note. Unsubscribe anytime.