Provably Fair Verifier - Recompute Dice Rolls Locally

Which scheme does my casino use?

HMAC-SHA256 (Stake, Primedice, Shuffle-style): roll = first 4 bytes of HMAC(serverSeed, clientSeed:nonce:0) as a float, scaled to 10,001 steps of 0.01 (0.00-100.00). SHA256-concat: the classic crypto-dice scheme - SHA256 over the concatenated seeds + nonce, first 32 bits as a float, scaled to the outcome range (10,001 steps = the standard 0.00-100.00 dice roll; 1,000,000 = integer rolls). Both are scaling schemes - a site that documents a modulo over more bits is a different formula. If the numbers do not reproduce, you may simply have the wrong scheme, the wrong nonce range or a seed that was rotated mid-session.

The DuckDice scheme (first ZEC-operator adapter)

DuckDice publishes its complete algorithm and a runnable reference implementation on its fairness page: SHA-512 over the concatenated server seed + client seed + nonce, then 5-hex-character chunks read as integers - a chunk of 1,000,000 or more is skipped (up to 25 trials), otherwise the roll is the chunk modulo 10,000 (0-9999). We implemented exactly that and cross-checked our implementation against a verbatim transcription of the operator's published code across 20,000 random seed/nonce combinations - all agree. Fixed test vectors live in our test suite; the reproduction is documented in our research notes. What this still does not prove: that the operator actually runs this code in production (verify with a real bet via their in-site verifier), that other games use it, or that the operator pays.

Where are the other ZEC-native adapters?

Still consciously absent for everyone else. A fair verifier needs a published, versioned specification plus a reproducible reference - Cloudbet documents a SHA3-256/SHAKE256 scheme for its Originals, which is a different hash family (no browser SHA-3 support without a vendored implementation) and per-game outcome mappings; it will get an adapter when the mapping for a specific game is reproduced. Other ZEC-taking casinos document no scheme at all. A generic "trust me" fallback for casino-specific formulas would verify nothing - this tool covers only schemes with an authoritative spec.

What a match proves - and what it does not

It proves: the displayed outcomes follow mathematically from the inputs you pasted, and - with the commitment check - that the server seed was fixed before your session. It does not prove that the operator pays withdrawals, that every game uses the same formula, that chain-anchored inputs were honest (verify the hashes yourself), or that the site is solvent. Fairness of one game is one brick, not the house. Read the full walkthrough in the provably fair guide →