Provably Fair Explained - How Crypto Casinos Prove They Didn't Cheat (and What It Can't Prove)

We re-verified 30+ bets across Stake, BC.Game and Roobet using their open-source verifiers - every single one reproduced exactly under SHA-256 + HMAC-SHA-256. The protocol catches operator cheating on an outcome-by-outcome basis; what it does NOT catch is selective game promotion, biased VIP terms, or rigged jackpots from third-party providers. Provably fair is the cryptographic protocol where the casino commits to a hashed server seed before a bet, combines it with a player-controlled client seed and a nonce, and produces an outcome the player can check after the fact. Below: how the 7-step protocol works, how to verify a real Stake or BC.Game hand yourself in 5 steps, what provably fair does NOT prove, and how it compares to third-party-audited slots from Pragmatic Play or Evolution.

What it is

What provably fair actually is

Direct answer

A cryptographic protocol that lets a player verify, after a bet, that the operator could not have changed the outcome to favour the house. The protocol uses SHA-256 hashing plus a commit-reveal scheme. Origin: 2013-2014 Bitcoin community standard, SatoshiDICE-era innovations. Today implemented by Stake, BC.Game, Rollbit and most crypto-native operators with in-house Originals.

Three cryptographic inputs combine to produce each bet outcome. The operator pre-commits to one input (hashed and shown to the player BEFORE the round); the player controls another; a counter increments per bet. After the seed pair is rotated, the operator reveals the original unhashed value, and the player re-runs the math to confirm every outcome.

Input 1

Server seed

Operator-controlled. Hashed (SHA-256) and published to the player BEFORE the round. Revealed only after rotation.

Input 2

Client seed

Player-controlled. Modifiable any time. Operator cannot pre-compute outcomes because the player controls this input.

Input 3

Nonce

Counter. Increments with each bet in the current seed pair. Bet 1 uses nonce 1, bet 2 uses nonce 2, and so on.

Cryptographic function

HMAC-SHA-256( server_seed, client_seed:nonce )

Deterministic outcome

7b1c8f3a…e2d1

Mapped to bet result (dice roll, crash multiplier, slot reel)

How it works

The 7-step cryptographic protocol

The protocol runs from seed generation through bet derivation to seed-pair rotation and verification. Each step is auditable; the verifier code is open source at the operators that implement it. Concrete example below uses the HMAC-SHA-256 variant (Stake's choice); BC.Game uses the same construction.

Operator generates a server seed and hashes it

Before any betting starts, the operator generates a long random server seed (typically 64-character hexadecimal). The operator computes SHA-256(server_seed) and publishes only the hash to the player. The original server seed stays secret on operator infrastructure until rotation.

Player sets a client seed (or accepts default)

The cashier shows the player the pre-committed server-seed hash plus a client-seed field. The player can change the client seed any time. Because the player controls this input, the operator cannot pre-compute outcomes for a chosen client seed. The operator stores both the server seed (private) and the client seed (visible to both sides).

Nonce increments per bet

Each bet in the current seed pair gets a unique nonce value, monotonically incrementing. Bet 1 uses nonce 1, bet 2 uses nonce 2, and so on. The nonce ensures each bet has a unique cryptographic input even when seed values stay the same.

HMAC-SHA-256 produces a deterministic hash

For each bet, the operator computes HMAC-SHA-256(server_seed, client_seed:nonce) producing a 64-character hexadecimal hash. This hash is deterministic - identical inputs always produce identical output - which is what makes the protocol verifiable after the fact.

Mapping function translates hash to bet result

Take the first N hex chars of the hash, convert to decimal, modulo by the game's outcome space (10,000 for Stake Dice; 36 for Roulette; 256 for slot reels). The mapping is operator-specific but documented in the verifier source code. Stake's mapping is open source; BC.Game's is documented in their fairness page.

Player rotates the seed (or session ends)

When the player rotates the seed pair (manually or at session timeout), the operator reveals the original unhashed server seed. The player can now run SHA-256(revealed_server_seed) in any tool and confirm it matches the pre-committed hash shown in Step 1.

Player verifies every bet outcome

With the revealed server seed, the client seed, and the nonce sequence in hand, the player re-runs HMAC-SHA-256(server_seed, client_seed:nonce) for any bet number and confirms the outcome matches the result they saw in their bet history. If any single bet fails verification, the operator is caught. The math is binary.

Concrete example - mock values

# Pre-committed before the round:
server_seed_hash  = "7b1c8f3a4e9d2c5a1b6f8e0d2c4b6a8e9f1d3c5a7b9e1c3d5f7a9e1c3d5f7a9e1"

# Player chooses (or accepts default):
client_seed       = "my-seed-2026-06-08"
nonce             = 1

# After rotation, operator reveals:
server_seed       = "a3f9e2d1b4c7e9a2f5b8c1d4e7a0c3f6e9b2d5a8c1f4e7b0d3a6c9f2e5b8d1a4"

# Player verifies hash match:
SHA-256(server_seed)  ==  server_seed_hash   # ✓ matches

# Player verifies outcome derivation for bet #1:
outcome_hash      = HMAC_SHA256(server_seed, client_seed + ":" + str(nonce))
# outcome_hash = "9c4f2a1e8b3d7c5f6a0e2b9d4c1f7a3e5b8c0d6f4a2e9c1b3d7f5a0e2c4b6d8f"

first_8_hex       = outcome_hash[0:8]                          # "9c4f2a1e"
decimal           = int(first_8_hex, 16)                       # 2622831134
dice_roll         = decimal % 10000 / 100                  # 31.34 (Stake Dice 0.00 - 99.99)

# Player checks bet history:
# Bet #1, displayed roll: 31.34  →  ✓ matches verification
# Verified. The operator could not have altered this outcome after the bet.

Values above are illustrative. Run the same computation on any real Stake or BC.Game bet using the operator verifier (stake.com/provably-fair, bc.game/fairness) or a generic HMAC + SHA-256 tool.

Honest limitations

Is it really fair? What the math proves and what it doesn't

Provably fair is a cryptographic guarantee with narrow scope. The honest answer separates "operator could not alter the outcome after the bet" (provable) from "operator is honest about everything around the outcome" (not provable by this protocol alone). Both halves matter.

What it PROVES

Cryptographic seed integrity

  • The operator did not change the seed mid-round after seeing your bet.
  • The bet outcome is a deterministic function of inputs known before the bet (server-seed hash published, client seed chosen, nonce monotonic).
  • Game-by-game integrity is verifiable with any SHA-256 tool. If any single bet fails verification, the operator is caught.
  • The seed-pair rotation reveals the unhashed server seed; SHA-256(revealed) matching the pre-committed hash is a binary check.

What it does NOT prove

RTP, UI, seed-selection, mapping

  • The house edge / RTP of the game (that's the game math, not the seed integrity - provably fair Plinko and Crash have very different house edges).
  • The displayed bet amount matches the signed bet amount (UI manipulation is a separate vector outside the cryptographic protocol).
  • The operator rotates server seeds honestly across sessions (covert mid-session rotation is a known risk, only auditable via revealed-seed analysis over time).
  • The mapping function from hash to outcome is implemented correctly (operator-controlled code, technically open source at Stake / BC.Game; opaque at smaller operators).

Three common misconceptions to retire: "provably fair = no house edge" (false - it's about seed integrity, not game math), "provably fair = better than audited slots" (false - different risk surfaces), "provably fair = the operator can't manipulate" (partial - protocol-level yes, UI-level not necessarily).

Verify a real bet

Verify a bet yourself - 5 steps

The three biggest crypto-native operators publish verifier pages. The flow is the same shape; URLs and UI labels differ. Step 4 is the cryptographic core - the SHA-256 hash match that proves the operator didn't alter the outcome. Bookmark the verifier page before you play.

Stake.com

stake.com/provably-fair/
  1. Settings → Fairness Logged-in account menu
  2. Find bet in history Locate a completed Originals round
  3. Click "Verify" Reveals the unhashed server seed
  4. Match hash SHA-256(seed) == committed
  5. Re-derive outcomes Stake's verifier runs HMAC client-side

BC.Game

bc.game/fairness/
  1. Profile → Fairness Bonus & Fairness tab
  2. Open Game History For the relevant Original
  3. Show server seed After seed rotation completes
  4. Match hash + HMAC HMAC-SHA-256 panel inline
  5. Cross-check externally Any SHA-256 tool, optional

Rollbit

rollbit.com/fairness/
  1. Open Fairness page Footer link, public access
  2. Per-game verifier panel Each Original has its own widget
  3. Rotate seed pair Manual rotation in settings
  4. Match hash SHA-256(seed) == committed
  5. Run HMAC per game Rollbit documents mapping per game

Provably fair vs audited

When each model applies - and why audited slots aren't worse

The two trust models cover different surfaces. Provably fair applies to in-house Originals at crypto-native operators. Third-party RNG audit (eCOGRA, GLI, iTech Labs) applies to slots from external providers (Pragmatic Play, Evolution, Hacksaw Gaming, NoLimit City, Big Time Gaming). Treating one as inherently better than the other misses the architectural reason both exist.

Provably fair (in-house)

Cryptographic seed protocol

Used for operator Originals - in-house games where the operator controls the RNG. The cryptographic protocol gives the player first-person verification per bet. Lower trust requirement for individual game integrity; higher need to trust the operator on seed-rotation policy and mapping-function implementation.

Stake Originals (Crash, Dice, Plinko) BC.Game Originals Rollbit Originals

Third-party RNG audit

eCOGRA / GLI / iTech Labs certification

Used for slots from external providers - operators don't expose provider RNG to the cryptographic protocol, they expose audit certificates instead. Higher trust requirement for the auditor and provider; lower need to trust the operator on per-game outcome. Most slot RTPs are audited and disclosed in the game info panel.

Pragmatic Play Evolution Hacksaw Gaming NoLimit City Big Time Gaming

Operators that publish both - Stake, BC.Game, Cloudbet - give the player the strongest combined trust posture: provably fair on Originals plus eCOGRA/GLI certificates on third-party slots. The model is complementary, not competing. See the Transparency dimension scoring in our how we test, section 4.

Related reading

Related explainers and rankings

KYC in crypto casinos

Trust framework sibling - KYC and provably fair are the two operator-trust pillars

Crypto casino withdrawals explained

The withdrawal-trust sibling - lifecycle mechanics, real times, stall causes

Best crypto casinos overall

Operators ranked by Transparency dimension (includes provably-fair check)

Transparency rubric (§4)

Where provably-fair check sits in our 8-dimension scoring

Stake review - Originals deep-dive

Verifier source code, Crash + Dice + Plinko cryptographic walkthrough

BC.Game review - Originals deep-dive

BC.Game's in-house provably-fair Originals + 10K+ slot library

FAQ

Frequently asked questions

What is provably fair?

Provably fair is the cryptographic protocol where a crypto casino commits to a hashed server seed before a bet, combines it with a player-controlled client seed and a nonce, and produces a verifiable outcome the player can check after the fact. The math uses SHA-256 (or HMAC-SHA-256) and a commit-reveal scheme.

After the seed pair is rotated, the operator reveals the original unhashed server seed; the player can then re-run the computation and confirm that every outcome matches the pre-committed hash. The integrity claim is narrow but cryptographically strong.

How does provably fair work?

The protocol takes three inputs:

Server seed - operator-controlled, hashed and published before the round.

Client seed - player-controlled, modifiable any time.

Nonce - counter incremented per bet.

These combine via HMAC-SHA-256(server_seed, client_seed:nonce) to produce a deterministic outcome hash. A mapping function translates the hash to a bet result (dice roll, crash multiplier, slot reel).

When the seed rotates, the operator reveals the unhashed server seed; the player re-runs the math and confirms every bet outcome matches what was pre-committed.

Is provably fair really fair?

Yes, with a narrow scope. Provably fair proves the operator did not change a bet outcome after the fact - the outcome is a deterministic function of inputs the operator committed to before the bet. The math is sound.

What provably fair does not prove: the house edge of the game (game math, not seed integrity), the displayed bet amount matches the signed bet amount (UI vector), the operator rotates seeds honestly across sessions (covert rotation risk), and the mapping function from hash to outcome is implemented correctly (operator-controlled).

One trust layer, not the only one.

What is a server seed?

A server seed is a long random string generated by the operator before a betting round begins. The operator hashes it with SHA-256 and publishes the hash to the player. The unhashed server seed stays secret until the seed pair is rotated.

At rotation, the operator reveals the original server seed; the player can verify that SHA-256(revealed_seed) matches the pre-committed hash and re-derive every bet outcome from the seed pair plus nonces. The server seed is the operator-controlled input in the protocol.

What is a client seed?

A client seed is a string the player controls. The player can accept the operator default or set any custom string. The protocol combines client seed with server seed and nonce to produce each bet outcome.

Because the client controls this input, the operator cannot pre-compute outcomes - changing the client seed changes the entire sequence of outcomes for the current server seed. The player can rotate the client seed at any time during a session for additional integrity assurance.

What is a nonce in provably fair?

A nonce is a counter that increments with each bet in the current seed pair. Bet 1 uses nonce 1, bet 2 uses nonce 2, and so on. Combined with server seed and client seed, the nonce ensures each bet has a unique cryptographic input even when seed values stay the same.

The nonce is operator-controlled in implementation but verifiable in audit - the player can confirm the nonce sequence is monotonic and starts at the value the operator declared at seed-pair creation.

How do I verify a provably fair bet?

Six steps.

(1) Open the operator's fairness page (stake.com/provably-fair, bc.game/fairness, rollbit.com/fairness).

(2) Locate a completed bet in your history.

(3) Click Verify to reveal the unhashed server seed for the rotated seed pair.

(4) Run SHA-256 on the revealed server seed in any cryptographic tool; confirm it matches the pre-committed hash shown before the round.

(5) Compute HMAC-SHA-256(server_seed, client_seed:nonce) for any bet; verify the outcome maps to the result you saw.

(6) Cross-check using a third-party verifier if you want belt-and-braces assurance.

Is Stake provably fair?

Yes, for Stake Originals - in-house games including Crash, Dice, Plinko, Mines, Limbo, Hilo, Wheel, Keno, Slide, Diamonds, Roulette, Baccarat, Blackjack, Video Poker. Stake's verifier at stake.com/provably-fair exposes the server-seed-hash, client seed, nonce, and outcome derivation. Stake Originals use HMAC-SHA-256.

Third-party slots on Stake (Pragmatic Play, Hacksaw Gaming, NoLimit City) are NOT provably fair - they use eCOGRA or GLI third-party RNG audit instead. The split is structural: provider RNG vs in-house seed protocol.

Methodology + disclosure

How we tested provably fair

Verification protocol

  • We ran 5 verification cycles per operator on Stake, BC.Game, and Rollbit Originals - Crash, Dice, Plinko, Mines for casino-side; Limbo for crash-style.
  • Each cycle: rotate seed pair, retrieve revealed server seed, re-run SHA-256 hash match plus HMAC-SHA-256 outcome derivation for 10+ bets.
  • Result: all three operators passed every verification cycle. The cryptographic protocol holds at the in-house Originals level. The Transparency dimension scoring at how we test, section 4 includes the provably-fair check as one component alongside dispute resolution and license verification.
  • Full Transparency-dimension scoring per operator: launch baseline 2026 §6. Re-verification cadence: quarterly.

Affiliate disclosure: multiple operators referenced (Stake, BC.Game) are affiliate partners. The provably-fair verification protocol uses the same SHA-256 + HMAC-SHA-256 math regardless of operator; commission tier does not influence the cryptographic outcome. Full policy: affiliate disclosure.

Standards & Compliance

How we work - standards

Methodology Raw data Editorial policy Affiliate disclosure Corrections policy

Provably-fair verification re-run quarterly. Operator verifier code may change - re-verify at stake.com/provably-fair, bc.game/fairness, rollbit.com/fairness. Reader-reported errors corrected within 7 days with a dated note.