How to Verify Provably Fair — Seed, Hash & Nonce Explained

Provably fair is the reason you do not have to trust a crypto casino’s word. It is a cryptographic system that lets you independently verify that every game outcome was determined fairly — before you placed your bet. No faith required. Just math you can check.

This guide walks you through the entire process: what provably fair actually proves, how it works under the hood, and step-by-step verification for each major game type. You do not need coding skills to verify using web-based tools — a browser and five minutes per round is all it takes. For advanced users, we also provide command-line methods at the end of this guide.

What You Need Before Verification

What Provably Fair Actually Proves

Before diving into mechanics, it is critical to understand the scope and limits of provably fair verification:

Provably fair and RTP are independent properties. A game can be provably fair with a 5% house advantage — the verification proves the 5% is applied honestly, not that it does not exist. For RTP verification, you need to check the payout structure separately. Full explanation of how RTP and provably fair relate.

How It Works: The Commit-Reveal Model

Most provably fair systems follow the same core commit–reveal logic, though the exact implementation varies by operator. Some platforms use a hash-chain model where a chain of millions of SHA-256 hashes is pre-generated and traversed in reverse. Others, such as Duel, use the seed-and-nonce approach described below. The underlying principle — pre-commitment to outcomes — is shared across all variants.

The following describes the seed-based model, which is the most common in crypto originals:

Phase 1: Commit (Before Your Bet)

1. The casino generates a random string called the server seed.
2. The casino runs SHA-256 on the server seed, producing a hash — a 64-character hexadecimal fingerprint.
3. This hash is shown to you before you bet. It commits the casino to its seed without revealing it.
4. You provide or accept a client seed — your own random input. You can change this to any string you want.

At this point, the outcome is mathematically locked. The casino cannot change the server seed because it would change the hash, which you already have. You cannot predict the server seed from the hash because SHA-256 is a one-way function.

Phase 2: Play

1. Each bet uses the formula: result = HMAC-SHA256(server_seed, client_seed + “:” + nonce)
2. The nonce is a counter that increments with each bet: 0, 1, 2, 3 and so on. Same seeds, different nonce means a different result.
3. The HMAC output, a 64-character hex string, is converted into a game result using a published conversion formula specific to each game type.
4. The game displays the result and settles your bet.

Phase 3: Reveal (After Your Session)

1. You rotate your server seed, usually in Settings, Fairness or a similar menu.
2. The casino reveals the raw server seed used for all previous bets.
3. A new server seed is generated for future bets, with a new hash commitment.
4. You can now verify every bet made under the old seed pair.

The rotation step is important: you can only verify bets after the server seed is revealed, and the server seed is only revealed when you rotate to a new one. This prevents you from using the server seed to predict future outcomes while still allowing full post-game verification.

The Universal Verification Process (5 Steps)

Regardless of game type, verification always follows these five steps:

Step 1: Record Your Seeds Before Playing

Before your session, go to the Fairness or Seeds section in your account settings. Note:

• Server seed hash, the 64-character hex string shown before play
• Your client seed, the string you set or the default one

Pro tip: Change the client seed to a custom string before playing. This ensures the casino could not have known your input in advance. Something like myverification2026april works fine.

Step 2: Note the Nonce for Each Bet

Each bet in your history will have a nonce number. This starts at 0 or 1, depending on the casino, and increments with each bet under the same seed pair. You will need the exact nonce for the specific bet you want to verify.

Step 3: Rotate the Server Seed

After your session, go back to the Fairness settings and rotate to a new server seed. This reveals the raw, unhashed server seed used for all your previous bets. Save this string — you will need it.

Step 4: Verify the Hash Commitment

Take the revealed server seed and run SHA-256 on it. You can use:

• Any online SHA-256 calculator
• A command line: echo -n "your_server_seed" | openssl dgst -sha256
• The casino’s own verification tool

The resulting hash must match exactly the hash that was shown to you before you started playing. If it matches, the casino committed to this seed before your bets and did not change it. If it does not match, something is wrong — contact support with evidence.

Step 5: Reproduce the Game Result

Using the server seed, your client seed and the nonce, run the HMAC-SHA256 calculation and apply the game-specific conversion formula. The result must match what you saw on screen. This is where each game type differs, so we break it down below.

Real Example: Duel Casino Dice Verification

Here is a real verification we performed on a Duel Casino Dice round:

Duel’s implementation differs from the generic example above: the HMAC key is the server seed imported as raw hex bytes, not text-encoded, and Dice uses modulo 10001 conversion with bias rejection rather than float-based division. We verified 6 real outcomes across Dice, Crash and Mines — all matched. See the full verification log or use the Provably Fair Checker for supported seed, hash, nonce and game-result checks.

Game-Specific Verification

Dice

Dice is the simplest provably fair game to verify because the outcome is a single number.

A common implementation:

1. Compute: hash = HMAC-SHA256(server_seed, client_seed + ":" + nonce)
2. Take the first 8 characters of the hash, equal to 4 bytes
3. Convert from hexadecimal to a decimal integer
4. Divide by 2^32, or 4,294,967,296, to get a float in the range [0, 1)
5. Multiply by the game’s range, commonly 10,000 or 100, to get the dice roll

Example:

• Server seed: abc123def456...
• Client seed: mytest
• Nonce: 0
• HMAC result first 8 chars: a1b2c3d4
• Hex to decimal: 2,712,847,316
• Divided by 4,294,967,296 = 0.6316…
• Dice roll: 63.16

If you bet “Roll Under 65.00,” this would be a win. The payout at 0% advantage for a 65% win chance would be 100 ÷ 65 = 1.5385x.

Verification check: Does the computed roll match what the casino displayed? If yes, the round’s outcome was pre-committed and not manipulated.

Note: This confirms the outcome was pre-committed. To verify the return level, separately confirm that the displayed multiplier matches 1 / win_probability. These are independent checks.

Crash

Crash verification is slightly more complex because the multiplier must be converted from the hash output using a specific formula.

A common approach:

1. Compute the HMAC hash as above
2. Take the first 13 hex characters, equal to 52 bits, and convert them to an integer
3. In edge-bearing implementations, some operators insert an instant-bust check: if the converted value is divisible by a threshold number, such as 101, the round ends at 1.00x. This occurs roughly 1% of the time and is one mechanism for generating the house margin.
4. For non-instant results, apply the crash formula: crash_point = floor((100 × 2^52 − int) / (2^52 − int)) / 100

At 0% advantage: The divisibility check described in step 3 is either skipped entirely or the threshold is set so that it does not reduce the expected value below fair odds. When verifying a 0% Crash game, confirm whether the operator’s fairness documentation includes or excludes this step.

Verification check: Compute the crash point from your seeds. Compare it to what the game displayed. They must match.

Note: Matching confirms the outcome was pre-committed. To verify that the overall bust distribution produces fair returns, you would need to audit the conversion formula itself or collect a large statistical sample. The exact Crash formula varies by operator — always use the one published in their fairness docs.

Mines

Mines generates a grid of mine positions from the hash, and your multiplier at each step is based on the remaining safe tiles.

How mine positions are typically generated:

1. Compute the HMAC hash
2. The hash output itself serves as the randomness source. Consecutive byte chunks of the HMAC string are converted to numbers and used directly to perform a Fisher-Yates shuffle of the 25 tile positions for a 5×5 grid. If the algorithm requires more random bytes than the 32-byte hash provides, implementations typically re-hash the output to generate additional bytes.
3. The first M positions in the shuffled array are mines, where M is your chosen mine count
4. The remaining 25 − M positions are safe tiles

Verification check: Reproduce the mine positions from your seeds. Confirm they match the positions revealed when your round ended. Each safe tile you clicked should have been in a non-mine position, and the mine that ended your game, if applicable, should be where the algorithm placed it.

Note: This confirms mine placement was pre-committed. To verify the return level, separately confirm the cashout multiplier and payout table. These are independent checks.

Plinko

Plinko converts the hash into a series of left/right decisions as the ball falls through rows of pegs.

A common approach:

1. Compute the HMAC hash
2. For each row of pegs, such as 16 rows, extract one bit from the hash
3. If the bit is 0, the ball goes left. If the bit is 1, the ball goes right.
4. After all rows, the ball lands in a specific bucket
5. The bucket determines the multiplier

The ball’s final position follows a binomial distribution. In a 16-row board, the number of “rights” out of 16 decisions determines the bucket. This creates the familiar bell-curve shape where the center buckets are hit most often and edge buckets are rare.

Verification check: Reproduce the ball path from your seeds. Confirm it matches the bucket that was displayed.

Note: Verifying the ball path confirms outcome pre-commitment. Verifying the weighted multiplier average across all buckets confirms the return level. These are independent checks, and probability distributions change with risk level and number of rows. Always verify using the exact settings from your round.

Blackjack

Blackjack uses the provably fair system to shuffle the deck.

How it works:

1. Compute the HMAC hash
2. The hash output serves as the randomness source. Byte chunks from the HMAC string drive a Fisher-Yates shuffle of the card array. Multi-deck implementations may extend the hash by re-hashing when more random bytes are needed.
3. Cards are dealt in order from the shuffled array

Verification check: Reproduce the shuffled deck from your seeds. Confirm that the cards dealt match what you saw. This is more complex than Dice or Crash verification because you need to reconstruct the full deck order, but the principle is identical.

Verification Tools

Casino Built-In Verifiers

Most provably fair casinos provide their own verification tool where you paste your seeds and nonce. Duel includes a verifier accessible from individual game interfaces and from the site footer. These are convenient as a first-pass sanity check but have an inherent limitation: you are trusting the casino’s own code to confirm its own fairness.

Third-Party Verifiers

Independent verification tools remove this trust requirement. Use only client-side verifiers — tools that run entirely in your browser via JavaScript, with no server-side processing. Your seeds are sensitive data: submitting them to a remote server means trusting that server not to log or misuse them. Open-source verifiers with visible source code are the safest option.

For browser-based checks, use the Provably Fair Checker for supported server seed commitment checks, HMAC-SHA256 output and game-result reproduction. Use this guide to understand the process; use the tool page when you want to run the actual check.

DIY Verification (Command Line)

For maximum confidence, you can verify with your own command-line tools. The following commands use openssl, which works consistently across Linux, macOS and Windows with OpenSSL installed.

Hash verification:

echo -n "your_server_seed" | openssl dgst -sha256

HMAC calculation:

echo -n "client_seed:nonce" | openssl dgst -sha256 -hmac "server_seed"

The output is the raw hash. You then apply the game-specific conversion formula to get the result. This approach requires no trust in any third party — you are running the cryptography yourself.

Common Verification Mistakes

• Using the hashed server seed instead of the unhashed one. You need the revealed, raw server seed, not the 64-character hash that was shown before play. The hash is for commitment verification. The raw seed is for result reproduction.
• Wrong nonce. Each bet has a unique nonce. If you are verifying bet #47, use nonce 47, or 46 if the casino starts at 0.
• Wrong separator format. Some casinos use client_seed:nonce, others use client_seed-nonce. Check the operator’s documentation for the exact format.
• Forgetting game-specific parameters. Mines requires the mine count. Plinko requires the risk level and row count. Using wrong parameters will produce a different result.
• Verifying after seed rotation without saving the old seed. Once you rotate, you need the revealed server seed for all prior bets. If you did not save it, you can usually find it in the Fairness section’s history.

What If Verification Fails?

First: double-check everything above. The most common cause of a mismatch is user error — wrong nonce, wrong separator, hashed vs unhashed seed, or wrong game parameters.

If you have confirmed all inputs are correct and the result still does not match:

1. Document everything: screenshots, seed values, nonce, expected result and actual result.
2. Try a different verification tool, third-party or DIY, to rule out a tool-specific bug.
3. Contact the casino’s support with your evidence.
4. If unresolved, share your findings publicly on crypto gambling forums or social media. The transparency of provably fair means the community can independently verify your claim.

A legitimate mismatch after all inputs and formulas have been double-checked deserves escalation, because either the inputs are still wrong or the implementation or documentation is inconsistent.

Why Bother Verifying?

Industry estimates suggest a small fraction of players routinely verify their provably fair results. If you are playing casually with small stakes, the effort may not feel worth it. But there are good reasons to verify at least occasionally:

• Trust establishment. Verify a few rounds at a new casino to confirm their implementation actually works. If it checks out, you have real evidence of fairness — not just a marketing claim.
• Large bets. If you are wagering significant amounts, verifying ensures every outcome was legitimate.
• Audit trail. If you ever need to dispute a result, having verified seeds and calculations gives you concrete evidence.
• RTP verification. By verifying outcomes and cross-referencing with payout tables, you can independently confirm whether a game is truly 100% RTP. How RTP verification works.

Provably Fair vs. Traditional RNG Auditing

Traditional online casino games use Random Number Generators certified by third-party auditors such as eCOGRA or iTech Labs. These audits are periodic — the auditor tests the RNG at intervals and certifies it meets standards.

Provably fair lets you audit every individual bet in real time. This is a fundamentally different level of transparency. However, it comes with trade-offs:

Neither system is strictly better. Provably fair offers stronger per-bet verification but exists primarily in less-regulated environments. Traditional auditing offers regulatory backing but less granular transparency. For 100% RTP games at crypto casinos, provably fair is the available and appropriate verification method.

Quick Reference Card

Provably Fair Verification FAQ