Provably Fair Explained - and What It Cannot Prove

By zcashcasinos editorial desk · updated 2026-09-15 · facts checked 2026-09-15

table of contents

1. How the schemes work
2. Running a verification
3. What a match proves - and what it does not
4. Where fairness actually fits in your decisions

How the schemes work

Every seed-based scheme is a commit-then-reveal construction built on standard hashes [1] [2]:

1. Commit. Before your session, the casino generates a server seed and publishes only its hash. It cannot change the seed later without breaking the hash.
2. Participate. You set a client seed - your contribution, so the operator cannot pre-compute results against you.
3. Count. Each bet increments a nonce; the same inputs with a different nonce give a different result.
4. Derive. The result comes from a hash over these inputs - commonly HMAC-SHA256(server seed, client-seed:nonce) for the Stake-style dice formula [2], or SHA-256(server + client + nonce) in the classic crypto-dice construction [1] - interpreted as a number in the game's outcome range.
5. Reveal. After the session (or on demand), the operator reveals the server seed. Now you can recompute every roll: same seeds, same nonces, same math, same results.

The verification is deterministic: if your recomputation matches what the site displayed, the displayed outcomes follow from the committed inputs. If the revealed seed does not hash to the pre-published commitment, the operator switched seeds mid-session - the one mismatch that is a finding, not a user error.

Running a verification

Our verifier tool recomputes the two common documented dice schemes locally in your browser - nothing you paste leaves the page (it is not even visit-counted):

1. Get the casino's revealed server seed, the published commitment hash (the one shown before), your client seed, and the nonce range of the session.
2. Pick the scheme that matches the operator's documentation - the formulas are different constructions, and guessing the wrong one just produces a clean mismatch.
3. Recompute a nonce range and paste the results the site showed you: matching lines prove the outcomes follow from the seeds.
4. Run the commitment check: the revealed seed must hash to the published value [1]. That is the "fixed in advance" leg.

A documented ZEC-native example for the history file: Zcash Video Casino published a full scheme (server-seed hash + client seed + SHA-256 derivation) with per-game house-edge claims back in 2019 [3] - proof that ZEC-native operators could and did document schemes. Today's operators are graded per-casino in our reviews: which games have a documented scheme, and whether seeds are actually published.

What a match proves - and what it does not

A successful verification proves exactly this: the displayed outcomes follow mathematically from the committed inputs. It does not prove any of the following, no matter what a banner implies:

• Solvent or paying. A perfect roll math says nothing about whether the withdrawal desk answers [4].
• Terms honesty. Bonus clauses, KYC surprises and confiscations live outside the game engine entirely.
• Coverage. One verified game says nothing about the other 3,000 in the lobby - schemes are per-game.
• Scheme integrity. Our generic adapters recompute documented formulas; a casino-specific formula needs its own documented spec and test vectors to verify at all.

That is also why our verifier deliberately ships no casino-specific adapters beyond the generic schemes: a "universal verifier" that pretends to check formulas it does not know would verify nothing [4]. Per-casino adapters only enter when an operator publishes a versioned spec plus real bet data we can reproduce.

Where fairness actually fits in your decisions

Use provably fair as one factor among several: a documented, verifiable scheme with honored commitments is genuine engineering honesty about the game layer [4]. Pair it with the facts that decide your money - payout processing times, KYC trigger lines, fee schedules and the operator's track record - all structured per casino in our comparison table, and the red-flag checks in our scam checklist.

And the math reminder that predates crypto by a century: the house edge is the price of the game, not a conspiracy [4]. Verification tells you the price is what the operator claims - budgeting is still your job.

FAQ

Does provably fair mean the casino cannot cheat me?

It means the game outcomes follow from inputs fixed before your session - a seed switch or post-hoc result edit would not recompute. It does not cover payouts, solvency, terms enforcement or games outside the scheme.

What are server seed, client seed and nonce?

The server seed is the casino's secret, committed in advance as a hash; the client seed is yours; the nonce counts bets. The result is a hash over these inputs - change any one, and the result changes.

Can I verify any ZEC casino game?

Only games with a documented scheme and revealed seeds. Our verifier covers the common documented formulas; a site that documents nothing has nothing you can verify.

Why does my verification not match?

Usually the wrong scheme, the wrong nonce range, or a seed rotated mid-session - request the session seeds first. A committed seed that fails to hash to the published value is the one mismatch that means cheating.

Do ZEC casinos use provably fair schemes?

Some do - the historic ZEC-native Zcash Video Casino documented a full scheme in 2019. Today's operators are covered per-casino in our reviews with the exact games where the scheme is documented.

Sources

1. FIPS 180-4: Secure Hash Standard (SHA-256) - the hash function the schemes rely on - accessed 2026-09-15
2. RFC 2104: HMAC - Keyed-Hashing for Message Authentication - accessed 2026-09-15
3. Wayback capture: Zcash Video Casino provably-fair page (2019) - a documented historic ZEC scheme - accessed 2026-09-15
4. Gambling mathematics (Wikipedia) - house edge and RTP basics - accessed 2026-09-15

Keep reading

Tools for this