Skip to content
LAB

Crash

Get out before the curve busts. h mod 33 = 3% house edge. Every round is checkable.

Crash

Cash out before the multiplier crashes. Stake-derived algorithm — h mod 33 = 3% house edge.

Bankroll
Bets0
Win %
Net P/L
Streak
Biggest win
1.00×
Place your bet + auto-cashout target.
Presets
Auto-bet
How dishonest operators rig this game 6 documented tricks
01 Account-tagged bust seeds

Mechanism. Server seed is silently chosen per account. High-balance or +EV accounts get seeds that produce early-bust multipliers; recreational players get juicy rounds visible in chat.

Red flag. Watch published-hash rotation. If hashes change at suspicious moments (after a deposit, after a withdrawal request), the operator is selecting seeds at runtime.

02 Cashout-button latency injection

Mechanism. Operator adds 200–500 ms server-side processing delay during high multipliers, so your "cash out at 5×" lands at 4.7× — past the curve and inside the bust window.

Red flag. Compare displayed multiplier to cash-out confirmation. A consistent gap on big multipliers is intentional friction, not network jitter.

03 Display-only multiplier desync

Mechanism. Animated multiplier on screen is not the bound-to-result HMAC value — it slows down near your target to fake-look like the curve. Real outcome decided server-side from a different stream.

Red flag. Verify a few rounds against your own HMAC computation. Visible multiplier must match the formula floor((100·e − h)/(e − h))/100 exactly.

04 Modulo-bias instant-bust skew

Mechanism. Game uses h % N for the instant-bust check, with N chosen so low h values bust more often. Drains beginners who always cash out at low targets.

Red flag. Track frequency of 1.00× rounds. If it materially exceeds 1/N for the stated house edge, the algorithm is biased.

05 Phantom-cashout race

Mechanism. Server processes high-bet cashouts last during high multipliers, so by the time your bet is matched, the round has busted. Smaller bets clear first.

Red flag. Time your own cashout, then cross-reference with the round-history feed. A delay correlated with bet size is foul play.

06 Provably-fair theatre

Mechanism. Operator publishes a server-seed HASH up-front but, after rotation, reveals a different seed than what was committed to. The hash never gets reverified by 99% of players.

Red flag. Always SHA-256 the revealed seed yourself and compare to the previously-published hash. Mismatch = the seed was swapped.

For the full compendium across all games, see The Book of Casino Dirty Tricks.

Server seed hash
Server seed (revealed after rotation)— pending rotation —
Client seed
Next nonce

The math behind each Crash round

Crash Game Multiplier Trajectory
Crash Multiplier: Verified trajectory and automated cashout point.
Crash Hash Verification Modal
Cryptographic Audit: Server seed reveal confirming outcome integrity.

A single integer drives the whole outcome, pulled from the HMAC stream:

h = parseInt( first 13 hex chars of HMAC(server, "{client}:{nonce}:0"), 16 )

if  h mod 33 == 0    →   multiplier = 1.00×    (instant bust, ~3% of rounds)
else                 →   multiplier = floor( (100·2⁵² − h) / (2⁵² − h) ) / 100

That modulo-33 test is the whole house edge in one line of arithmetic. Roughly one round in 33 — 3.03% — dies at 1.00× without giving you a chance to click. Everything else runs through the geometric formula, which explains the shape you see: dense activity between 1.0× and 2.0×, rounds above 5× thinning out fast, and anything past 100× becoming exponentially scarce.

Pick any cashout target — the EV never moves

Set a target T of 1.00 or higher and two relationships hold:

P(round reaches T)  =  0.97 / T
EV(T)               =  T · P(reach T) − 1  =  −0.03  =  −house edge

Expected return sits at −3% per round, fixed. Your target choice redistributes variance, not value. Grab 1.1× and you’ll win about 88% of rounds for pocket change; chase 50× and you’ll connect on roughly 1.9% of attempts for a much larger hit. Identical EV in both directions.

The formula has no opinion about your strategy. To see the survival curve yourself, open the Crash cashout explorer.

Five ways operators manipulate Crash

No provably-fair game attracts more manipulation attempts — everything rides on one visible number, so pressure concentrates there. The Dirty Tricks book documents five recurring patterns; the textbook case is cashout-button latency injection. During high-multiplier rounds the server inserts a 200–500 ms processing delay, so a request meant to land at 5× settles at 4.7× — already swallowed by the bust.

Spot check. Fire fifty cashouts at an identical target and measure the gap between button-click and operator confirmation. Latency should look the same no matter what the multiplier was doing. If confirmation gets slower exactly when payouts get bigger, that’s engineered friction, not packet loss.

Verify a round yourself, step by step

  1. Capture the server-seed hash the operator publishes before the round.
  2. Record your client seed and the round nonce.
  3. Play the round; record the busted multiplier.
  4. Wait for the operator to rotate seeds — the previous seed must now be revealed.
  5. SHA-256 the revealed seed yourself. Compare to the previously-published hash. Mismatch = the operator swapped seeds; every round under that hash is invalid.
  6. Hash matches? Run HMAC-SHA256(revealed_seed, “{your_client}:{nonce}:0”) and apply the formula above. The result must equal the displayed multiplier exactly.

Step 6 is what the Crash verifier does automatically; step 5 across many rotations is the job of the hash-chain auditor.

Frequently asked questions

Can a clever cashout scheme beat Crash over the long run?

No. Strategy controls variance, not expected value. Over enough rounds, every player converges to −3% of total turnover regardless of cashout target. What strategy CAN optimise is the probability of hitting a specific profit goal before bust, sized via the Kelly criterion.

Why does the simulator default to 3% house edge?

It’s the canonical Stake setting. The house-edge dropdown lets you switch to 1% (h mod 101), 2% (mod 50), or 4% (mod 25) and observe how the instant-bust frequency changes.

I just hit five 1.00× busts in a row. Is the game rigged?

Probably not, but check. At the 3% default, P(5 consecutive instant-busts) = (1/33)⁵ ≈ 2.6 × 10⁻⁸. That’s once every 40 million 5-round sessions. Rare isn’t impossible — run it through the streak analyzer.

Is the server seed in this simulator actually random?

Yes. We use crypto.getRandomValues from your browser’s WebCrypto. On a real operator the answer is “supposedly” — and the modulo bias detector plus chi-square audit exist to test that supposition empirically.