Provably Fair: How to Verify Every Hand

Every time a crypto casino shows a "Provably Fair" badge, it is making a specific mathematical claim. Most players never check it. They treat the badge like a security sticker on a car window: reassuring, but never tested. That is a mistake. Verifying a hand takes a few minutes once you understand the moving parts. Doing it teaches you exactly what the system protects you from and what it doesn't.

This guide gives you a full audit protocol for Stake Originals Blackjack and similar crypto blackjack games. We will cover the cryptography (SHA-256 and HMAC-SHA256), the three inputs that determine every card, how a hash digest becomes a deck order, and a step-by-step routine you can run after any session. Then we draw a hard line between what Provably Fair proves and what it does not. A verified deck still carries a house edge, and no seed setting will change that.

Why "Trust Us" Isn't Good Enough

In a brick-and-mortar casino, you can watch the shuffle. You see the discard tray, the cut card and the dealer's hands. Cheating is possible, but it is physically constrained and observable. Online RNG blackjack removes all of that. The server decides which card comes next, and historically you had no way to know whether that decision happened before or after the software saw your $500 double down.

Traditional online casinos answer this with third-party lab certifications. Those certifications are useful. If you want the full comparison of trust models, read our RNG vs Live Dealer overview. But a lab report is a statement about the software at the time it was tested. It is not proof about the specific hand you just lost.

Provably Fair flips the burden. The casino commits to its randomness before you act. You then get the tools to check, hand by hand, that the commitment was honored.

The Three Inputs: Server Seed, Client Seed, Nonce

Every card dealt in a Provably Fair blackjack round comes from exactly three inputs. If you know all three and the published algorithm, you can reproduce the deal with perfect accuracy on your own computer.

1. The Server Seed

The server seed is a 64-character hexadecimal string, which equals 256 bits of randomness. The casino generates it with a cryptographically secure random number generator. Before you place a single bet, the casino runs that seed through SHA-256 and shows you only the resulting hash. This is the commitment.

SHA-256 is a one-way function. You cannot work backward from the hash to the seed. The casino also cannot find a different seed that produces the same hash, because SHA-256 is collision-resistant. Once that hash is on your screen, the casino is locked in. It cannot swap the seed later without the mismatch being obvious the moment you check.

2. The Client Seed

The client seed is your contribution. Your browser generates it by default, or you can type any string you like: your dog's name, a random phrase, anything.

Here is the crucial point. You can set or change the client seed after the server has already committed its hashed seed. The casino therefore cannot pre-select a server seed designed to produce bad outcomes against your particular client seed. It simply doesn't know what you'll pick.

3. The Nonce

The nonce is an integer counter. It starts at 0 when a new seed pair becomes active and goes up by exactly 1 with every wager. Your first hand under a seed pair is nonce 0, the second is nonce 1, and so on.

The nonce is what makes each hand different even though the two seeds stay fixed. It also gives every hand you play a permanent, checkable address: server seed + client seed + nonce.

From Hash to Cards: How the Deal Is Built

Step One: HMAC-SHA256 Generates Raw Bytes

The game feeds the inputs into HMAC-SHA256. This is a keyed hash: the server seed acts as the secret key, and the message is a string built from your client seed, the nonce and a cursor:

HMAC-SHA256(server_seed, "client_seed:nonce:cursor")

Each call produces a 32-byte digest. A blackjack round may need more random numbers than one digest provides. When that happens, the cursor increments (0, 1, 2…) and a fresh 32-byte block is generated. This gives a long, deterministic stream of unpredictable bytes for every single hand.

Step Two: Bytes Become Floats in [0, 1)

The digest is split into 4-byte chunks, so each 32-byte block yields eight numbers. Each chunk is converted into a floating-point value between 0 (inclusive) and 1 (exclusive) using positional division:

float = b0/256 + b1/256² + b2/256³ + b3/256⁴

The first byte carries the most weight and the fourth the least. The result is a uniformly distributed number with roughly 32 bits of precision, more than enough to choose among 52 cards without measurable bias.

Step Three: Fisher-Yates Builds an Immutable Deck

In shuffle-based implementations, those floats drive a Fisher-Yates shuffle:

1. Start with an ordered array of cards indexed 0 through 51.
2. Walk from the last position down to the first.
3. At each position i, multiply the next float by (i + 1) and take the floor. This gives a swap index j between 0 and i.
4. Swap card i with card j.

Fisher-Yates is the gold standard because it produces every one of the 52! possible deck orders with equal probability, provided the input randomness is uniform. Once the floats are fixed, the permutation is fixed. The deck that comes out is tamper-proof in the strict sense: change one bit of any input and you get a completely different deck. Keep every input the same and you get the identical deck every time, on any machine, forever.

The Audit Protocol: Verifying a Hand Step by Step

Here is the routine I use and teach. It works for any hand you've played, whether it was a routine loss or a dealer six-card 21 that made you suspicious.

Step 1: Rotate the Server Seed to Reveal the Secret

While a seed pair is active, the server seed stays hidden. It has to, because revealing it would let you predict every upcoming hand. To audit, open Stake's Fairness settings and rotate (change) the seed pair. At that moment the casino retires the old server seed and reveals it in plain text. It then commits a fresh hashed seed for your future play.

Before rotating, write down three things for the hand you want to check:

• the hashed server seed you were shown during the session,
• your client seed,
• the nonce of the hand in question, which is listed in your bet history.

Step 2: Verify the Commitment

Take the revealed server seed and compute its SHA-256 hash yourself. Use a local tool, not the casino's own page. On most systems, a single terminal command does it. In Python it is one line: hashlib.sha256(seed.encode()).hexdigest().

Compare your result character by character against the pre-commitment hash you recorded. If they match, the seed that generated your cards is provably the same one the casino locked in before you bet. If they don't match, stop playing and escalate. That is the one scenario Provably Fair exists to expose.

Step 3: Reproduce the Deal Independently

Now regenerate the cards. Use an independent, open-source script that you can read line by line. Here is a minimal Python verifier covering both the shuffle model and the independent-draw model:

import hmac, hashlib

def float_stream(server_seed, client_seed, nonce, count):
    out, cursor = [], 0
    while len(out) < count:
        msg = f"{client_seed}:{nonce}:{cursor}".encode()
        digest = hmac.new(server_seed.encode(), msg, hashlib.sha256).digest()
        for i in range(0, 32, 4):
            b = digest[i:i+4]
            out.append(b[0]/256 + b[1]/256**2 + b[2]/256**3 + b[3]/256**4)
            if len(out) == count:
                break
        cursor += 1
    return out

def fisher_yates_deck(server_seed, client_seed, nonce):
    deck = list(range(52))
    floats = float_stream(server_seed, client_seed, nonce, 51)
    for k, i in enumerate(range(51, 0, -1)):
        j = int(floats[k] * (i + 1))
        deck[i], deck[j] = deck[j], deck[i]
    return deck

def independent_draws(server_seed, client_seed, nonce, n_cards=52):
    return [int(f * 52) for f in float_stream(server_seed, client_seed, nonce, n_cards)]

Map the resulting indexes to ranks and suits using the card table published on the operator's fairness page. Then compare the first several cards to your hand history: your first card, the dealer's upcard, your second card, the dealer's hole card, then hits in order of play.

If the sequence matches, the hand was dealt exactly as committed. Your decisions changed which cards you received, but they never changed the order of cards waiting in the stream.

What Provably Fair Proves, and What It Does NOT

This is where most players get it wrong, in both directions. Some think Provably Fair means "the game can't be beaten by the house." Others assume it's marketing fluff. The truth is precise:

On seed generation quality, the commitment proves the casino didn't switch seeds. Whether its seed generator draws from a properly seeded CSPRNG is a separate question. That is covered in the cryptographic PRNG entropy analysis on BlackjackMath.org.

On counting, every hand is generated fresh from a new nonce, so there is no depleting shoe to track. Our card counting online reality check explains why this kills traditional advantage play online.

The House Edge Is Still Encoded in the Rules

Let me be blunt: a perfectly fair shuffle of an unfavorable game is still an unfavorable game. Provably Fair guarantees the deck is random. The house edge comes from the rules: the dealer acts last, you bust first, and the payout structure is fixed.

Stake Originals Blackjack carries roughly a 0.57% house edge against perfect basic strategy. That figure comes from its rule set: the dealer stands on soft 17, blackjack pays 3:2, there is no surrender, and the deck model is effectively infinite.

Here's how individual rules shift the edge. These are approximate figures against a standard multi-deck baseline:

Want to see exactly how deck count and individual rules compound? Work through the single-deck rule house edge calculation on BlackjackMath.org. The derivations live there, and you don't need to redo them to act on the conclusions.

The payout row matters most. A cryptographically perfect 6:5 game is worse than a sloppy-looking 3:2 game, every single time. Our 3:2 vs 6:5 payout guide shows the dollar damage. You can also plug any game's rule set into our Table Grader tool to grade it before you play.

Debunking the Seed Myths

Myth: "Changing my client seed resets bad luck."

It doesn't. Every seed pair produces a stream of outcomes with identical statistical properties. Switching client seeds swaps one unpredictable sequence for another, equally unpredictable one. The expected value per hand is identical before and after.

Rotating seeds is good practice for auditing, because it reveals the old server seed. It has zero effect on your expected results. Losing streaks are variance, and variance doesn't care what your seed is named.

Myth: "When I bet big, the cards turn against me."

Look at the inputs again: server seed, client seed, nonce. Bet size isn't one of them. The cards for nonce 47 were fixed the moment the server hash was committed and your client seed was set, long before you decided to bet $10 or $1,000.

If you remember a brutal hand on a big bet, verify it. You will find the cards match the commitment exactly. What you're experiencing is memory bias. Big losses are memorable; big wins feel deserved.

Myth: "If I find a pattern in past hands, I can predict the next ones."

HMAC-SHA256 output is computationally indistinguishable from random without the key. Patterns you spot in past hands are noise. Predicting future hands would require the unrevealed server seed, and that would mean breaking SHA-256.

A Practical Session Routine

Here is the checklist I use on any Provably Fair blackjack platform:

1. Before playing: Check the rules panel. You want 3:2, S17, and doubling and splitting options. Grade the game with our Table Grader tool. Note that a fair shuffle doesn't fix bad rules.
2. Seed setup: Rotate to a fresh pair. Screenshot the new hashed server seed, then set your own random client seed.
3. During play: Use perfect basic strategy for the game's rules. Ignore seed superstitions and size bets by bankroll, not by "feel."
4. After the session: Rotate seeds to reveal the old server seed. Verify its SHA-256 hash against your screenshot, then spot-check a few hands with your local script. Prioritize the large or suspicious ones.
5. Keep records: Save the seeds and nonces in a simple spreadsheet. If a dispute ever arises, you'll have cryptographic evidence, not just a complaint.

Choosing where to play involves more than cryptography: rules, limits, licensing and withdrawal track record all count. Our Casinos comparison hub (1win & Stake) breaks those factors down side by side.