"Provably fair" is one of those phrases that gets used in marketing copy to mean "trust us". It's actually something more specific and stronger: a cryptographic protocol that lets you, the player, verify that a Crash round's outcome was determined before the round started, by a seed the operator committed to in advance. If the implementation is correct and you do the verification, the operator literally cannot rig a specific round against you after the fact.
This guide explains the protocol, walks through a concrete verification you can run yourself, and is honest about what provably-fair does not protect against (the house edge is still there).
The trust problem provably-fair solves
On a non-provably-fair casino, the game outcome is computed on the operator's servers. They run the RNG, they decide the result, they tell you what happened. You either trust them or you don't. The regulator's license is the only check on their behaviour — and regulators audit periodically, not in real-time.
For Crash specifically, this matters because Crash payouts are unbounded in principle. A regulator can audit average payout across thousands of rounds. They can't easily catch an operator that biases specific high-stake rounds to bust early. Provably-fair closes that gap by making per-round outcomes verifiable cryptographically.
The three inputs
Server seed
A long random string (typically 256 bits, displayed as a 64-character hex string) generated by the operator. The operator publishes the hash of this seed before any rounds are played, then keeps the seed itself secret while the seed is in active use.
Crucially, because SHA-256 is cryptographically secure, the operator can't change the server seed after publishing the hash. If they reveal a seed later that doesn't hash to the committed value, you know they cheated. This is what "commitment" means in cryptography.
Client seed
A string supplied by the player. On Stake-style implementations you can rotate it any time; doing so starts a new chain of nonces against the same server seed (or, depending on the operator's scheme, against a freshly committed one). The client seed is the player's input to the randomness.
Why does this matter? Without a client seed, the operator could in principle pre-compute results for a specific server seed and choose which seed to use against which player. Letting the player contribute a seed makes that attack impossible: the operator publishes the server seed hash beforeseeing the client seed, so they can't select a server seed that produces favourable outcomes for the client seed they're about to receive.
Nonce
A counter that starts at zero (or one) and increments by one with each round. Each combination of (server seed, client seed, nonce) produces exactly one output. Replaying the same nonce on the same seeds produces the same result, which is what makes verification possible.
How a Crash multiplier is derived
The standard implementation, used by Stake among others, is roughly:
- Compute
HMAC-SHA256(server_seed, client_seed:nonce:cursor), producing a 64-character hex string (32 bytes). - Take the first 4 bytes (8 hex chars) and convert them to a 32-bit integer
n. - Apply a deterministic transformation to
nto derive the crash multiplier. The exact formula varies by operator — Stake's public Crash implementation uses a well-documented function that produces multipliers between 1.00× and theoretically unbounded, with a small tail that busts at exactly 1.00× to maintain the house edge. - If the round's output isn't in the valid range (very rare), increment the cursor and re-hash. This is why the "cursor" appears in some implementations.
The exact formula matters only if you want to reproduce results. The verifiable property doesn't depend on the formula — only on the inputs being committed in advance and the function being deterministic.
The verification step
Here's what you actually do after a session to verify the rounds you played. The flow on a typical Stake-style implementation:
- Open the "Provably Fair" section in the game UI. You'll see your current server seed's hash, your client seed, and the current nonce.
- Rotate the server seed. This action triggers the operator to commit a new server seed (publishing its hash) and reveal the previous one.
- Copy the revealed server seed from the "Previous Seeds" section.
- Hash it yourself using any SHA-256 calculator. Compare the result to the hash you saw in step 1. They must match exactly.
- For any specific round you want to verify, take the server seed, the client seed in use at that time, and the round's nonce, then run them through the operator's published HMAC-SHA256-based formula. The output should equal the multiplier you saw on screen.
Most major operators publish a verification page or a small open-source script for step 5. Stake's is at stake.com/provably-fair/implementation. Roobet, BC.Game and other crypto crashes have similar pages. Third-party verifiers also exist — they take the seeds and nonce, run the standard formula, and tell you the expected multiplier.
What provably-fair doesn't protect against
The house edge
Crash games typically run a 1–3% house edge. The standard implementation achieves this by reserving a small percentage of the output space for "instant bust at 1.00×" — a fraction (often 1/33 ≈ 3%) of valid hash outputs map to a crash at exactly the starting multiplier. This is part of the verifiable formula, not a side channel. You can verify it's applied uniformly. You can't make it go away.
The honest framing: provably-fair guarantees the operator runs the same fair-game process for every player and every round. It doesn't guarantee you'll win. The expected return of a Crash bet is still slightly negative — the math is just verifiable.
Operator manipulation outside the round
Provably-fair attests the round's outcome. It doesn't prove that the server seed was generated randomly in the first place — only that it wasn't changed after commitment. An operator that pre-generates 100 server seeds and hand-picks one based on something they observe (e.g. unusually large bets) could in principle bias outcomes without the protocol catching it. Mitigations: rotate seeds frequently, especially before large bets, and provide your own client seed (which the operator can't see in advance).
UX problems unrelated to the RNG
Provably-fair doesn't solve withheld payouts, KYC stalls, bonus T&Cs that void wins, or account closures. Those are regulatory issues — see the unpaid winnings playbook for what to do if you hit one.
Should you actually verify?
Honest answer: most players never do, and statistically they don't need to — the cryptographic guarantee works whether anyone checks or not, as long as the threat of someone checking exists. The operator can't selectively cheat because they can't identify in advance which player will verify.
That said, there are two situations where verification is worth the 30 seconds:
- After an unusual session. Lost 20 in a row at low multipliers, suspicious it might not be variance? Rotate the seed and run a quick batch verification. If the rounds check out (and they will, on any major operator), you can move on with confidence. If they don't, you have evidence for a regulator complaint.
- Before a large bet. Rotate the server seed first. The seed in use for your big bet is then a fresh commitment the operator just made — they couldn't have pre-selected it based on knowing you were about to bet large.
The wider context — how to compare crash implementations across operators, including provably-fair details — is in the Roobet Crash vs Stake Crash comparison. And the live multiplier history for both, side-by-side, is on /games/crash and /games/stake-crash.
