How does provably fair actually work?
It proves a specific narrow thing: that the operator could not have changed the outcome after seeing your bet, not that the game is fair in any broader sense. Three ingredients go into every round: a SERVER SEED the casino generates and keeps secret, a CLIENT SEED you supply or are given, and a NONCE that counts up by one on every bet. Before you can bet, the casino publishes the HASH of its server seed, its SHA-256 fingerprint, which commits the casino to that seed without revealing it: changing the seed afterward would produce a different hash and be instantly detectable. The outcome is then computed from all three ingredients together, typically as HMAC-SHA256(server seed, client seed plus nonce), sliced into a number and mapped onto the game's result. When you are done with that seed, the casino reveals the plain server seed, and you can recompute everything yourself to confirm nothing was altered. What it does NOT prove: that the mapping from hash to outcome matches the advertised return to player, that the client seed was not silently generated in a way the casino also controls, or that any of this happened at all rather than being a decorative widget with no bearing on the real game engine behind it.
A cryptographic commitment scheme, not an audit. It proves the casino could not cheat after your bet, and proves nothing about before.
The evidence
| Step | What happens | What it proves |
|---|---|---|
| Before betting | Casino generates a secret server seed and publishes its SHA-256 hash | The seed existed and was fixed before you bet, since changing it later changes the hash |
| During betting | Your client seed plus an incrementing nonce combine with the hidden server seed via HMAC-SHA256 | Every bet uses a distinct, unpredictable combination even on the same server seed |
| After the seed cycle | Casino reveals the plain server seed | You can recompute every round and confirm it matches what you were shown live |
| What is never proven | That the number-to-outcome mapping matches the advertised RTP, or that a real player even generated the client seed | This layer is honest about the commitment, not about the game math behind it |
How we know
A fully worked example, computed independently in Node and Python with identical results, both shown so this is checkable rather than asserted: with server seed "raw-demo-server-seed-2026", its published SHA-256 hash is 35b670136cfd442282edce49758c4dc8e16166f7238f2eecbd13f52da5315070. With client seed "raw-demo-client-seed" and nonce 1, HMAC-SHA256(server seed, "raw-demo-client-seed:1") is 3c339f3c0423c30192deaba5840cab450e758d4ad011e14af0f237059c5dda7d. Taking the first 8 hex characters, 3c339f3c, as an integer gives 1010016060, and 1010016060 mod 100, plus 1, gives 61: a result on a 1 to 100 scale. Anyone can run this themselves; nothing above is specific to any operator, it is the general shape every provably fair implementation follows. The gap almost nobody states plainly: this scheme is borrowed from crypto-casino culture precisely because it needs no regulator, and it is not a substitute for one. Nevada Regulation 14.360 requires an INDEPENDENT testing laboratory to certify that a game's software matches its declared mathematical model. Provably fair verifies the ARITHMETIC of one round after the fact; it says nothing about whether the declared odds it is faithfully executing were ever independently checked in the first place. A game can be perfectly provably fair and have terrible declared odds, and the hash scheme would never catch that. One more thing worth knowing if a page cites a lab certificate rather than provably fair math: iTech Labs, a commonly cited certifier, was acquired by GLI Group in May 2023, and a certification is normally tied to the specific software version tested, not to the operator or game brand indefinitely. An updated build is a different question than the one that was certified.