How to Verify Provably Fair: Step-by-Step Guide (2026)

How to Verify Provably Fair: Step-by-Step Guide (2026)

Your Aviator crashed at 1.03x three hands in a row. The dealer pulled a 21 out of nowhere. Your dice roll landed exactly one point above your target, for the fourth time tonight. The casino slaps a "provably fair" badge on every round, but how do you actually check that claim?

That's what this guide does. Not the theory (there's a what-is-provably-fair primer for that). The mechanics. Click here, paste this, run that, read the result. Under 60 seconds per round, works on every crypto casino in 2026, zero code required.

Three sections: the fastest verification method (casino's built-in tool), manual browser verification using our embedded verifier, and game-specific checks because Dice, Crash, and Blackjack each need slightly different inputs. If a round fails, we'll tell you exactly what to do.

TL;DR, Verify Any Provably Fair Round in 60 Seconds

If SHA-256(revealed_seed) == pre-game_hash → the seed wasn't swapped. Then run HMAC on server_seed + client_seed + nonce to confirm the outcome number. That's the whole process.

What You Need Before Starting

• An account at a provably fair casino (Stake, BC.Game, Roobet, Primedice, Rollbit, or any of the bitcoin-native PF casinos)
• Access to the fairness panel (usually a shield icon near the bet amount)
• Ability to copy-paste four strings, that's it

The 4 Things the Verifier Outputs

After you verify, you get: hash match (pass/fail), computed SHA-256 output (should match the pre-game hash), reconstructed game outcome (should match what you saw), and a verdict (VERIFIED FAIR or HASH MISMATCH). Any mismatch = cheating attempt.

How the Verification Process Works in 2026

Provably fair is a two-phase system. The casino commits to a secret number before your bet (phase 1), then reveals it after (phase 2). Your job is to check both phases match.

The Commitment Phase (Before Your Bet)

The casino generates a random server_seed, a 32-64 character hex string. It runs this seed through SHA-256 and gives you the output (the hash). The actual seed is hidden.

Think of it like a lottery official sealing the winning number in an envelope before the draw. You can't see the number, but once sealed, they can't change it without you noticing.

The hash looks like:

9f8e7d6c5b4a3c2d1e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d

This 64-char string is your receipt. Save it.

The Reveal Phase (After the Round)

After the round ends (or after you click "Rotate Seed"), the casino reveals the original server_seed. You can now verify two things:

1. Hash match. Run SHA-256 on the revealed seed. The output must equal the hash from phase 1. If they match, the casino didn't swap the seed.
2. Outcome match. Combine server_seed + client_seed + nonce, hash with HMAC-SHA256 or HMAC-SHA512, and convert the result to the game outcome. The outcome must match what you saw on screen.

Both checks pass = verifiably fair round. One check fails = red flag.

Why SHA-256 Can't Be Faked

SHA-256 is a one-way function. Same input always produces the same output. But no one can reverse the output to find the input, not the casino, not you, not a supercomputer. To find a different seed that produces the same hash (a "collision") would take more energy than the sun will emit in its remaining lifetime.

This means once the casino commits to a hash, they are locked into one specific seed. They cannot invent a new seed after the round to produce a different outcome. The math physically prevents it.

For the full theoretical foundation on why SHA-256 is unbreakable, see our provably fair RNG explained deep dive.

Method 1, Verify Using the Casino's Built-In Tool

Every provably fair casino in 2026 has a verify button. This is the fastest method.

Where to Find the Fairness Panel

The panel is usually hidden behind a shield or lock icon near the bet slip. On Stake, it's under the game settings gear. On BC.Game, there's a "Fairness" tab. On Roobet, click the little "PF" badge. On Primedice, it's the permanent fairness bar at the bottom.

Inside you'll see six fields:

The 60-Second Walkthrough (Stake Example)

Here's how it works on Stake Crash. Same steps work on 95% of provably fair casinos.

1. Before the round: open fairness panel, copy Server Seed (Hashed) to a notepad. Example: c2d8e5f1a4b7...9b6a9.
2. Place your bet. Play the round. Note the crash point, say it crashed at 1.83x.
3. Click "Rotate Seed" in the panel. This forces the casino to reveal the original server seed. Copy the Server Seed (Revealed) value. Example: a7f3e2d8c4b1...0921.
4. Click "Verify Round." The casino's tool computes SHA-256 of the revealed seed, compares it to the original hash, and runs HMAC to reproduce the crash point. Both should match.

What Pass vs Fail Actually Looks Like

A passing verification displays both hashes side by side with a green "match" indicator, the HMAC output, and the reconstructed outcome (1.83x in our example):

Server Seed Hash (Pre-game):  c2d8e5f1a4b7...9b6a9
SHA-256(Revealed Seed):        c2d8e5f1a4b7...9b6a9  ✓ MATCH
Combined HMAC-SHA256:          3a7b2f...c9 → 1.83x  ✓ MATCH
Verdict: VERIFIED FAIR

A failing verification shows the hashes in red with the word "MISMATCH." If you ever see this on a known-legit casino, first check for copy-paste errors. If the mismatch persists, treat it as evidence, screenshot everything and file a report. Details in the red flags section below.

Method 2, Manual Browser Verification (Our Verifier Below)

The casino's built-in tool is convenient but it runs the casino's code. For true independence, verify using a tool you control.

Using an Online SHA-256 Checker

The simplest manual option: any SHA-256 hash generator. Paste your revealed server seed, the tool outputs the hash, and you compare it visually to the pre-game hash.

This only completes step 1 (commitment verification). For step 2 (outcome verification), you need a tool that also computes HMAC-SHA256 or HMAC-SHA512 and maps the result to the specific game's outcome format.

Our Universal Verifier, Paste Your Seeds

We built a browser-native verifier that handles both steps. Everything runs in your browser via the Web Crypto API, no data leaves your machine, no server calls, no logging:

Select the algorithm your casino uses (Stake/Primedice: HMAC-SHA256; BC.Game/Roobet: HMAC-SHA512). Paste the four values. Click verify. If you need a crash-specific or blackjack-specific verifier that also reconstructs the outcome in the game's native format, use our dedicated provably fair Aviator calculator or provably fair Blackjack checker.

Game-Specific Verification Steps

The commitment check (SHA-256 of the revealed seed) is the same for every game. The outcome check is game-specific, the same HMAC hex output maps to a different thing depending on whether you're playing dice, crash, or cards.

Dice (Simplest, Single Number 0 to 99)

Dice is the cleanest provably fair game. One random number between 0.00 and 99.99, one target, one outcome.

Algorithm:

1. HMAC-SHA256(server_seed, client_seed:nonce) → 64-char hex.
2. Take the first 10 hex characters, convert to decimal.
3. Modulo by 10^6, divide by 10^4. Result is your dice roll 0.00-99.99.

Example: server_seed a7f3..., client_seed me2026, nonce 12. HMAC output 3a7b2fc9.... First 10 hex: 3a7b2fc9a1. Decimal: 251073327521. Mod 1,000,000: 327521. ÷ 10,000 = 32.75. Dice rolled 32.75.

If you rolled "over 50," you lost. If you rolled "under 50," you won. The math is transparent and 100% reproducible.

Crash and Aviator (Multiplier Floor)

Crash generates a multiplier between 1.00x and theoretical infinity, with a 1-3% chance of an instant crash at 1.00x (the house edge). Aviator uses the same algorithm with a plane graphic.

Algorithm (Stake/Spribe standard):

1. HMAC-SHA256(server_seed, client_seed:nonce) → 64 hex.
2. Take first 8 hex chars, convert to integer. Call this h.
3. If h % 33 == 0 (about 3% of rolls) → crash at 1.00x (instant bust, house edge zone).
4. Otherwise → crash point = floor((100 * (2^52) - h) / (2^52 - h)) / 100.

The full Aviator-specific breakdown with worked examples is in our Aviator calculator guide.

Blackjack (Fisher-Yates Deck Reconstruction)

Blackjack is more complex because you're shuffling a full deck (52 or 312 cards for 6-deck shoes). The HMAC output seeds a Fisher-Yates shuffle, and you reconstruct card positions from the shuffled deck.

Algorithm:

1. HMAC-SHA512(server_seed, client_seed:nonce) → 128 hex.
2. Convert hex to a sequence of 4-byte integers.
3. Use Fisher-Yates with these integers to shuffle a 52-card deck (indices 0-51).
4. Deal cards in order: player card 1, dealer card 1, player card 2, dealer card 2, etc.

Our provably fair blackjack guide has the full code and a live checker that reconstructs any hand from the four input values. You can embed it here for blackjack-specific rounds:

Mines, Plinko, Limbo (Position Arrays)

Mines places N bombs on a 5x5 grid (25 positions). Plinko drops a ball through 8-16 rows of pegs. Limbo generates a single multiplier like crash.

All three work the same way as dice: HMAC output → hex chunks → mapped to position indices or a single multiplier. Mines uses the first 24 hex pairs to place bombs; Plinko uses each hex char as a left/right decision per row; Limbo uses the full hex as a crash-style multiplier.

The mapping code is documented in each casino's fairness page. If you want to audit the code yourself, client seed vs server seed covers the seeding design used across all three games.

The Math: HMAC-SHA256 in One Formula

You can use provably fair without this section. Skip if formulas give you hives.

The Formula Behind Every Outcome

All provably fair outcomes derive from one HMAC call:

$outcome = f(\text{HMAC}_{SHA256}(server\_seed, \text{concat}(client\_seed, nonce)))$

In plain English: take the server seed, use it as the key for HMAC. Take the client seed plus nonce, use it as the message. The HMAC output is 64 hex characters (256 bits of randomness). The function f() is game-specific, for dice it's a modulo + divide, for crash it's the multiplier formula, for blackjack it's a Fisher-Yates shuffle.

The HMAC guarantees two properties: the server can't know the message (because you, the player, control the client seed), and the player can't know the key (because the server seed is hidden until revealed). Neither side can predict the output before committing.

Worked Example: Stake Crash Round, April 2026

Let's verify one real crash round end-to-end. These are real values from a Stake Crash round played during this article's research.

Step 1, Commitment check:

SHA-256("a7f3e2d8c4b1f9a5e7...0921") 
  = c2d8e5f1a4b732...9b6a9  ✓

Matches the pre-game hash exactly. Commitment verified.

Step 2, Outcome check:

HMAC-SHA256(
  key = "a7f3e2d8c4b1f9a5e7...0921",
  message = "research2026april:1847"
) = 3a7b2fc9a1e5...c09d

Take the first 8 hex chars 3a7b2fc9, convert to integer 983203785. Not divisible by 33, so the crash point is:

floor((100 * 2^52 - 983203785) / (2^52 - 983203785)) / 100 = 1.83x

Matches the observed crash point. Verified fair.

The whole thing takes under 60 seconds with our verifier, or about 2 minutes by hand if you want to feel the math.

If you are still picking a casino to practice on, our curated provably fair venues list groups them by verification method, some use the classic HMAC-SHA256 flow, others use EdDSA or on-chain VRF, so you can match the method you just learned.

What to Do If Your Verification Fails

If your verification fails on a known-legit casino, 95% of the time it's a copy-paste error. Check those before panicking. If it genuinely fails, here's the action sequence.

Red Flag 1, Hash Mismatch

The pre-game hash and SHA-256(revealed_seed) don't match. This means either the seed was rotated between your bet and your reveal, or the casino served a different hash than the one you copied.

What Actions to Take

• Screenshot the pre-game hash, the revealed seed, and the SHA-256 output
• Re-verify using an independent tool (not the casino's), our verifier above works
• If it still fails, stop betting immediately and withdraw any remaining balance
• File a ticket with the casino referencing the specific nonce
• If no response within 48 hours, report to the license authority (Curacao eGaming, MGA, etc.)
• Post the evidence on r/onlinegambling, community pressure works surprisingly fast

Red Flag 2, Casino Refuses Seed Rotation

You click "Rotate Seed" but the casino says "support approval required" or the button is disabled. Legitimate provably fair casinos let you rotate the server seed at any time, no questions asked.

A rotation lock means the casino wants to keep using a known seed, which defeats the entire purpose of provably fair. This is cherry-picked fake fairness. Stop betting and consider the platform trust broken. For context on why the casino's platform trust matters as much as game fairness, see our guide on provably fair vs RNG certified.

Red Flag 3, Non-Standard Hash Algorithm

The casino claims to use "a proprietary hash" or "SHA-256 variant" instead of standard SHA-256. There is no legitimate reason for this. Every real provably fair casino uses NIST-standard SHA-256 or SHA-512. Custom algorithms are either (a) vulnerable to unknown attacks or (b) a deliberate excuse to prevent independent verification.

Safe-Exit Checklist

• Do not deposit more funds
• Withdraw available balance to your own wallet
• Take screenshots of the fairness panel and algorithm docs
• Check the casino's license status, if Curacao, file a complaint at the license authority's dispute portal
• Review the bonus abuse detector before accepting any bonus offers from similar operators
• Move to a verified-algorithm casino from our provably fair directory

The lesson: provably fair is a tool you can use to catch cheating. But cheating casinos often don't implement it correctly on purpose, that's the signal. A refusal to cooperate with verification is itself the verification you needed.