GAME MATH LIBRARY
What Is Provably Fair? Commit/Reveal, HMAC, and Server RNG Explained
The useful question is not whether a product uses the label 'provably fair', but whether a player can recompute the same deterministic outcome after the secret is revealed.
Wavelet Intelligence · 2026-09-25Direct answer
The useful question is not whether a product uses the label 'provably fair', but whether a player can recompute the same deterministic outcome after the secret is revealed.
Quick facts
- Core idea
- Commit first, reveal later
- Common tool
- HMAC / hash
- Verifiable input
- seed + nonce → outcome
- Does not prove
- Every other fairness claim
01
What commit/reveal is designed to solve
A server can publish a hash of a secret server seed before a round. That hash acts as a commitment to a value that has not yet been revealed.
After the round, revealing the original seed lets the player verify that it matches the earlier hash, limiting the server's ability to swap the secret after seeing player actions.
02
How HMAC turns seeds into outcomes
A common design combines a server seed, client seed, nonce or round identifier into deterministic input and processes it with an algorithm such as HMAC-SHA256.
The digest is then mapped by a published rule into a dice roll, Plinko path or card sequence. If inputs and mapping are disclosed, the same result can be replayed.
03
Server CSPRNG is not automatically provably fair
A cryptographically secure server RNG can produce high-quality randomness, but players cannot necessarily verify an individual round if no replayable seed and commitment are exposed.
'Uses secure RNG' and 'player-verifiable provably fair' are therefore different claims.
04
Provably fair is not the whole fairness system
Commit/reveal mainly verifies outcome generation. It does not by itself prove that a paytable is appropriate, an RTP claim is correct, the wallet settled correctly, or the operator meets regulatory obligations.
A fuller fairness model separates game math, outcome authority, presentation and accounting evidence.
EXAMPLE
Conceptual verification flow
1. Before round: publish hash(serverSeed)2. Round: HMAC(serverSeed, clientSeed + nonce) creates a deterministic digest3. After round: reveal serverSeed4. Player recomputes the hash and HMAC to verify both commitment and outcome
Frequently asked questions
Can the public hash reveal the server seed?
A properly selected cryptographic hash is designed for preimage resistance, so publishing the hash should not make recovering the original seed practical.
Does provably fair prevent misleading animation?
Only if the final presentation is reconciled with the server-authoritative outcome. Verifiable RNG does not replace presentation and settlement checks.
Can a slot using server CSPRNG always be called provably fair?
Not necessarily. Without a player-replayable commitment/reveal protocol, 'server CSPRNG' is a more precise claim than player-verifiable provably fair.