You open the game history, click an old round, and see a row of fields that look more technical than helpful: server seed hash, revealed server seed, client seed, nonce. That is the point where an audit starts.
A provably fair history check is not a general safety test. It is a way to verify that a specific game round was not altered after your bet, using cryptographic inputs recorded before and after play.
The mechanism is common on some crypto-based games. It can let you inspect past results yourself, round by round, instead of relying only on a displayed outcome.
What a provably fair history audit is actually checking
The core idea is a commitment before the round and a reveal after it. Before play, the game publishes a hash of a hidden server seed. After enough rounds, or when the seed pair changes, the original server seed can be revealed.
If the revealed server seed produces the same hash that was shown earlier, the operator committed to that seed in advance. That matters because a cryptographic hash is designed so that even a tiny change in the input creates a very different output.
Then comes the second check. The game combines the revealed server seed with your client seed and a nonce to generate the result for each round in that seed cycle.
If your recalculation matches the stored outcome, you have evidence that the round result followed the published method and was not changed after the bet. That is the narrow but useful proof.
It does not prove that every game on a site uses this system, that payout settings were generous, that balances are fully backed, or that withdrawals will be processed smoothly. It verifies individual round integrity, not every other part of the gambling experience.
The four pieces you need: server seed, hash, client seed, nonce
Most history audits revolve around four values. Missing one usually means you cannot reproduce the round independently.
| Element | What it does | What you check |
|---|---|---|
| Server seed | The secret input held by the game before reveal | After reveal, it should hash to the earlier commitment |
| Hash commitment | The published fingerprint of the hidden server seed | It should match the revealed seed exactly when hashed with the same algorithm |
| Client seed | An input tied to the player, often editable on many sites | The stored value should match what was used for that round |
| Nonce | A counter that changes from one round to the next under a seed pair | The round should use the correct nonce in sequence |
Two details trip people up. First, the nonce is not decoration; it prevents the same seed pair from producing the same result every time. Second, the client seed may be set automatically unless you changed it yourself, so the history value matters more than memory.
Step 1: Find the committed hash from before the round
Start with the older record, not the reveal screen. You need the server-seed hash that was visible while the seed was still hidden.
On many sites this appears in a fairness panel, seed menu or round details view. Sometimes the current seed hash sits in one place while the per-bet history sits somewhere else, which means you may need both screens to reconstruct the chain.
Copy the hash exactly. One missing character will break the audit.
A hash is usually shown as a long string of letters and numbers. The site should also state which hash function it used, commonly SHA-256, because the same seed hashed under a different algorithm will not match.
Step 2: Get the revealed server seed for that history period
Next, find the revealed server seed linked to the same seed cycle. A seed cycle is the period during which one hidden server seed stayed active while the nonce incremented from round to round.
Games commonly reveal the old server seed when you rotate seeds or request a new pair. Some interfaces keep an archive of previous seed pairs; others show only the current and immediately previous values.
Match the revealed seed to the right commitment. If the history includes several rotations, using the wrong reveal will make every later step fail even if the game was working exactly as described.
Step 3: Hash the revealed server seed yourself
Now test the commitment. Take the revealed server seed and run it through the stated hash function.
If the output equals the earlier published hash character for character, the game committed to that server seed before revealing it. That is the first cryptographic proof in the process.
Suppose a history page showed a hash before you played 18 rounds, and later the site revealed the original server seed after a seed change. If your own SHA-256 calculation matches the stored hash, the seed was not swapped after those rounds were completed.
If it does not match, stop there. Either the wrong seed pair was selected, the wrong algorithm was used, a copy error occurred, or the record is not internally consistent.
Step 4: Confirm the client seed used for the round
The next input is the client seed. On many implementations, this is player-controlled or at least player-visible.
Check the exact client seed attached to that round or to that seed cycle. Do not assume the current client seed is the same one that was active months ago.
This matters because outcome generation typically mixes server seed, client seed and nonce together. Change any one of them, and the resulting number changes too.
Step 5: Identify the correct nonce
The nonce is usually a simple counter: 0, 1, 2, 3 and so on, though some systems start from 1. The site should indicate which nonce belongs to which bet.
Find the exact nonce recorded for the round you want to audit. A common mistake is recalculating a result with the right seeds but the next nonce in the sequence.
Imagine one seed pair was used for 43 bets. Bet number 7 and bet number 8 may have the same server seed and client seed but different nonces, so they must produce different derived values.
Step 6: Recreate the outcome using the game’s published method
After you have the revealed server seed, the matching hash, the client seed and the nonce, recreate the game result using the stated formula. This part is game-specific.
Some games derive a large hexadecimal value and convert part of it into a decimal number. Others use a hash-based message authentication process and then map the result onto a dice roll, card draw or crash point according to published rules.
The important standard is consistency, not a single universal formula. You are checking whether the game used the method it said it used for that exact round.
If the site offers a built-in verifier, compare its result with your manual or third-party calculation. A matching result strengthens confidence that you entered the values correctly. If the site also publishes the formula, independent recalculation is the stronger test.
What a successful audit proves
A successful audit supports three narrower conclusions.
- The revealed server seed matches the earlier hash commitment.
- The round outcome can be reproduced from the stored server seed, client seed and nonce.
- The operator could not change that round’s result after committing to the hidden server seed without breaking the hash match.
That is meaningful. It lets you test whether recorded history is internally consistent and whether a specific result follows from the precommitted inputs.
What a successful audit does not prove
This is where readers often overreach. A clean provably fair check does not answer every fairness question.
| Claim | Does a history audit prove it? | Why not |
|---|---|---|
| A round was not altered after the bet | Yes, if the commitment and recalculation match | The hash commitment and seed reveal are designed for that check |
| The game offered favourable long-run returns | No | Provably fair history is separate from RTP and house edge for a defined game and rule set |
| The site is solvent | No | Seed verification says nothing about reserves or payment ability |
| Every game on the site uses the same method | No | One verified title or round does not automatically cover others |
| The operator’s wider conduct is reliable | No | Round integrity is only one part of the overall picture |
There is another limit. If a system lets the house choose from many hidden seeds before publishing a commitment, provably fair history still does not prove that the precommitment process itself was optimally neutral. It proves that once the commitment existed, the recorded result matched it.
Common reasons an audit fails
Most failed checks are mundane. Typos are common, especially with long hashes and seeds.
Another issue is mismatching time periods. A revealed server seed from one rotation will not validate rounds generated under an earlier commitment.
Nonce handling causes plenty of confusion too. A game may increment per bet, per game action or per completed round, depending on its design.
Finally, some players verify the commitment correctly but use the wrong outcome formula. A dice formula will not help you audit a card draw.
How to keep an audit trail for your own records
If you plan to verify history later, save the relevant details before changing seeds. Screenshots help, but raw text is better because hashes and seeds can be copied exactly.
Keep the date, game name, round ID if shown, server-seed hash, client seed, nonce and final result. With those pieces, you can usually revisit the round even if the interface changes.
That small habit matters most when old records disappear from the live history tab. An audit is much easier when you already captured the commitment before the reveal happened.
FAQ
Can I audit provably fair history without the revealed server seed?
No. You can see the commitment hash before play, but you cannot complete the cryptographic check until the matching server seed is revealed.
Why does the nonce matter in a provably fair audit?
Because it separates one round from the next under the same seed pair. Using the wrong nonce usually produces a different result even when both seeds are correct.
Does provably fair history mean the game is fair in every sense?
No. It helps verify that a specific round followed the committed inputs and published method, but it does not prove payout quality, solvency or broader operational conduct.
Play responsibly
Gambling should be treated as paid entertainment, never as a way to earn income or recover losses.
18+ or 21+ depending on where you are; follow the minimum age that applies to you.
Help line (US): 1-800-MY-RESET (1-800-697-3738)
This article is general information about how these mechanics work. It is not legal advice and not a recommendation to gamble or to use any particular operator. Availability and legality differ by jurisdiction — check the rules that apply where you are.