Crash

Cash out before the multiplier crashes. h mod 33 = 3% house edge. Verifiable per round.

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

How Crash math actually works

Each round derives a single integer 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

The modulo-33 check is the entire house edge: about 1 in 33 rounds (3.03%) busts at 1.00× immediately. Every other round uses the geometric formula that produces the iconic skewed distribution — lots of action in the 1.0–2.0× range, fewer rounds at 5×+, exponentially rarer above 100×.

Why every cashout target has the same EV

For any cashout target T ≥ 1.00:

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

Your expected return per round is constant at −3%, no matter where you cash out. The math doesn’t care about your strategy. Cashing at 1.1× wins 88% of the time with a tiny payout; cashing at 50× wins 1.9% with a massive one. Same EV, totally different variance profile.

The Crash cashout explorer draws the survival curve so you can see this directly.

How operators rig Crash

Crash is the most-manipulated provably-fair game on the internet — too much player attention is concentrated on a single number. The five most-documented manipulations are listed in the Dirty Tricks book; the canonical one is cashout-button latency injection: server inserts a 200–500 ms processing delay during high-multiplier rounds so your “cash out at 5×” lands at 4.7×, past the curve and inside the bust window.

Spot check. Cash out at the same target 50 times and time the delay from button-click to operator confirmation. The delay should be statistically identical regardless of multiplier. A correlation between target multiplier and confirmation latency is intentional friction, not network jitter.

Step-by-step provably-fair verification

  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.

The Crash verifier automates step 6; the hash-chain auditor batches step 5 across rotations.

Frequently asked questions

Can a smart cashout strategy beat Crash long-term?

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. Unusual, but variance like this happens — that’s why we have 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.