Provably Fair Explained - and What It Cannot Prove

By zcashcasinos editorial desk · updated 2026-10-23 · facts checked 2026-10-23

table of contents

1. How the schemes work
2. A worked example: a real ZEC operator's algorithm
3. Running a verification
4. What a match proves - and what it does not
5. 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 [2] [3]:

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 [3], or SHA-256(server + client + nonce) in the classic crypto-dice construction [2] - 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.

A worked example: a real ZEC operator's algorithm

This is where most provably-fair articles stop. We will not - here is a live, ZEC-taking operator's published scheme, and numbers you can reproduce yourself.

DuckDice publishes its complete roll algorithm on its fairness page [1]:

• Commitment: the server seed is hidden with a SHA-256 hash while your session runs; each seed is revealed after its last use.
• Roll: hash = SHA512(serverSeed + clientSeed + nonce) - a 128-character hex string. Read 5 hex characters at a time as an integer. If a chunk is 1,000,000 or more, skip it and read the next 5 characters (up to 25 trials). The roll is the first valid chunk modulo 10,000 - a number from 0 to 9,999 [1].

Now the reproducible part. Our verifier implements exactly this scheme, and our test suite pins it against a verbatim transcription of the operator's published reference across 20,000 random seed/nonce combinations. Three fixed vectors from that test suite:

Pick any row, open the verifier tool, choose the DuckDice scheme, paste the inputs, and the same number comes out - computed in your browser, no server involved. The third row's inputs are deliberately long: that vector exercises the skip path, where the first chunk reads 1,000,000 or more and the algorithm has to move to the next 5 characters.

Why this matters more than the history-file example below: the historic scheme proves ZEC-native operators documented fairness; the live one proves a scheme you can check today, with published code, against inputs you choose.

Running a verification

Our verifier tool recomputes the common documented 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 [2]. That is the "fixed in advance" leg.

Two ZEC-specific data points on scheme coverage: DuckDice is the first ZEC-taking operator whose published scheme we have fully implemented and vector-tested [1]; Cloudbet publishes a provable-fairness page for its Originals, but its documented scheme uses the SHA-3 family, which needs a vendored implementation before an adapter can verify it - it stays absent until the per-game mapping is reproduced, and other ZEC-taking operators in our database document no scheme at all.

A documented historic reference for the 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 [4].

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 [5].
• 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 documented schemes: a "universal verifier" that pretends to check formulas it does not know would verify nothing. Per-casino adapters only enter when an operator publishes a versioned spec plus real bet data we can reproduce - which is exactly how the DuckDice adapter entered [1].

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. 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 [5]. Verification tells you the price is what the operator claims - what the price does to a session is the house edge guide's job. Budgeting is still yours.

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 two generic dice constructions plus DuckDice's published SHA-512 scheme; 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?

Yes - DuckDice, an active ZEC-taking dice site, publishes its complete algorithm on its fairness page [1], and our verifier implements it with test vectors reproduced across 20,000 random seed/nonce combinations. The historic ZEC-native Zcash Video Casino documented a full scheme back in 2019 [4]. Others document nothing - covered per-casino in our reviews.

What does a provably fair scheme prove about my payouts?

Nothing. The scheme lives in the game engine; the payout desk, the KYC trigger and the terms do not. Verification tells you the dice are honest - not that the cashier is.

Sources

1. DuckDice fairness page - the operator's own published algorithm (SHA-512 roll derivation) and seed-commitment model - accessed 2026-10-23
2. FIPS 180-4: Secure Hash Standard (SHA-256, SHA-512) - the hash functions the schemes rely on - accessed 2026-10-23
3. RFC 2104: HMAC - Keyed-Hashing for Message Authentication - accessed 2026-10-23
4. Wayback capture: Zcash Video Casino provably-fair page (2019) - a documented historic ZEC-native scheme - accessed 2026-10-23
5. Gambling mathematics (Wikipedia) - house edge and RTP basics - accessed 2026-10-23

Further reading

• DuckDice fairness page - a live ZEC-taking operator publishing its full roll algorithm - rare and worth reading in the original
• FIPS 180-4 (NIST Secure Hash Standard) - what SHA-256 and SHA-512 actually do, from the source
• RFC 2104 (HMAC) - the keyed-hash construction behind the Stake-style dice formula
• Wikipedia - Gambling mathematics - the house-edge math that no seed scheme changes

Keep reading

Tools for this