How to Verify Provably Fair Results — Step-by-Step Guide

To verify a provably fair bet: collect the revealed server seed, your client seed, and the nonce from your bet history. Compute HMAC-SHA-256(serverSeed, clientSeed:nonce). Apply the casino’s documented outcome mapping to the hash. If your computed result matches the casino’s recorded result, the bet was fair. The full process takes under two minutes once you know where to find the data.

Related guides in this series: What is Provably Fair? | Server seed vs client seed explained | Can provably fair be rigged?

Want to skip the manual process? Our Provably Fair Verifier handles the hash computation and outcome mapping automatically — paste your seeds and get an instant result.

---

What You Need Before Verifying

Manual verification requires four pieces of data. Without all four, the check can’t be completed.

1. The revealed server seed

This is the casino’s original random string, kept secret until after your session ends or you rotate seeds. The hash of this seed is shown to you before you bet — that’s the commitment. After rotation, the original (unhashed) seed is revealed in your bet history or fairness settings page.

2. Your client seed

The string you (or the casino, if you accepted the default) contributed to the round. You’ll find this in your current fairness settings panel. If you’ve already rotated seeds, the client seed used during that session is recorded in your bet history.

3. The nonce

A counter that increments with each bet placed under the current seed pair. Bet number one uses nonce 0, bet number two uses nonce 1, and so on. The nonce for any specific bet is visible in your detailed bet history.

4. The game result

The outcome the casino recorded: the dice roll, crash multiplier, card order, or Plinko path. You’re checking whether the seeds and nonce, when hashed, produce this result through the casino’s documented mapping formula.

---

Step 1 — Find the Seed Data

Seed data is located in different places depending on the casino. Here’s where to look at the three platforms I tested most thoroughly.

Stake.com

Navigate to your profile icon → Bets → select any bet → click Fairness (the shield icon). This opens a panel showing the server seed hash for the active session, your client seed, and the nonce for that specific bet. To retrieve a revealed server seed from a completed session, go to Fairness Settings → scroll down to Previous Seeds → the unhashed server seed appears there after rotation.

Stake also provides a direct fairness page at stake.com/provably-fair/verification where you can paste seeds and recompute results in their own tool — though I’d recommend verifying independently using the ProofBets Verifier.

BC.Game

Go to your avatar → Fairness → History. Each bet in your history displays the server seed hash, client seed, nonce, and (for completed sessions) the revealed server seed. BC.Game’s original games (Crash, Hash Dice, Plinko, Limbo) each have a small fairness icon directly on the game screen that opens the same data panel mid-session.

See the BC.Game review for notes on which of BC.Game’s original games support provably fair and which don’t.

Roobet

Navigate to Fairness from your account menu or directly from the game screen via the shield icon. Roobet displays the current server seed hash and client seed prominently. After rotating, the previous server seed appears in the same panel.

For casinos not listed here, look for terms like “Fairness,” “Provably Fair,” or a shield icon either in account settings or directly on the game screen. Every legitimate provably fair casino provides this data. If you can’t find it, treat that as a warning sign.

---

Step 2 — Wait for the Server Seed to Unhash

This step catches players out most often. You can’t verify a bet until the server seed has been revealed — and it’s only revealed after you rotate your seed pair.

The timing matters for a specific reason. The casino commits to the server seed by showing you its SHA-256 hash before you bet. The actual seed stays hidden until you end the session or rotate seeds. This is by design: if the seed were visible in advance, you could calculate every upcoming outcome and eliminate the house edge. The hash commitment proves the seed existed before your bet without revealing it.

I ran this verification on a Stake Dice round last week — took about 90 seconds start to finish once the seed was revealed. The process itself isn’t complicated. Finding where the data lives is what trips people up.

What happens when you rotate seeds:

• The active server seed is revealed (unhashed) in your bet history
• All bets placed under that seed pair are now verifiable
• A new server seed hash is generated for future bets
• The nonce resets to 0

If you want to verify a specific bet, place the bet, then rotate seeds. The seed used for that bet will immediately become available for verification. You don’t need to end your entire session — you can rotate mid-session and continue playing with a new seed pair.

Important: verify within a reasonable window. Some casinos retain seed history indefinitely; others purge it after 90 days. If you’re verifying a bet for a dispute, don’t wait.

---

Step 3 — Combine Seeds and Calculate the Hash

With the revealed server seed, client seed, and nonce in hand, the computation is straightforward.

Most provably fair casinos use HMAC-SHA-256 rather than plain SHA-256 for the final hash. The formula is:

hash = HMAC-SHA-256(key=serverSeed, message=clientSeed:nonce)

Where clientSeed:nonce is the client seed and nonce joined by a colon — for example, my-client-seed:42.

You can compute this in a browser console with two lines of JavaScript, or in Python as follows:

import hmac
import hashlib

server_seed = "your_revealed_server_seed_here"
client_seed = "your_client_seed_here"
nonce = 42  # Replace with the actual nonce for the bet you are verifying

message = f"{client_seed}:{nonce}"
result = hmac.new(
    server_seed.encode(),
    message.encode(),
    hashlib.sha256
).hexdigest()

print(result)

The output is a 64-character hexadecimal string. That’s the raw hash the casino used to derive the game result.

For a deeper explanation of why HMAC-SHA-256 is used rather than plain SHA-256, and how the hash properties make manipulation detectable, see our SHA-256 hash calculator gambling guide.

---

Step 4 — Derive the Game Result

The raw hash must be converted into a game-specific outcome. Each casino documents this mapping formula — and the formula is where you need to pay close attention, because this is the layer where a dishonest casino could theoretically manipulate outcomes while still passing hash verification (see can provably fair be rigged? for the technical detail on that risk).

Dice (standard)

Take the first 8 hex characters of the hash. Convert to a decimal integer. Divide by 0xFFFFFFFF (4,294,967,295). Multiply by 100. The result is the roll value between 0.00 and 99.99.

roll = (parseInt(hash.slice(0, 8), 16) / 0xFFFFFFFF) * 100

Crash / Limbo

Crash multiplier derivation varies by casino. Stake’s documented formula converts the hash to a float and applies an exponential transformation with a built-in 1% house edge. The exact formula is published in Stake’s fairness documentation. If you’re verifying a Stake crash bet, use the Provably Fair Verifier which implements Stake’s specific mapping.

Card games (blackjack, baccarat)

The hash is segmented into multiple chunks, each chunk determining one card position using a Fisher-Yates shuffle. The full deck order is derived deterministically from the hash.

Multi-outcome games (Plinko, Mines, Keno)

These games require multiple values from the hash. The hash is expanded using additional nonce increments (nonce, nonce+1, nonce+2, etc.) to generate enough entropy for all positions.

The casino’s provably fair documentation page must specify the exact mapping. If it doesn’t, the claim can’t be independently verified.

---

Step 5 — Compare Your Result to What the Casino Showed

After computing the outcome from the hash, compare it to the result recorded in your bet history.

If they match: The bet was determined by the documented algorithm using the pre-committed server seed. The outcome wasn’t manipulated after your client seed was known.

If they don’t match: One of four things has happened:

1. You used the wrong seeds or nonce — double-check each value from your bet history
2. You applied the wrong outcome mapping — verify against the casino’s specific documentation
3. The casino uses a different hash algorithm than you assumed — confirm whether they use HMAC-SHA-256, plain SHA-256, or a variant
4. The result genuinely doesn’t verify — which is a serious red flag (see the next section)

For most players, mismatches in initial attempts are caused by data entry errors rather than casino misconduct. Our Provably Fair Verifier reduces this risk by handling the computation automatically with casino-specific presets.

---

Using Our Provably Fair Verifier Tool

Manual verification is instructive but time-consuming. The ProofBets Provably Fair Verifier automates the hash computation and outcome mapping for the casinos we cover.

What it automates:

• Casino-specific HMAC construction (Stake, BC.Game, Roobet, FortuneJack, and others)
• Outcome mapping for each supported game type (Dice, Crash, Plinko, Mines, Limbo, etc.)
• Batch verification — paste multiple bets and check them all at once

What it doesn’t do:

• Access your casino account directly — you still need to copy the seed data manually
• Verify third-party slots or live dealer games — these use traditional RNG and aren’t provably fair

The verifier runs entirely in your browser. Seeds are never transmitted to our servers. The source logic for each casino’s computation is documented alongside the tool so you can audit it.

---

What If the Results Don’t Match?

A genuine mismatch — after you’ve confirmed the correct seeds, nonce, and mapping formula — is a serious red flag.

Immediate steps:

1. Screenshot everything. Capture the bet result page showing the server seed hash, client seed, nonce, and game outcome. Capture the revealed server seed from your history. Capture your hash computation showing the mismatch. Timestamps matter.

2. Repeat the check. Run the same verification twice — once manually and once using our verifier tool — to eliminate calculation error.

3. Check if others have reported the same issue. Search casino-specific threads on Reddit (r/cryptogambling), Bitcoin Talk, and Casino Guru. A pattern of mismatches from multiple players is significantly more meaningful than a single instance.

4. Submit a formal complaint. Every licensed casino has a disputes mechanism. For Curaçao-licensed casinos (which includes most crypto casinos), complaints can also be filed with the Curaçao Gaming Control Board. Casino Guru’s complaint service has a strong track record of facilitating resolutions and is my recommended first point of escalation.

5. Don’t continue playing at the casino until the issue is resolved. Continuing to bet while a verification dispute is open weakens your position.

A single non-matching result can sometimes indicate a documentation error on the casino’s side (wrong version of the formula published) rather than intentional fraud. That said, treat any unresolved mismatch as a reason to withdraw your balance and pause play.

---

Which Casinos Support Provably Fair Verification?

Not all crypto casinos implement provably fair. Among the casinos we cover, these support independent verification on their original games:

• Stake.com — Dice, Plinko, Mines, Crash, Limbo, Keno, Blackjack, Video Poker. Well-documented, open-source verification code available. See our Stake.com review.
• BC.Game — Crash, Hash Dice, Plinko, Limbo, Wheel, Ring of Fortune, and other BC Originals. Algorithm documented in the fairness section. See our BC.Game review.
• FortuneJack — Dice, Plinko, Keno, Video Poker, Heads or Tails, and other in-house originals. One of the earliest crypto casinos to adopt provably fair (since 2014). See the Is FortuneJack Provably Fair? guide for the full breakdown.
• Roobet — Crash and original Roobet games.
• Duelbits — Original games with documented provably fair implementation.

Third-party slots and live dealer games at all of these casinos use traditional RNG certified by testing labs and aren’t provably fair. For a full comparison of which casinos have the most comprehensive implementations, see our Best Provably Fair Casinos 2026 list.

---

Frequently Asked Questions

Do I need to verify every bet I place?

No. The value of provably fair is that you could verify any bet if you wanted to. Most players verify selectively — after a suspicious run of results, after a large loss, or just as a spot-check. The option to verify is the trust mechanism, not the act of verifying every round.

Can I verify bets after a long time has passed?

Most casinos retain seed history for 90 days or longer. Some keep it indefinitely. Check the casino’s terms or fairness documentation for their retention policy. If you need to verify a disputed bet, act promptly.

What happens to the server seed hash commitment if I never rotate my seeds?

The server seed stays hidden as long as you never rotate. You can’t verify any bet placed under the current active seed pair until you do. There’s no disadvantage to rotating frequently — the nonce resets to 0 and a new server seed hash is generated.

Does verifying a bet prove the house edge is what the casino claims?

No. Hash verification proves only that a specific outcome was determined by the pre-committed seeds. The house edge is embedded in the outcome mapping formula. A casino could use a correctly implemented hash function with a secretly inflated house edge. Verifying the house edge requires auditing the mapping formula and checking the statistical distribution across many bets.

Is there a difference between SHA-256 and HMAC-SHA-256 in provably fair?

Yes, and it matters. Plain SHA-256 takes a single input and produces a hash. HMAC-SHA-256 uses a key (the server seed) and a message (the client seed plus nonce) to produce a keyed hash. Most modern provably fair implementations use HMAC-SHA-256. If you apply the wrong formula when verifying, your result won’t match regardless of whether the casino was honest.

---