The Provably Fair Algorithm: How It Works, the Math Behind It, and How to Verify its Claims

Click Play to listen to the podcast on “Provably Fair”.

What is “Provably Fair”?

The Provably Fair Algorithm: How It Works, the Math Behind It, and How to Verify a Casino’s Claims

“Provably fair” is a verifiable way to generate and commit to game results so players can independently confirm no one tampered with them after the bet. In practice, the casino first commits to a secret (server seed) by publishing a cryptographic hash; later it opens the commitment by revealing the seed so players can recompute outcomes. In cryptography, that’s a commitment scheme: binding (can’t change later) and hiding (doesn’t reveal early).

Crypto casinos popularized this approach: a server seed (casino), a client seed (player/browser), and a monotonically increasing nonce (bet counter) feed a hash/HMAC function; you can then recompute the exact random bytes that drove your spin/roll and confirm they match the on-screen result.

Provably Fair vs. Traditional RNG

Traditional online casinos rely on proprietary RNGs validated by third-party labs; you don’t see the draw itself. Provably fair adds a receipt for each round—inputs, function, and mapping—so you can reproduce the same random output from the same seeds and nonce. Some operators even expose per-round “how we calculated this result” pages.

Core Components of a Provably Fair Algorithm

Commitment: Publish hash(server_seed) before play. Any later change would break the previously posted hash—this is exactly what cryptographic hash commitments are for.
Combination: After each bet, combine server_seed, client_seed, and nonce into a keyed digest (commonly HMAC-SHA256/SHA-512). HMAC is a standard, keyed hash used for integrity and authenticity.
Reveal & verify: At rotation (or session end), the casino reveals the server seed. You compute the same HMACs locally and confirm results. Implementations from major operators document the exact inputs and function (e.g., HMAC-SHA256 with seed pair + nonce).

The Math Behind Provably Fair

1) Generate verifiable randomness

A common pattern (operator-documented):

bytes = HMAC_SHA256(key = server_seed, 
                    msg = client_seed || ":" || nonce)

This produces 32 random-looking bytes. Because HMAC is keyed, the digest is unpredictable to players during the session but fully recomputable after reveal. (NIST’s FIPS 198-1 defines HMAC; RFC 4868 details HMAC-SHA256 use.)

Some systems use hash chains (pre-generated sequences of SHA-256 values that can be verified from a terminating hash), again so future outcomes can’t be retro-picked. Bustabit’s public seeding events are a well-known example.

2) Map bytes → game outcomes without introducing bias

A naïve mod N on a 256-bit value can create modulo bias if 2^k isn’t a multiple of N. Correct implementations use rejection sampling (discard out-of-range draws) or an optimal mapping so each outcome has identical probability. This is standard in RNG literature.

Example (dice 0–99.99):

Interpret the first 8 bytes as a 64-bit unsigned integer u.
If u > maxAccept (the largest 64-bit value that still maps evenly into 10,000 buckets), discard and use the next 8 bytes.
Else compute floor(u / scale) to get a uniform integer in [0, 9999], then divide by 100 for 0–99.99. (Public docs and community write-ups describe similar mappings.)

Example (roulette 0–36): apply the same rejection-sampling idea so 37 pockets remain exactly equiprobable. Several educational explainers call out modulo bias and the need for careful mapping.

3) Verify a Round Yourself

Operators that do this right provide: server-seed hash (pre-commit), your client seed, the nonce used, and the function spec (e.g., HMAC-SHA256). You can then recompute the digest and apply the stated mapping. Stake’s public implementation notes the seeds + nonce → HMAC-SHA256 step; independent explainers show the same three-input pattern

How Online Casinos Rotate and Reveal Seeds

Good practice: rotate the server seed after a fixed number of bets or time window, reveal the old seed, and post a new pre-commit hash. That preserves privacy during play and auditability afterward. Hash-chain approaches (precommitting to millions of hashes with a published terminator) are another verifiable pattern.

A Worked Mini-example (Conceptual)

Pre-game commitment: site posts H = SHA256(server_seed).
You set client_seed = "alice-2025".
First bet uses nonce = 0.
Site computes R = HMAC_SHA256(server_seed, "alice-2025:0").
Site maps R (via rejection sampling) to a dice result 0–99.99 and shows “47.23”.
After rotation, the site reveals server_seed.
You recompute H' = SHA256(server_seed) and check H' == H, then recompute R and confirm it maps to 47.23 exactly. (This flow matches public “how it works” pages and community documentation.)

Where Provably Fair Algorithm Claims Go Wrong

No pre-commit hash (you can’t prove they didn’t change the seed later).
Vague “SHA-256 used” but no exact function (HMAC vs raw hash, inputs, byte order).
Results derived with naive mod N (introduces bias).
No seed rotation/reveal log.
Authoritative crypto and security sources explain why missing commitments or sloppy mappings undermine fairness.

Beyond Fairness: Security & Transparency

Remember: “provably fair” guarantees outcome integrity, not business integrity. Still look for licensing, payout SLAs, 2FA, cold-storage/treasury controls, and clear T&Cs. (Industry guides explain provably fair as a transparency layer alongside normal controls.)

Powerblocks Blog