To verify a provably fair roll: record the hashed server seed the site shows before you bet, play, then rotate your seed so the site reveals the raw server seed. Hash the revealed seed and confirm it matches the commitment, then re-run the game's published formula with your client seed and nonce. If your recomputed number matches what the site showed during play, that bet was computed honestly.
What you need before you start
- The committed server seed hash, captured before you play — screenshot it, because this is your evidence if anything mismatches later.
- Your client seed at the time of the bet (if you edited it mid-session, note when).
- The nonce of the bet you want to check — most sites show it in the bet details.
- The revealed server seed, available only after you rotate.
- The site's documented formula — the byte-to-outcome mapping differs per game, and a verification that uses the wrong mapping proves nothing.
Step 1: Record the committed hash before you bet
Every legitimate implementation shows the SHA-256 hash of the active server seed somewhere — usually a fairness or provably-fair page, or a seed section in the bet menu. If you cannot find a committed hash anywhere, stop: without a commitment made before your bets, there is nothing to verify later, no matter what the marketing says.
Step 2: Play, then rotate your seed
Rotation retires the active seed pair and forces the site to reveal the raw server seed it was using. This is the only moment your past bets become checkable — an unrevealed seed is just a promise. Note your last nonce before you rotate, because that number tells you exactly how many bets the closed seed should account for. If rotation is buried, rate-limited, or missing entirely, treat that as a finding in itself; we cover the mechanics and the auditing habit in Why (and When) to Rotate Your Server Seed.
Step 3: Check the commitment
Hash the revealed seed with SHA-256 and compare it to the hash you recorded in step 1. Using our worked demo seed:
serverSeed (revealed after rotation):
d8e2c9a41b7f30e6558a2c4d9b1e6f03a7c85d21e4b90f6c3a1d5e8b2f7c4a90
SHA-256(serverSeed):
34a02fe0999787f4227f9438a297439f02aaccd7ead624d49552ef9955b5a99e
must equal the hash shown BEFORE you playedIf these do not match, the site did not play the seed it committed to. That is not a rounding issue — it is the one failure mode the whole scheme exists to catch. Screenshot everything and stop playing there.
Step 4: Recompute the roll
With the commitment confirmed, recompute the outcome. For a dice-style game using the common HMAC construction:
clientSeed = highlighted-demo
nonce = 7
HMAC-SHA256(serverSeed, 'highlighted-demo:7') =
ebe161ba2e6860ef2f32e6f5d2e517bf3694fd1859cc78e36ef437e950194494
first four bytes: eb e1 61 ba → 235, 225, 97, 186
float = 235/256 + 225/256² + 97/256³ + 186/256⁴ = 0.92140780
roll = floor(0.92140780 × 10001) / 100 = 92.14If the site showed 92.14 for that bet, it checks out. The byte-by-byte reasoning behind each line is in Server Seed, Client Seed, Nonce — Explained Byte by Byte.
Where do I find these values?
| Input | When it is visible | Typical location |
|---|---|---|
| Server seed hash | Before and during play | Fairness / provably-fair page, seed settings |
| Client seed | Always | Seed settings (usually editable) |
| Nonce | Per bet | Bet details / game history |
| Raw server seed | Only after rotation | Seed history or fairness page |
How do I verify a roll on CSGORoll?
CSGORoll documents a three-part seed: the hashed server seed, a public seed, and a nonce. For its PvP games the public seed is an EOS blockchain hash that only becomes known after every player has committed their bet, so neither the site nor any player can know the result in advance. The fairness page publishes JavaScript you can run yourself with the publicSeed, serverSeed and nonce of any game — the same loop as above, with CSGORoll's own outcome mapping. Multiplayer rounds add inputs like roll order, which we break down in How Case Battles, Crash and Jackpot Stay Fair.
What about crash sites like Gamdom or Crash GG?
Crash is a shared round (one multiplier for everyone), so verification works per round rather than per player. Gamdom exposes round data for its provably fair originals so you can check outcomes after the fact. At the other end of the spectrum, when we reviewed Crash GG we could not find any independently verified fairness documentation at all — and the only honest way to treat an unverifiable claim is as an unverified one.
What if the numbers don't match?
- Wrong seed pair — make sure the bet belongs to the seed you rotated, not an earlier pair.
- Nonce off by one — most implementations count from 0, and your first bet is nonce 0, not 1.
- Cursor games — games that need many random values (card games especially) append a cursor to the message; check the site's docs.
- Wrong mapping — a dice mapping will never reproduce a roulette pocket. Use the formula for that exact game.
- Genuine commitment failure — if SHA-256 of the revealed seed does not match the committed hash after you have ruled the above out, collect screenshots, raise it with support, and withdraw. There is no innocent explanation for a broken commitment.
Checking bets one at a time gets old fast — rotation actually unlocks your entire seed history at once. Our provably fair verifier is built for exactly that: paste a seed pair and a nonce range, and it recomputes the whole session in your browser, with nothing sent to any server. A verification that passes tells you the site computed your results honestly. It does not tell you the odds were good, the case was worth its price, or the withdrawal will clear. Skipping those checks because the math checked out is the mistake the marketing hopes you will make.