“Provably Fair” is the most important trust claim in crash gambling — and also the most misunderstood. Many players see the label and assume the game is fair without ever checking. Others want to verify but don’t know where to start. This guide fixes that: it explains what provably fair actually proves (and what it doesn’t), and walks you through verifying crash game results step by step using free tools.
If you want the theory behind how crash points are generated, read our algorithm explainer first. This page is purely practical — it’s about checking results after they happen.
What “Provably Fair” Actually Proves (and What It Doesn’t)
Provably fair verification answers exactly one question: was the crash point determined before bets were placed, and was it left unchanged? If verification passes, you know the casino didn’t manipulate the result after seeing your bet.
What provably fair does not tell you:
It doesn’t tell you the RTP. A game can be provably fair and still have a 5% house edge. The house edge is built into the formula (e.g., using 99 instead of 100 in Bustabit’s formula creates 1% edge; using 97 would create 3%). Provably fair guarantees process integrity, not favorable odds. Always check the RTP separately.
It doesn’t tell you the game is “beatable.” Verification proves randomness and pre-commitment. The odds are still against you by exactly the house edge.
It doesn’t cover the whole system. Provably fair verifies crash point generation, not deposits, withdrawals, or other platform operations.
The Building Blocks: Seeds, Hashes, and HMAC
Before diving into verification steps, you need to understand four concepts:
Server Seed
A random string generated by the casino before each round (or pre-generated as a hash chain). This is the primary input that determines the crash point. Before the round, you see only its hash — not the seed itself. After the round, the actual seed is revealed so you can verify.
Client Seed
A string contributed by the player (or, in some games, derived from an independent source like a Bitcoin block hash). The client seed ensures the casino alone cannot determine the outcome — it needs your input too. Many platforms let you set a custom client seed before playing.
SHA-256 Hash
SHA-256 is a cryptographic one-way function. It takes any input and produces a fixed 64-character hexadecimal string. The same input always produces the same output, but you cannot reverse the process — given a hash, you cannot determine the input. This is what allows the casino to commit to a result without revealing it.
HMAC-SHA256
HMAC (Hash-based Message Authentication Code) combines two inputs using SHA-256. In crash games, it typically combines the server seed with the client seed to produce a final hash from which the crash point is calculated. The key difference from plain SHA-256 is that HMAC requires both inputs — neither party alone can predict the output.
Universal Verification: 3 Steps That Work for Any Crash Game
Regardless of the platform, verification follows the same logical structure:
Step 1: Confirm the server seed wasn’t changed
After the round ends, the platform reveals the server seed. Take this seed and hash it with SHA-256 using any free online tool (search “SHA-256 generator”). Compare your result to the hashed server seed that was shown to you before the round. If they match, the seed was not altered after your bet was placed.
Step 2: Recalculate the crash point
Using the revealed server seed, the client seed, and the game’s published formula, recalculate the crash point yourself. Every provably fair platform publishes its formula — usually in a “Provably Fair” settings page or documentation. The formulas differ between platforms, but the process is always: combine seeds → hash → extract number → apply formula.
Step 3: Compare your result to the official result
If your calculated crash point matches the platform’s reported result, the round was fair. If it doesn’t match, something is wrong with either the platform’s implementation or your inputs.
Now let’s see how this works on specific platforms.
How to Verify: Bustabit (Hash Chain System)
Bustabit uses a pre-generated chain of 10 million SHA-256 hashes. The chain is created by starting with a secret seed and repeatedly hashing the output. Games use the chain in reverse — game #1 uses hash #10,000,000, game #2 uses hash #9,999,999, and so on.
What you need
The game hash (shown after each round), the client seed (published during the seeding event on BitcoinTalk), and the terminal hash of the chain (publicly committed).
Verification process
1. Verify the hash belongs to the chain. Take the game hash and apply SHA-256 to it. The result should equal the hash of the previous game. Repeat this for any number of games to confirm the chain is intact. You can verify all the way to the published terminal hash.
2. Calculate the crash point. The formula (simplified from the open-source code):
hmac = HMAC_SHA256(key=clientSeed, message=gameHash)
r = parseInt(hmac.slice(0, 13), 16) // 52 bits
X = r / 2^52
result = Math.max(1, Math.floor(99 / (1 – X)) / 100)
// Also: 1-in-101 chance of instant bust (divisibility check)
3. Compare. If your calculated result matches the displayed crash point, the round was fair. Bustabit also provides a StackBlitz verification tool directly on the site.
How to Verify: Stake Crash
Stake uses a server seed + client seed + nonce system. Each bet increments the nonce, creating a unique input for every round without changing the seed pair.
What you need
Access Stake’s “Provably Fair” settings (click the shield icon in any game). You’ll find: the hashed server seed (shown before), the revealed server seed (shown after you rotate seeds), your client seed, and the nonce for each bet.
Verification process
1. Verify the server seed hash. Take the revealed server seed, hash it with SHA-256, and compare to the hash you were shown before playing. They must match.
2. Calculate the crash point. Stake’s formula:
hmac = HMAC_SHA256(key=serverSeed, message=clientSeed:nonce:0)
int = parseInt(hmac.slice(0, 8), 16) // first 4 bytes, 32-bit int
crashpoint = Math.max(1, (2^32 / (int + 1)) * (1 – 0.01))
// The 0.01 is the 1% house edge
3. Compare. Stake provides a built-in verification page where you can input the seeds and see the calculation. You can also replicate this independently with Node.js or any HMAC-SHA256 tool.
How to Verify: Aviator (Spribe)
Aviator by Spribe uses a more complex system that involves multiple players in seed generation. The hash function is SHA-512 (not SHA-256), and the combined seed includes three client seeds from the first three bettors in each round.
What you need
In Aviator’s game history, click on any round to see the server seed and the three client seeds. The hash of the combined seeds is also shown.
Verification process
1. Combine the seeds. Concatenate the server seed and three client seeds (the exact order is specified in Aviator’s documentation).
2. Hash with SHA-512. Use an online SHA-512 tool (search “SHA-512 generator”). Input the combined seed string.
3. Compare the hash. If your SHA-512 output matches the hash shown in the game history, the result was pre-determined from those seeds.
4. Calculate the multiplier. Aviator’s multiplier derivation from the hash follows Spribe’s published formula, which extracts specific bytes and applies the house edge factor. The exact implementation is in Aviator’s provably fair documentation.
Aviator’s multi-player seed system adds a layer of trust: because the client seeds come from real players who bet in that round, neither the casino nor any single player can predict the combined hash.
Free Verification Tools
| Tool Type | What It Does | Where to Find |
|---|---|---|
| SHA-256 Generator | Hashes any input string — use to verify server seed commitment | Search “SHA-256 online” — any tool works |
| SHA-512 Generator | Required for Aviator (Spribe) verification | Search “SHA-512 online” |
| HMAC-SHA256 Calculator | Combines server seed + client seed — use to recalculate crash point | Search “HMAC-SHA256 online” |
| Hex to Decimal Converter | Converts hash substrings to numbers for formula calculation | Search “hex to decimal converter” |
| Node.js / Python | Run the full verification script locally for complete independence | Built-in crypto libraries (no install needed) |
| Platform Built-in Verifiers | Pre-built tools on the casino site — convenient but not independent | Bustabit: StackBlitz. Stake: Provably Fair page. BC.Game: Fairness menu. |
Important: Platform built-in verifiers are convenient but not fully independent — you’re trusting the platform’s code to verify its own results. For maximum trust, use an external SHA-256/HMAC tool or run the verification script locally.
Provably Fair Systems Compared: Hash Chain vs. Seed-Per-Round
| Feature | Hash Chain (Bustabit, CSGORoll) | Seed + Nonce (Stake, BC.Game) | Multi-Player Seeds (Aviator) |
|---|---|---|---|
| Hash Function | HMAC-SHA256 | HMAC-SHA256 | SHA-512 |
| Pre-commitment | 10M hashes in advance | Server seed hashed before round | Server seed hashed before round |
| Client Input | Seeding event (Bitcoin block) | Player-set client seed | 3 player seeds per round |
| When Seeds Rotate | Never (chain is fixed) | Manual rotation by player | Every round (new players) |
| Verification Difficulty | Easy (chain is linear) | Easy (single formula) | Moderate (4 seeds + SHA-512) |
| Open-Source Code | Yes (Bustabit on GitHub) | Published (Stake docs) | Partial |
| Future Results Pre-exist | Yes (all 10M) | No (generated per round) | No (generated per round) |
The hash chain approach (used by Bustabit) is arguably the strongest because all future results already exist before any game is played. The seed-per-round approach (Stake, BC.Game) is easier for players to interact with since you can set your own client seed. Aviator’s multi-player seed approach adds trust by distributing seed generation across multiple independent parties.
Red Flags: When Provably Fair Claims Are Suspicious
Not every game that claims “provably fair” actually implements it correctly. Watch for these warning signs:
No published formula. If the platform says “provably fair” but doesn’t publish the exact algorithm for converting seeds to crash points, you can’t verify anything. The label is meaningless without the math.
Server seed not shown before the round. The core of provably fair is pre-commitment: you must see the hashed server seed before placing your bet. If seeds are only revealed after, the system doesn’t prove anything.
No client seed input. Without a player-side input, the casino alone determines the result. Provably fair requires that both parties contribute to the outcome.
Built-in verifier only. If the platform provides a verification tool but doesn’t publish the code for independent checking, you’re trusting them to verify themselves.
“Provably fair” on non-original games. Third-party provider games running on regular casinos use the provider’s RNG. Check whether the provider (not the casino) offers verification. Games from aggregated providers may use certified RNG rather than provably fair systems — both are valid but work differently.
Provably Fair vs. Certified RNG: Both Are Valid
Not all crash games are provably fair, and that’s not automatically a problem. Many provider-built games (like Aviator at mainstream casinos, JetX, Spaceman) use certified RNG systems audited by third-party labs like iTechLabs, GLI, or BMM Testlabs.
| Aspect | Provably Fair | Certified RNG |
|---|---|---|
| Who verifies? | You (the player) | Independent testing lab |
| When? | Every round, in real time | Periodic audits |
| Trust model | Cryptographic proof | Third-party authority |
| Player skill needed | Some (hashing, basic code) | None |
| Common in | Crypto casinos, originals | Licensed casinos, provider games |
Neither system is inherently better. Provably fair gives you direct verification but requires technical ability. Certified RNG relies on trusting the auditor but covers more complex games and is standard in regulated jurisdictions. The worst case is a game with neither — no published verification and no regulatory audit.
Related Guides & Tools
- Crash Game Algorithm Explained — how crash points are generated from hashes
- Provably Fair Explained — theory and concepts in depth
- Crash Game Odds — probability tables for every multiplier
- Crash Game RTP Comparison — house edge for 18+ games
- Bustabit Review — open-source crash game with the strongest verification
- Aviator Review — multi-player seed verification explained
- Stake Crash Games — seed + nonce system
- BC.Game Crash Review — provably fair with custom scripts
- Crash Game Software — which providers use provably fair vs certified RNG