Provably fair verification is a post-round audit process. It checks whether a completed casino result is consistent with cryptographic inputs committed before or during the betting cycle. The usual inputs are a server seed hash, a later revealed server seed, a client seed and a nonce or round counter.
The process has two separate layers:
- Commitment check: confirm that the revealed server seed matches the hash shown before play.
- Result check: use the same seeds, nonce and game algorithm to reproduce the displayed result.
What You Need Before Verifying a Round
Collect the exact values for one completed bet. A single wrong field is enough to generate a different result.
| Field | Purpose | Typical Location |
|---|---|---|
| Server seed hash | The commitment displayed before the raw server seed is revealed. | Fairness settings, seed page or pre-bet verification panel. |
| Revealed server seed | The hidden server input disclosed after rotation or completion of the seed cycle. | Seed history, fairness page or completed bet details. |
| Client seed | A player-side or account-side input combined with the server seed. | Fairness settings, API payload or bet details. |
| Nonce | The counter identifying the exact round under the same seed pair. | Bet history, verifier panel or API response. |
| Game type | Determines how the cryptographic output is converted into a roll, multiplier, board or card order. | Bet receipt or game history. |
| Game settings | Parameters such as mine count, Plinko rows, risk level or table rules. | Round details or the live game interface. |
| Displayed result | The value you will compare with the independently reproduced output. | Bet history, transaction receipt or completed round screen. |
The Commit–Reveal Model
Most seed-based systems follow the same broad sequence, although message formats and result conversions differ between operators.
1. Server commitment
The casino creates a hidden server seed and publishes a cryptographic hash of it. The hash acts as a commitment: changing the server seed later would produce a different hash.
2. Round inputs
The game combines the committed server seed with the client seed, nonce and sometimes additional values such as a cursor, salt or game setting. The precise construction must come from the operator’s documentation or verified source code.
3. Result conversion
The cryptographic output is converted into a game result. Dice may map bytes to a roll, Crash may use a 52-bit formula, and Mines may use a deterministic shuffle. These conversion rules are not universal.
4. Seed reveal
After the seed is rotated or the betting cycle ends, the operator reveals the raw server seed. Only then can the commitment and completed results be independently checked.
How to Verify a Provably Fair Game in Five Steps
Step 1: Save the Commitment Before Playing
Copy or screenshot the server seed hash before placing the bets you want to audit. Without the pre-bet hash, you may still reproduce a result, but you cannot prove that the revealed server seed was committed in advance.
Also record the current client seed and confirm whether the casino lets you change it. A custom client seed adds a player-controlled input, but it does not remove the need to verify the server commitment and result algorithm.
Step 2: Record the Exact Round Data
Save the nonce, bet ID, game mode, visible result and relevant settings. Nonce numbering may start at 0 or 1, and some platforms use a cursor or round index in addition to the nonce.
JSON or API payloads often use keys such as:
{
"server_seed": "...",
"client_seed": "...",
"nonce": 7,
"public_hash": "...",
"game": "dice",
"roll": 12.16
}Field names alone do not reveal the algorithm. A value called secret_salt, for example, may be used as an HMAC key, a message component or something else entirely.
Step 3: Reveal the Server Seed
Rotate the active seed or wait until the operator exposes it in seed history. Do not use an active unrevealed server seed in a third-party tool. Never paste wallet recovery phrases, private keys, passwords or two-factor codes into a game verifier.
Step 4: Check the Hash Commitment
Hash the revealed server seed with the same encoding documented by the casino. UTF-8 text and hexadecimal bytes are not interchangeable.
The computed SHA-256 value must match the hash saved before play. A match confirms that the revealed seed corresponds to the earlier commitment.
| Result | Meaning | Next Action |
|---|---|---|
| Exact match | The revealed seed matches the saved commitment. | Continue to result reproduction. |
| Mismatch | The inputs, encoding or commitment may be wrong. | Recheck whitespace, text/hex encoding and the correct seed cycle. |
| No saved hash | Pre-commitment cannot be established for this cycle. | Save the next commitment before playing. |
Step 5: Reproduce the Result
Use the revealed server seed, client seed, nonce and the exact platform algorithm. Compare the reproduced output with the completed result in the bet history.
A matching result is meaningful only when all of the following are correct:
- server seed encoding;
- HMAC key and message order;
- separators and cursor values;
- nonce indexing;
- game-specific conversion;
- rounding and display precision;
- extra settings such as mine count or Plinko rows.
What a Successful Check Proves
| Successful Check | Supported Conclusion | Not Proven |
|---|---|---|
| Revealed seed matches the saved hash | The operator revealed the seed associated with the earlier commitment. | The game conversion or payout table is correct. |
| HMAC output matches | The same key, message and encoding produced the same digest. | The digest was mapped to the game result correctly. |
| Displayed result is reproduced | The completed round is consistent with the tested disclosed algorithm. | The game has no house edge, the casino is safe or future rounds are predictable. |
Provably Fair Is Not the Same as RTP
A deterministic and reproducible outcome can still be priced with a house edge. Verification checks the randomness and commitment process; RTP checks the payout model.
| Question | Provably Fair Audit | RTP Audit |
|---|---|---|
| Was the revealed seed committed in advance? | Yes | No |
| Can the completed outcome be reproduced? | Yes | No |
| Does the multiplier match fair probability? | No | Yes |
| What is the house edge? | No | Yes, if the full payout model is known |
| Will withdrawals be processed? | No | No |
For multiplier and payout checks, use the relevant game audit or calculator. The Mines RTP audit checker, for example, evaluates the paytable rather than the hidden board.
Why Verification Results Commonly Fail
| Problem | Typical Symptom | Correction |
|---|---|---|
| Hashed seed used as the HMAC key | Commitment may look valid, but every game result differs. | Use the revealed raw server seed for result reproduction. |
| Wrong nonce | Valid-looking but completely different output. | Check the exact bet and whether counting begins at 0 or 1. |
| Text/hex confusion | HMAC digest never matches. | Confirm whether the server seed is UTF-8 text or decoded hex bytes. |
| Wrong message format | Digest differs despite correct seeds. | Check field order, separator and cursor values. |
| Wrong game conversion | HMAC matches but roll, multiplier or layout differs. | Use the exact platform-specific result mapping. |
| Missing game setting | Board or bucket differs. | Add mine count, rows, risk level or other round parameter. |
| Display rounding | Result differs only in the final decimal place. | Compare raw output before display rounding. |
Game-Specific Differences
The guide should not be used as a universal algorithm specification. The examples below describe the audit target, not one formula that applies to every casino.
Dice
Dice normally converts a digest or random byte stream into a bounded number. Operators may use modulo arithmetic, floating-point chunks or rejection sampling. Confirm the exact range, bias handling and decimal rounding.
Crash
Crash implementations may differ in 52-bit extraction, instant-bust logic, edge factors and rounding. A generic reference formula is not proof of compatibility with a specific casino.
Mines
Mines requires a deterministic ordering or shuffle of tile positions. Byte generation, cursor behavior and Fisher–Yates implementation must match the platform exactly.
Plinko
Plinko verification may reproduce left/right decisions or the final bucket. Rows, risk level and multiplier table are separate inputs, and verifying the path does not verify RTP.
Blackjack and Video Poker
Card games require reconstruction of a deck, shoe or replacement sequence. Even a matching card order does not prove the rules or paytable produce the advertised return.
Tools You Can Use
Browser Checker
The 100RTP.games checker can parse common JSON fields and perform browser-side commitment, HMAC, Dice, generic Crash and generic Mines checks. It does not automatically infer a proprietary operator algorithm.
Casino Verifier
The operator’s built-in verifier is useful for locating fields and confirming the documented workflow. Because it is supplied by the same operator, an independent reproduction is stronger evidence.
Command Line
For a text-encoded server seed, a SHA-256 commitment can be checked with OpenSSL:
printf '%s' 'your_server_seed' | openssl dgst -sha256A simple text-keyed HMAC example is:
printf '%s' 'client_seed:nonce' | openssl dgst -sha256 -hmac 'server_seed'These commands are examples only. They will not match a platform that decodes the key as hexadecimal bytes, uses another message format or adds a cursor or salt.
What to Do If the Result Still Does Not Match
- Export or screenshot the original bet details before changing anything.
- Confirm that the values belong to the same seed cycle and round.
- Repeat the commitment check independently.
- Compare the platform documentation with the selected tool mode.
- Try a second independent implementation or command-line calculation.
- Record both raw and displayed outputs, including rounding.
- Contact support with the bet ID, commitment, revealed seed, nonce, algorithm reference and reproduced output.
A mismatch after these checks may indicate undocumented implementation details, incorrect documentation, a verifier bug or a genuine integrity problem. Preserve the evidence and avoid overstating the conclusion until the algorithm and inputs are independently reviewed.
Provably Fair vs Traditional RNG Auditing
| Feature | Provably Fair | Traditional RNG Audit |
|---|---|---|
| Verification timing | Individual rounds can be checked after the seed is revealed. | Testing is performed periodically by an auditor. |
| Who can reproduce results? | Players or independent developers with the full algorithm and inputs. | Normally the testing laboratory. |
| Main strength | Granular post-round transparency. | Regulatory and laboratory oversight across the implementation. |
| Main limitation | Players must trust that the disclosed algorithm and interface describe the deployed code. | Players cannot normally reproduce an individual round. |
Provably fair is not fully trustless. It reduces the amount of trust required by making commitments and completed outcomes reproducible, but implementation, interface and platform risks remain.
Quick Reference
| Step | Action | Evidence Produced |
|---|---|---|
| 1 | Save the server seed hash before play. | Pre-bet commitment. |
| 2 | Record client seed, nonce, game settings and result. | Round-specific input set. |
| 3 | Rotate or reveal the server seed. | Raw server input. |
| 4 | Hash the revealed seed and compare commitments. | Commitment match or mismatch. |
| 5 | Run the exact game conversion and compare outputs. | Round-level reproduction. |
Related Tools and Guides
- Provably Fair Checker — execute the commitment and result checks.
- Provably Fair Predictor Scams — why verification cannot reveal future hidden outcomes.
- Mines RTP Audit Checker — verify multiplier pricing separately from board generation.
- Duel Dice Audit — roll verification and payout math.
- Duel Crash Audit — crash formula and distribution caveats.
- Duel Mines Audit — board reconstruction and multiplier checks.
- Zero-Edge Guides — full educational index.
Frequently Asked Questions
Can provably fair results be predicted?
No. A proper system hides the active server seed. Verification becomes possible after the relevant seed is revealed, not before future results are generated.
What is a server seed hash?
It is a cryptographic commitment to a hidden server seed. After reveal, the raw seed is hashed and compared with the value saved before play.
What is a nonce?
A nonce is a round counter used with a seed pair. The wrong nonce produces a different deterministic output.
Why does my check not match?
Common causes are the wrong nonce, wrong seed cycle, text-versus-hex encoding, extra whitespace, an incorrect message format or a game conversion that does not match the operator.
Does provably fair mean 100% RTP?
No. It checks outcome generation. RTP depends on payout rules, multipliers, paytables, caps and any return mechanism.
Is a matching round proof that the casino is safe?
No. It supports the integrity of that tested outcome only. Withdrawals, licensing, KYC and account terms remain separate risks.
Bottom Line
Provably fair verification is strongest when the pre-bet commitment, revealed seed, client seed, nonce, game settings and conversion formula are all available. Check the commitment first, then reproduce the completed result.
Keep the conclusion limited to the evidence. A match supports the integrity of one tested round. It does not establish RTP, predictability or overall casino reliability.
