Provably Fair Casino Games: How the Math Proves Itself
A player who loses a hand and cannot check the result has only one option: trust you. A player who can recompute that same result on their own machine does not need to. That single difference is what "provably fair" buys you — it converts every disputed spin from an argument into a calculation.
Provably fair is not a certification, a badge, or a marketing line. It is a cryptographic method that lets a player verify, after the round, that the outcome was fixed before they bet and was not altered to make them lose. At CasinoWebScripts we build it into the games themselves — and we now support two different provably-fair models, so an operator can offer the exact style of fairness their audience already expects. This is a transparency layer that sits on top of our GLI-19 certified RNG; it changes nothing about the math or the return-to-player, and everything about how much a player has to take on faith.
How provably fair actually works
Every provably-fair round is a sealed handshake built from three ingredients:
- The server seed — a long secret value the game generates and keeps hidden during the round. This is where the randomness comes from.
- The client seed — a value the player controls and can change at any time. Because the player contributes input the house cannot predict, the house cannot pre-arrange a losing result.
- The nonce — a simple counter that increments each round, so the same pair of seeds produces a fresh, verifiable outcome every bet.
The sequence is always the same, and the order is the whole point:
- Commit. Before the player bets, the game publishes a cryptographic hash (a SHA-256 fingerprint) of the hidden server seed. The hash gives nothing away — you cannot run it backwards to find the seed — but it locks the seed in. It is a sealed envelope held in escrow.
- Play. The player sets their own client seed and plays the round. The outcome is derived from the committed server seed plus that client seed.
- Reveal. When the round ends, the game reveals the raw server seed.
- Verify. The player hashes the revealed seed themselves. If it matches the fingerprint published in step one, the seed was never swapped — and they can re-run the outcome formula to confirm the result they got was the result the math produced.
No certificate can do this. A lab audit tells a player the random number generator is sound in general; it can say nothing about one specific hand they think was rigged. Provably fair answers that exact question, per round, without anyone having to take the operator's word for it.
The two models we support
"Provably fair" is a principle, not a single algorithm. Different platforms implement it differently, and players who came from one ecosystem expect the verification flow they already know. Rather than force one method on everyone, our games can run either of two established models — chosen by the operator.
Model 1 — HMAC (the crypto-casino standard)
This is the method the largest crypto and "originals" casinos popularised. The game commits a hash of the server seed, then derives each outcome as HMAC-SHA256(server_seed, client_seed:nonce) — a keyed hash that turns the seeds into a stream of numbers, which the game maps to a dice roll, a card shuffle, a crash multiplier, and so on. Its advantage is familiarity: crypto players already know how to verify HMAC results, and they can do it with any standard cryptographic library or an independent third-party tool — they do not even have to trust the operator's own verifier. If your audience comes from crypto casinos, this is the model they expect to see.
Model 2 — commit-reveal (the player-friendly model)
The second model commits a hashed server value before the bet and then applies the player's client seed as a shift or a deck cut, revealing everything after the round. The result is the same guarantee — the outcome was sealed before play — but the verification a player has to follow is simpler: one committed hash, one revealed value, one comparison. For audiences that are not crypto-native, it is the easier story to tell and the easier proof to check.
Both models share the property that matters most: they are outcome-neutral. They do not touch the game's return-to-player or volatility. They sit on top of the certified RNG as a verification wrapper, so switching fairness models never changes the underlying math — which means it is not a re-certification of the game's economics, just a different way of proving the same honest result. You can confirm the math separately in our published RTP and game-math list.
Which games are provably fair
Across our catalogue of 252+ HTML5 games, provably fair applies to every game type except scratch cards:
- Slots — the spin outcome is committed and revealable.
- Table and card games — blackjack, baccarat, poker variants, war and dragon-tiger style games: the dealt deck is verifiable against the committed seed.
- Video poker, roulette, keno and bingo — the draw or wheel result reproduces from the seed.
- Dice and crypto-native originals — mines, plinko, limbo, dice, stairs and tile-adventure games, the exact set crypto players verify most often.
Scratch cards are the deliberate exception. They draw from a pre-generated, certified prize pool rather than computing an outcome at the moment of play, and exposing the data needed to verify a ticket would also expose which other tickets are winners. So scratch games stay on the certified prize-pool model by design — the right call for that format, not a gap. It is worth being precise about this with buyers, because "all our games are provably fair" is the kind of overclaim a serious operator will test.
Why operators should care, not just players
In crypto and sweepstakes markets, the single most common objection a new player raises is some version of "how do I know this isn't rigged?" Trust is the conversion bottleneck, and a certificate hanging in the footer does not resolve it because players cannot interrogate it. A provably-fair result they can recompute themselves does. It moves the burden of proof off your support team and onto math that is true whether or not anyone trusts you.
There is also a defensive benefit. When a player disputes a result, "here is the committed hash, here is the revealed seed, here is the formula — run it" ends the conversation in your favour when you are honest, every time. It is cheaper than a support argument and more credible than a policy page.
Provably fair vs certified RNG — you want both
These are often confused, so it is worth separating them cleanly. A certified RNG is a one-time, independent lab audit (GLI-19 in our case) proving the random number generator is statistically sound and unpredictable. Provably fair is a per-round, self-serve proof that one specific outcome was committed in advance and not tampered with. The certificate establishes the engine is trustworthy in general; provably fair lets a player confirm a single result with their own hands. Strong operators offer both — and they are careful to say "GLI-19 certified RNG," because it is the RNG that is certified, not each individual game.
What to verify before you offer provably-fair games
If you are evaluating any provider's "provably fair" claim — ours included — these are the four checks that separate real implementations from theatre:
- Is the commitment published before the bet? A hash revealed only after play proves nothing. The seal has to come first.
- Can the player control the client seed? If the house controls every input, it can grind for a favourable server seed. Player-supplied input is what closes that door.
- Do seeds rotate each round? A fresh server seed per round (or a clean reveal-and-rotate cycle) is what keeps each outcome independently verifiable.
- Is there a public verifier? Players should be able to reproduce the result with an independent tool, not only a calculator the operator wrote and controls.
Our games meet all four, on both models, for every game type except scratch cards.
The bottom line
Provably fair does not make a game more honest — a certified RNG already does that. What it does is make honesty checkable, which is a different and, in trust-sensitive markets, more valuable thing. Offering it in the model your players already recognise removes the largest single objection standing between a visitor and a deposit.
If you are deciding which games and which fairness model fit your market, our configuration wizard will point you to the right package in a couple of minutes, or you can browse the full HTML5 catalogue and see the game types for yourself. Prefer to talk it through? Get in touch and we will walk you through how verification works on our platform.
if (basename($_SERVER['SCRIPT_FILENAME']) === basename(__FILE__)) exit;