How to Verify Provably Fair Casino Games (Step-by-Step Guide)

What You're Actually Verifying

When you verify a provably fair result, you're confirming two things:

• 1
  The commitment was honest. The hashed server seed you were shown before the bet matches the actual server seed revealed after the bet. This proves the casino didn't change the server seed mid-round.
• 2
  The result matches the math. Given the server seed, your client seed, and the nonce, the HMAC-SHA256 output produces the exact game result the casino showed you. This proves the result wasn't fabricated.

If both checks pass, the round is mathematically verified as fair. There is no ambiguity -- the same inputs will always produce the same output, on any computer, anywhere in the world.

The Verification Process -- 4 Steps

A Worked Example -- Verifying a Stake Dice Roll

Let's walk through the exact math for a Stake-style dice verification. This is the most common algorithm and is also used by Roobet, Shuffle, and several other major operators.

// Inputs
const serverSeed = "a1b2c3d4e5f6..."; // Revealed after rotation
const clientSeed = "myCustomSeed123";
const nonce = 42;

// Step 1: Build the HMAC message
const message = "myCustomSeed123:42:0";

// Step 2: Compute HMAC-SHA256(serverSeed, message)
// Using Web Crypto API: crypto.subtle.sign('HMAC', key, data)
const hmacHex = "e3b0c44298fc1c14..."; // 64-char hex output

// Step 3: Extract the result
// Take the first 5 hex characters
const hexSlice = "e3b0c"; // = 933644 in decimal

// Step 4: Apply the formula
// 933644 % 10000 = 3644
// 3644 / 100 = 36.44
const diceRoll = 36.44;

// The casino should have shown you 36.44 for this round.
// If it did, the round was fair. If it didn't, something is wrong.

The formula is deterministic. Anyone with the same three inputs (server seed, client seed, nonce) will always get 36.44. That's the entire point -- the result is fixed at the moment of the commitment, and neither party can change it afterward.

Game-Specific Verification Notes

While the underlying HMAC-SHA256 computation is the same across all games, each game type uses a different formula to convert the hash output into a game result:

• Dice: First 5 hex characters are converted to a decimal, modulo 10,000, divided by 100. Result range: 0.00 to 99.99. See our dice algorithm deep dive.
• Crash: First 8 hex characters converted to a 32-bit integer, used in the formula 2^32 / (int + 1) * (1 - houseEdge), floored to 1.00x minimum. See our crash algorithm guide.
• Limbo: Same math as crash, different UI framing. The multiplier represents a target you need to hit rather than a crash point.
• Mines: The HMAC output seeds a Fisher-Yates shuffle of a 25-tile grid. The first N tiles in the shuffled array become mines. See our mines algorithm breakdown.
• Plinko: Each bit of the hash output determines a left or right bounce at each pin row. A 16-row plinko game consumes 16 bits (2 hex characters) per ball drop.

Common Mistakes (and How to Avoid Them)

When Verification Fails -- What to Do

How Often Should You Verify?

You don't need to verify every single bet -- but you should verify enough to establish a pattern. A reasonable approach:

• Verify several rounds when you first start playing at a new casino
• Spot-check after any round where the result felt "off" (even though feelings aren't evidence, checking builds trust)
• Verify at least once per seed rotation to make sure the commitment scheme is working
• Always verify if you experience an unusually long losing streak that you want to investigate

The power of provably fair isn't that you verify every round -- it's that you can verify any round, at any time, and the casino knows this. That accountability mechanism is what keeps the system honest.