Seed Pair Verification After a Session: A Complete Checklist

After a session ends, the only evidence you can take away is a set of seed pairs, nonces, and hashes. If you did not record these values before or during the session, the session cannot be verified after the fact. This checklist gives you a repeatable procedure for checking every round that was generated with a given seed pair, and it flags the exact points where false positives commonly appear.

Why Seed Pairs Are the Core of Provably Fair Games

In a typical provably fair implementation, the server selects a secret server seed, publishes a hash of it (usually SHA-256) before a round, and reveals the server seed only after the round is finished. The client seed is chosen by the player, and a nonce—a per-round counter—makes each outcome unique. The final game result is derived from a deterministic function of these three values. When you verify a seed pair, you are checking that the revealed server seed matches the pre-published hash, and that the recorded outcomes were correctly computed from that seed pair and the nonce sequence. For a broader explanation, see our guide on provably fair verification.

Data You Need for Verification

Gather these values before you open the verifier. If any of them is missing, the result of the verification is incomplete.

Step-by-Step Verification Checklist

Use this order every time. Skipping steps creates false isolation: you may verify one round while ignoring the sessions that used a different seed pair.

1. Normalize the input strings. Copy the server seed, client seed, and nonce into a plain editor. Remove trailing spaces. Confirm the exact concatenation convention used by the platform. Many sites use serverSeed:clientSeed:nonce with a colon, but some use an empty separator or an extra salt. Check the operator’s fair-play documentation; this is an operator-specific detail, so never assume a standard.
2. Verify the server seed against its pre-round hash. Compute SHA-256 of the revealed server seed string and compare it with the hash that was shown before the session. If they differ, stop. There is no valid continuation without a matching hash. This step alone reveals whether the server seed was genuinely fixed in advance.
3. Generate outcomes for every nonce in the range. Use a script or an independent verifier that implements the same deterministic function as the site. For a dice game, the usual algorithm is to take the first eight hex characters of SHA-256 of the concatenation, convert that value from hex to decimal, then apply a modulo to get an integer in the game’s range. The exact formula is game-specific; read the operator’s algorithm with fresh eyes.
4. Compare computed outcomes with your bet history. For each nonce, check that the computed roll, card, or spin matches the outcome shown in the game log. Also check that the payout multiplier equals the product implied by the game’s published house edge and the outcome. A mismatch can mean you used the wrong formula, the wrong separator, or the wrong nonce order.
5. Watch for nonce resets at seed rotation. If a new client seed was activated during your session, the nonce counter restarts from zero or one. If you try to verify the whole session as one continuous seed pair, you will get a false failure. Split the session into segments, one per seed pair, and verify each segment separately.
6. Aggregate the session’s RTP. Sum the total amount returned to you across all bets in the seed-pair segment, then divide by the total amount staked. Compare the result to the game’s theoretical RTP. For a house edge of 1%, the expected RTP is 99%; a single session’s RTP can deviate by several percentage points, so this check is informative only when you have thousands of rounds.
7. Document the verification. Write down the server seed, client seed, hash, nonce range, and the script or tool you used. Keep a copy of the computed outcomes. If you want an immutable timestamp, calculate a hash of that record and store it on a blockchain or in a timestamping service. This documentation is what you would present to a support team or auditor.

If the Verification Fails

First, separate the two failure modes. A hash mismatch means the operator cannot prove the server seed was fixed in advance. That is a fundamental integrity failure. An outcome mismatch on one or more nonces, with a correct hash, usually points to a difference between your computation and the site’s documented algorithm. Check the separator, the encoding, the nonce base (0 or 1), and the modular formula. Check whether the site uses the first 8 hex characters or the whole hash for modulo. Check whether it uses a float or integer range. Only after you have reproduced the exact algorithm should you conclude that the server behavior is inconsistent.

When you encounter a true mismatch, raise it with the operator. Use the evidence you collected in step 7. Some operators offer a bug bounty for reproducible verification failures; check their terms. For a list of casinos that expose their seeds before each round, consult our casino reviews.

Common Verification Mistakes

• Hashing the combined seed instead of the revealed server seed.
• Confusing the pre-round server seed hash with a hash of the client seed.
• Using uppercase hex in one place and lowercase in another.
• Forgetting that a new client seed resets the nonce counter.
• Applying one game’s formula to a different game type (e.g., dice formula on keno).
• Using a third-party verifier that silently ignores the house edge in its payout display.
• Verifying only one round and assuming the whole session was fair.

If you want to reduce the number of bets you need to verify, consider a more predictable staking structure. A fixed bet per nonce makes the RTP-aggregation step easier to read. Practical staking methods are covered in our bankroll management guide.

FAQ

What if I forgot to record the pre-round server seed hash before the session?

You lose the most important proof. The pre-round hash is the anchor that ties the server seed to the moment before the round. Without it, the operator could have rotated the server seed after seeing your client seed, so there is no way to prove the outcome was not engineered. In future sessions, copy the hash as soon as the game loads, before placing any bet.

Can I verify seeds from a site that doesn’t publish a server seed hash?

No. If the site does not show a hash before the round, it is not provably fair under the standard definition. You can still check whether the same client seed produces the same outcome when repeated exactly, but this only detects a deterministic RNG, not unfairness. Use the verification method described here only for sites that provide pre-round hashes. If a site in our reviews claims provably fair, it should expose the algorithm and the hash before a round.

How many rounds do I need to check for a meaningful audit?

For algorithmic integrity, one correctly verified round is enough to prove the seed pair was used and the formula was deterministic. For RTP, you need a much larger sample: with a 1% house edge, a 10,000-round session has a standard deviation around 1 percentage point per event. So a single session’s RTP close to 99% is consistent, but it is not a guarantee. The seed verification gives you certainty about the algorithm; the RTP aggregation only gives you a probabilistic check against a known edge. For current provably fair news and any changes, see our news section.