verify
Provably fair verifier
Check a server seed against its SHA-256 commitment, then recompute the dice roll with HMAC-SHA512. Everything runs in your browser — nothing is sent anywhere.
clientSeed:nonce, converting the first accepted 4-byte chunk into a 0.00–99.99 roll. Individual operators differ in hash function, message format and outcome mapping, so always check the algorithm your casino publishes. The point here is education: once you have recomputed one roll by hand, no fairness page is a black box again.How to use it
- Before betting, save the hashed server seed the casino shows you — that hash is the commitment everything else rests on.
- Play, keeping note of your client seed and how many bets you place.
- Rotate your seed pair in the site's fairness settings. Rotation forces the old server seed to be revealed.
- Paste the values above. The revealed server seed, the saved hash, your client seed and the nonce of the bet you want to check.
- Read the output. A green commitment check plus a roll that matches your bet history means that bet was decided before you placed it.
What each field means
server_seed is the casino's secret random value, fixed before your first bet and revealed only after rotation. It is the input the casino must commit to, because it is the only input the casino controls.
server_seed_hash is the SHA-256 digest of that seed, published before you bet. Hash functions are one-way: publishing the hash proves the seed existed without revealing it, and pins it so it cannot later be swapped. The full mechanics are in our provably fair primer.
client_seed is your contribution to the randomness. Because it enters the HMAC alongside the server seed, the casino cannot have precomputed a losing sequence for a seed you had not chosen yet. Set your own — here is why it matters.
nonce is a counter, incremented once per bet, so one seed pair can serve thousands of bets with a distinct outcome each. Seed, seed, nonce — the three inputs together fix the result deterministically.
What the verifier computes
Step one is the commitment check: sha256(server_seed), compared character-for-character against the hash you saved. Step two derives the roll the way most originals sites do it:
- Compute
HMAC-SHA512(key = server_seed, message = clientSeed + ":" + nonce), a 64-byte digest. - Take the digest 4 bytes at a time as a big-endian integer.
- If the value is below 4,294,960,000 accept it; otherwise reject it and move to the next 4 bytes (this rejection sampling keeps the roll exactly uniform).
- The roll is
(value mod 10,000) ÷ 100— a number from 0.00 to 99.99.
The tool prints the full HMAC digest and highlights the exact bytes used, so you can reproduce every step in Python or Node — the verification guide has the code. How that 0.00–99.99 number becomes a dice payout is covered in dice under the hood.
What a green check does — and does not — prove
A matching commitment and a matching roll prove the outcome of that bet was fixed before you placed it and was not altered afterwards. They do not prove the game's odds are good, that the payout table is fair, or that the operator will pay a withdrawal — provably fair has real limits, and it is worth knowing exactly where they sit.
Frequently asked questions
Is my server seed sent anywhere when I use this verifier?
No. Everything runs locally in your browser using the Web Crypto API (crypto.subtle). No field is transmitted, logged or stored — you can load the page, disconnect from the internet, and it still works.
Why does my roll not match what the casino shows?
Most likely the site uses a different construction. This tool implements the most common one — HMAC-SHA512 keyed by the server seed over "clientSeed:nonce", first accepted 4-byte chunk mod 10,000 divided by 100 — but operators vary the hash function, the message format, the byte-extraction method and the outcome mapping. Check the casino's published fairness algorithm; the commitment check (SHA-256 of the server seed) is far more universal than the roll derivation.
What does a commitment mismatch mean?
It means the revealed server seed is not the seed that was committed to before you bet. Assuming you copied both values correctly and the site hashes the seed the standard way (SHA-256 of the seed string), there is no benign explanation. Save screenshots of the commitment, the reveal and your bet history.
Why are some 4-byte chunks rejected?
To keep the roll unbiased. A 4-byte number ranges over 4,294,967,296 values, which is not an exact multiple of 10,000. Taking mod 10,000 directly would make low rolls very slightly more likely. Rejecting chunks at or above 4,294,960,000 (the largest multiple of 10,000 that fits) and moving to the next chunk removes that bias. A rejection happens in roughly 1 in 589,000 chunks.
Can I verify a bet before the server seed is revealed?
No — that is the whole point of the scheme. Until the casino reveals the server seed, you only hold its hash. You can verify the commitment exists, but you can only recompute results after rotation reveals the seed. Verify the moment you rotate, not months later.