How to Verify a Provably Fair Result, Step by Step

What exactly does 'provably fair' mean in practice?

It means the game's outcome is generated from data you can independently recompute: a server seed the house commits to (hashed) before betting, and a client seed you supply or can see. Because the hash is published up front and the raw seed is revealed after, you can mathematically confirm the result wasn't altered once your wager was known.

This is different from simply trusting a regulator's audit certificate, which checks the game's design at one point in time but doesn't let you confirm any single spin you personally played. Provably fair verification is per-round and requires no outside authority — only a hash function and arithmetic you can run yourself.

Math replaces the promise.

What do I need to record before I even place the bet?

Before the round starts, note the hashed server seed the platform displays (a long hexadecimal string), your current client seed, and the nonce — the counter tracking which round this is for that seed pair. Screenshot or copy all three; without the pre-round hash, you have nothing to check the post-round reveal against.

• Hashed server seed — the commitment, shown before play
• Client seed — yours, either chosen or auto-assigned
• Nonce — increments each round using the same seed pair
• Game rules page — the exact formula for turning the hash into an outcome

How do I recompute the hash myself, step by step?

After the round, the platform reveals the plain-text server seed it was committed to. Run that revealed seed through the same hash function it advertises (usually SHA-256) using any free online calculator or a one-line script. The output should be an exact character-for-character match to the hash you recorded before the round — any difference means the seed was swapped.

Most platforms publish their hashing method on a fairness or provably-fair help page. If a site won't tell you which hash function it uses, or won't reveal the pre-round hash before betting closes, verification is impossible by design — treat that as a warning sign rather than an oversight.

Can you walk through a worked example with numbers?

Say the pre-round hash shown was `9f2a...c81e` (SHA-256 of the hidden server seed). After the round, the platform reveals server seed `a17x9k...`. You hash that revealed string yourself and get `9f2a...c81e` again — a match, so the seed is genuine. You then combine that seed with your client seed and nonce 42 through HMAC-SHA256, take the result modulo 37, and get 14 — the exact pocket the wheel showed.

These values are illustrative, not a real cryptographic output — the point is the shape of the process: hash-check first, then outcome-recompute second. Every provably fair game (roulette, dice, card draws) follows this same two-step pattern; only the final mapping from hash output to game result changes.

• Step 1 — hash the revealed server seed, compare to the pre-round commitment
• Step 2 — combine server seed + client seed + nonce via HMAC-SHA256
• Step 3 — map the resulting number to the game's outcome range (e.g. mod 37 for roulette)
• Step 4 — compare your number to what the platform actually displayed

Same two steps, every single time.

What tools do I actually need to do this?

A browser is enough. Free SHA-256 and HMAC-SHA256 calculators exist online and require no download or account — paste the seed, get the hash. Players comfortable with code often use a five-line Python or JavaScript snippet instead, which is faster for checking many rounds but not required for a single spot-check.

Some platforms also publish open-source verification pages or npm packages built specifically for their format, which automate the whole sequence — you paste in the three values and it tells you match or no-match. These are convenient but optional; the underlying math is simple enough to check by hand.

What should I do if the hash or outcome doesn't match?

A mismatch at either step is a real red flag, not a rounding error — hash functions are deterministic, so identical input always produces identical output. Re-check for copy-paste errors (extra spaces, wrong seed) first, since that's the most common cause. If the values still don't reconcile, treat the result as unverified and raise it with the platform's fairness or support channel directly.

A mismatch is a fact, not a glitch.

How does rotating my client seed change what I'm verifying?

Changing your client seed starts a fresh seed pair and resets the nonce, closing out the old server seed for verification. Best practice is to rotate periodically and verify the outgoing server seed each time it's revealed — this catches any pattern of a house reusing or mismanaging seeds across many rounds rather than just spot-checking once.

Reputable platforms let you rotate your client seed on demand rather than only at fixed intervals, and reveal the previous server seed immediately on rotation. If rotation is hidden behind friction or delay, that's worth noticing.