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-25

Direct 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 digest
  • 3. After round: reveal serverSeed
  • 4. 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.