Provably Fair Crash Game Explained 2026 — The 1% House-Edge Math Behind Stake / BC.Game Crash
ⓘ This article contains affiliate links. We may earn a commission if you sign up — at no cost to you. See our full disclosure.
TL;DR — Provably fair crash in one paragraph
Crash games (Stake, BC.Game, Rollbit) display a multiplier that climbs from 1.00× and busts at a random point. You cash out before the bust to win at that multiplier; you lose if you don't cash out. The bust point is determined by the same cryptographic primitives as provably fair dice — SHA-256 commit on the server seed, HMAC-SHA-512 to compute the outcome, and a mapping function that translates the HMAC hex slice into a long-tail multiplier distribution. The 1% house edge is baked into the bust-at-1.00× probability — approximately 1 in 100 rounds bust immediately, which is the operator's margin.
Quick Answer — Is crash actually fair?
Yes, when the operator uses the canonical commit-reveal protocol. The server seed hash is published before each round, and the revealed seed (after rotation) verifies the hash. The HMAC-SHA-512 computation is browser-verifiable using our Provably Fair Verifier. The fairness is mathematical, not promotional. Wild Fortune does NOT offer crash games and is not provably fair — its game library uses audited RNG via iTech Labs / eCOGRA-style monthly attestations. For crash, use Stake.com, BC.Game, Rollbit, or Roobet.
Disambiguation: wildfortune.io and crash games
This article does not claim wildfortune.io offers crash games or operates under the provably fair protocol. The current Wild Fortune (operated by Metlait SRL on Tobique Gaming Commission licence #0000064) hosts slot and live-dealer titles with audited RNG; it does not offer crash, plinko, dice, or limbo in the provably fair sense. The older wildfortune.com (formerly N1 Interactive Ltd on Malta MGA licence, closed July 2025) similarly did not offer provably fair games. This article covers Stake.com, BC.Game, Rollbit, and Roobet — the crypto-native casinos that DO use the protocol. See the Provably Fair Master Guide for honest WF positioning across the full fairness model spectrum.
What crash actually is
Crash is a multiplayer (or single-player) game where a multiplier climbs from 1.00× over a few seconds, then "crashes" at a random predetermined point. You place a bet before the round starts and choose when to cash out. If you cash out before the crash, you win at the multiplier you cashed out at. If the crash beats you, you lose the entire bet.
A typical round:
- t=0: round starts, multiplier = 1.00×, all bets locked
- t=1.5s: multiplier reaches 1.20× (some players cash out for safe 1.20×)
- t=3.0s: multiplier reaches 2.0× (more cash out)
- t=4.5s: multiplier reaches 3.5× (high-risk players still in)
- t=5.2s: CRASH at 3.71× — players still in lose
The fairness question is straightforward: how is the 3.71× crash point determined, and can the operator manipulate it after seeing player bets?
Provably fair crash games answer: the crash point is determined entirely by SHA-256(server_seed) committed before any bets are placed. The operator cannot change the crash point once the round starts without producing a different hash that fails verification.
The cryptographic core — same protocol as dice
The cryptographic mechanics are identical to provably fair dice (see our Provably Fair Dice Tutorial for the full walkthrough):
- Server seed generated, SHA-256 hash published before the round
- Player has a client seed (you can set this; defaults to random hex)
- Round nonce (incrementing counter)
- After round resolution:
HMAC-SHA-512(server_seed, client_seed:nonce) - First N hex characters interpreted as a decimal in [0.0, 1.0)
- Decimal mapped to crash multiplier via the mapping function
The mapping function is where crash differs from dice. Dice gives you a single linear roll between 0.00 and 99.99. Crash needs a long-tail distribution where 1.00× is the most common outcome and 1000×+ is rare.
The canonical Stake.com mapping function:
1. Let e = 2^52
2. Let h = first 13 hex characters of HMAC, parsed as integer
3. If h mod 33 == 0, return 1.00 (1% house edge case: instant bust)
4. Otherwise, multiplier = floor((100e − h) / (e − h)) / 100
5. Cap at the operator's max multiplier (typically 1,000,000×)
The h mod 33 == 0 branch is the house edge. Approximately 1 in 33 — but wait, that's 3% not 1%. The actual breakdown is more nuanced; the formula combined with the floor operation produces an effective house edge close to 1%. Other operators use slightly different mappings (BC.Game's is similar but uses 16 hex chars and a different divisor; Rollbit uses a HMAC-SHA-256 variant).
Where the 1% house edge actually lives
Most players assume the house edge comes from the long-tail distribution being "biased" against high multipliers. That intuition is wrong. The long-tail distribution itself is mathematically fair — high multipliers are rare in proportion to their payout magnitude.
The actual house edge lives in the bust-at-1.00× probability. Approximately 1 in 100 rounds (calibrated by the modulo branch in the mapping function) crash immediately at 1.00× — before any cashout opportunity. These rounds are pure operator wins.
Mathematically:
- Win probability at cashout target T:
P(win | T) = 0.99 / T - Payout multiplier at T:
T - Expected value per dollar bet:
0.99 / T × T − 1 = 0.99 − 1 = −0.01
The expected value is −1% regardless of your cashout target. Whether you cash out at 1.01× (99.0% win probability) or at 100× (0.99% win probability), the long-run EV is the same: −1%.
This invariance is a feature of well-designed crash games. The operator's margin doesn't change with your strategy, which means crash strategy is fundamentally about variance management, not edge reduction.
Multiplier distribution and EV at different cashout targets
A table of cashout target → win probability → payout → EV per dollar:
| Cashout target | Win probability | Payout | EV per dollar | Variance |
|---|---|---|---|---|
| 1.10× | 90% | 1.10× | -1% | Very low |
| 1.50× | 66% | 1.50× | -1% | Low |
| 2.00× | 49.5% | 2.00× | -1% | Medium-low |
| 3.00× | 33% | 3.00× | -1% | Medium |
| 5.00× | 19.8% | 5.00× | -1% | High |
| 10.0× | 9.9% | 10.0× | -1% | Very high |
| 100× | 0.99% | 100× | -1% | Extreme |
The 1% house edge is constant. What changes is variance — the standard deviation of your bankroll trajectory.
For a recreational player wagering a fixed bankroll, low-target crash (1.10× to 1.50×) produces a long, low-variance grind that approximates a slow bleed at 1% house edge. High-target crash (5× to 100×) produces high-variance sessions where 95% of bets lose but the occasional big multiplier covers the losses.
Neither is mathematically superior. The choice is purely about your variance tolerance and entertainment preference. Use the Bonus EV Calculator to model crash sessions against your bankroll if you're combining crash with a bonus-funded play.
Strategy myths debunked
Crash attracts more "strategy" content than almost any other casino game because the multiplier is visible during the round and the cashout decision feels skill-based. Three myths to debunk:
Myth 1: Martingale (doubling after each loss) works on crash
False. Martingale requires unbounded bankroll to survive a long losing streak. On crash with a 50% win target at 2.00×, a 10-loss streak (P ≈ 0.5^10 ≈ 0.1%) requires you to be wagering 1,024× your starting bet to recover. Operator max-bet limits (typically $5,000 to $50,000) cap the strategy at 8-12 doubling levels, which guarantees an eventual ruin event.
The math: Martingale converts a small constant -1% EV into a large rare-event loss. Expected value remains -1%. Risk profile changes from continuous low-grade bleeding to occasional catastrophic blowup. Worse, not better.
Myth 2: "Wait for a high streak then cash out low" works
False. Crash rounds are independent Bernoulli-style trials. The probability of a high multiplier next round does not depend on the history of past multipliers. The gambler's fallacy applies in its purest form here.
Some autobet scripts implement "skip until 10× hits, then start betting at 1.50× for 20 rounds" — this is equivalent to betting at 1.50× for 20 rounds, full stop. The "wait" before doesn't change the math.
Myth 3: Auto-bet scripts have lower house edge
False. The mapping function applies to every round regardless of how the bet was placed. Auto-bet scripts can help you maintain discipline (cash out at exactly target X without emotional override), but they cannot reduce the house edge below the 1% baked into the formula.
The genuinely useful aspect of auto-bet is variance reduction through consistent bet sizing — but that's a behavioural advantage, not a mathematical one.
Verification walkthrough
To verify any crash round you played:
- After the round, find the seed pair and nonce in the casino's provably fair section
- Rotate your seed pair so the previous server seed is revealed
- Open our Provably Fair Verifier
- Pick "Crash" mode
- Paste server seed (revealed), server seed hash (published), client seed, nonce
- Click Verify
The tool computes:
- SHA-256(server_seed) and checks against published hash
- HMAC-SHA-512(server_seed, client_seed:nonce)
- The crash multiplier via the mapping function
If the computed multiplier exactly matches what the casino displayed during the round, the operator played fair. If it doesn't, you have a verification failure that should be reported.
The hash check is the load-bearing part. If SHA-256 of the revealed seed doesn't match the published hash, the operator changed the seed mid-round — that's seed substitution, a real fairness violation that should be reported to the operator and (if egregious) to the operator's licensing authority.
The 6-operator crash comparison
Crash exists at multiple crypto-native casinos with subtle differences in implementation. We surveyed six in May 2026.
| Operator | Hash function | Mapping formula source | Max multiplier | Min bet | Max bet | Auto-cashout |
|---|---|---|---|---|---|---|
| Stake.com | HMAC-SHA-512 | Published GitHub | 1,000,000× | $0.0001 | $50,000 | Yes |
| BC.Game | HMAC-SHA-512 (variant) | Published | 100,000× | $0.0001 | $25,000 | Yes |
| Rollbit | HMAC-SHA-256 | Documented | 25,000× | $0.001 | $10,000 | Yes |
| Roobet | HMAC-SHA-512 | Documented | 100,000× | $0.0001 | $10,000 | Yes |
| FortuneJack | HMAC-SHA-512 | Documented | 50,000× | $0.0001 | $20,000 | Yes |
| Cloudbet | HMAC-SHA-512 | Documented | 100,000× | $0.0001 | $30,000 | Yes |
The differences that matter:
- Rollbit's HMAC-SHA-256 produces a shorter 64-character hex output (vs HMAC-SHA-512's 128 chars). Functionally equivalent for crash's single-multiplier-per-round logic, but fewer hex chars per HMAC call means more frequent server-side seed nonce increments. Verification works the same — just shorter strings.
- Max multiplier caps vary widely. Stake's 1,000,000× is genuinely the highest in the segment; Rollbit's 25,000× is the lowest. If your strategy is "wait for 100,000× then cash out lower", Rollbit won't deliver because the cap blocks the multiplier from reaching that range.
- Max bet limits matter for high-roller strategies. A Martingale doubling sequence starting at $1 hits Stake's $50,000 cap after 16 doublings; hits Rollbit's $10,000 cap after 13. Both fall short of recovering an extended losing streak.
The mathematical distribution in detail
The Stake crash mapping function produces a specific multiplier distribution. We can compute it analytically.
Let X be the HMAC-derived decimal in [0, 1) and M the resulting crash multiplier. Ignoring the modulo-33 instant-bust branch:
M = floor((100e − h) / (e − h)) / 100
Where h is the integer interpretation of the first 13 hex characters and e = 2^52.
For large e relative to h, this simplifies approximately to:
M ≈ 100 / (100 − 100 × X) = 1 / (1 − X)
This is the Pareto-style distribution. The probability that M > k is approximately 1/k (for k ≥ 1.01). So:
- P(M > 2) ≈ 0.50
- P(M > 5) ≈ 0.20
- P(M > 10) ≈ 0.10
- P(M > 100) ≈ 0.01
- P(M > 1000) ≈ 0.001
Combined with the modulo-33 branch that gives instant-bust 1.00×, the actual distribution shifts the probabilities slightly. The 99% RTP guarantee is the integral of P(survives until M) × M dM over the multiplier domain minus the 1% instant-bust loss.
Crash-specific cognitive distortions
Crash games have unique psychological hooks that the dice format does not have. Worth naming:
The visual rise
The multiplier rises visually on screen. Each tick that passes without crashing feels like increasing momentum. The brain interprets this as "the multiplier is getting bigger so the crash is becoming more likely" — a variant of the gambler's fallacy specific to visualised continuous-rise games.
Mathematically false. Crash rounds are independent. The visual rise has no information value. But the UX is intentionally designed to amplify this cognitive distortion because cashing out feels like "locking in profit" — which biases players toward earlier cashouts than expected-value math would suggest.
The "I should have waited" regret
When the multiplier crashes at 2.5× and you cashed out at 1.5×, you "miss" the higher win. This regret bias systematically pushes players toward higher cashout targets in subsequent rounds — which has lower win probability and similar EV (still -1%) but higher variance.
The longitudinal pattern: a session that starts at conservative 1.5× targets often drifts to 5× targets by hour 3. The EV stays the same but the variance has multiplied 10×. Bankroll busts happen here.
The cashed-out-too-late regret
Conversely, when you stay in past 2× and crash at 2.05× — losing on what felt like a sure win — the regret is acute. Players sometimes interpret this as "I should have cashed at 2×" which is the right lesson, but the take-away "always cash out before 2×" is the wrong generalisation because each round is independent.
Time-of-day and chat-room effects
Crash is often played in a multiplayer lobby where you see other players' bets and cashouts in real time. This has measurable effects:
- Herd cashout — when one big player cashes out at 1.20×, smaller players often cash out at 1.21× (a "follow the smart money" bias). The cashed-out players are not smart money; they have the same -1% EV as everyone else.
- Bet-size escalation — visible large bets in the lobby prime smaller players to increase their own bet sizes. The streamed bet feed is an operator UX choice that encourages this.
- Auto-bet escalation — when other players' auto-bet scripts are visible, players mimic settings without verifying whether those settings match their own bankroll size.
The behavioural literature treats this as social-proof manipulation. Wild Fortune does not have a crash lobby because it does not offer crash games at all.
Crash for bonus clearing
Some affiliates promote crash as a bonus-clearing strategy because the per-round wagering counts at 100% (slots equivalent) and the variance can theoretically be tuned by cashout target. The math:
For a 40× WR on $100 bonus = $4,000 turnover required. At $5 per round on crash, 800 rounds needed. At 1 round per 15 seconds, that's 3.3 hours of continuous play.
Compare to slots at $5 per spin and 8-second cycle: same $4,000 turnover in 1.8 hours, fewer cashout decisions, lower cognitive load.
Crash for bonus clearing is mathematically equivalent but operationally worse than slots. The decision-fatigue from 800 cashout choices is real. Slots-on-autoplay during bonus clearing produces lower-variance outcomes because every spin is a fixed-bet trial; crash bet sizes are easier to drift up during the session.
Use slots for bonus clearing. Reserve crash for sessions where the entertainment value of the format justifies the variance.
Crash vs dice vs limbo — short compare
All three games use the same SHA-256 + HMAC-SHA-512 protocol with different mapping functions:
| Game | Mapping output | Bet structure | Typical house edge |
|---|---|---|---|
| Dice | Single roll 0.00-99.99 | "Roll under" / "roll over" target | 1% |
| Crash | Long-tail multiplier | Cashout before bust | 1% |
| Limbo | Long-tail multiplier | Bet matches target before "limbo" point | 1% |
Crash and limbo are mathematically related — both use long-tail multiplier distributions. The difference is UX: crash has a real-time rising multiplier you can cash out from; limbo is a single resolved multiplier you compare against your chosen target.
Dice is the simplest — a single linear roll with a chosen target. All three games offer browser-verifiable provably fair outcomes when the operator implements the protocol correctly.
For a complete walkthrough of the dice case (the simplest), see our Provably Fair Dice Tutorial. For the full pillar including audit-based fairness models (which is what Wild Fortune uses), see the Provably Fair Master Guide.
Frequently asked questions
What is the RTP of provably fair crash?
Approximately 99%. The 1% house edge is baked into the mapping function via the instant-bust probability. This is one of the lower house edges available in any casino game category — comparable to blackjack with correct basic strategy and lower than European roulette.
Can the casino make the crash point lower if I bet bigger?
No. The crash point is determined entirely by the server seed (committed via SHA-256 hash before bets are placed) and the client seed plus nonce. The operator cannot change any of these after seeing your bet size. This is the core cryptographic guarantee of provably fair.
What is the maximum multiplier in crash?
Operator-dependent. Stake.com caps at 1,000,000×. BC.Game caps at 100,000× by default. Rollbit caps at 25,000×. The cap matters because if your cashout target exceeds the cap, you can't actually reach it even when the underlying multiplier would have gone higher. Check the operator's published max before betting at extreme targets.
Why do some crash rounds bust at exactly 1.00×?
That is the house edge. Approximately 1 in 100 rounds bust before any cashout opportunity. The frequency is calibrated by the modulo branch in the mapping function. Without this branch, the game would be exactly fair — 0% house edge — and the operator would have no margin.
Does Wild Fortune offer crash?
No. Wild Fortune's game library is slot and live-dealer titles via ICONIC21, Plati+, and BeterLive. Crash games are not in the catalog. For crash, use Stake.com, BC.Game, Rollbit, or other crypto-native casinos.
Is auto-cashout safer than manual cashout?
It removes emotional override at the cashout decision, which helps consistent execution. The house edge is identical (1%) either way. Auto-cashout is a discipline tool, not an EV tool.
Can I write my own crash verification tool?
Yes. The math runs in any browser console with the Web Crypto API. Our Provably Fair Verifier is one implementation; the underlying primitives (SHA-256, HMAC-SHA-512) are open standards.
What is the optimal cashout target?
There is no mathematically optimal target — EV is constant at -1% across all targets. The choice is about variance preference. Lower targets (1.10×-1.50×) produce slow grinds with low variance. Higher targets (5×+) produce high-variance sessions with rare big wins. Use the Bonus EV Calculator to model your specific bankroll and bet size.
Is crash mathematically rigged?
No. The protocol is publicly documented, the cryptographic primitives are open standards, and the outcome is browser-verifiable. The 1% house edge is the operator's margin and is disclosed in the published mapping function. This is materially more transparent than slot machines whose RTP is audited monthly but whose per-spin outcome cannot be verified.
Read next — cross-cluster
- Provably Fair Master Guide — the full pillar
- Provably Fair Dice Tutorial — the simplest case
- Provably Fair Verifier — browser-native verification
- Crypto casinos Australia — where provably fair operators serve AU
- Crypto casinos Canada — where they serve CA
- Chainlink VRF casino explained — stronger fairness model
This article was researched, written, and edited by James Patel, Casino Editor at Payout Verdict. Last verified 22 May 2026 against the published Stake.com and BC.Game provably fair documentation. The mapping function reproduced here is approximate; consult the operator's authoritative spec for legal-grade verification. 18+ only. See our safer gambling hub.