How Rust Crash Multipliers Are Actually Generated
Every Crash round on Rust Snowball has its crash point computed and committed before bets open. You can verify any past round in about thirty seconds.
Commit, reveal, prove
Before each Crash round, the server generates a random 32-byte seed. It SHA-256-hashes that seed and broadcasts the hash. The hash is the public commitment: it locks the seed without revealing it.
The crash multiplier itself is HMAC-SHA256(serverSeed, roundId), mapped onto a calibrated distribution between 1.00x and 50.00x. After the round resolves, the server reveals the raw seed. Anyone can re-compute the hash and confirm it matches the commitment.
That's the entire fairness guarantee in two sentences. The server can't change the outcome after seeing your bet, because the commitment is locked first. And the server can't target you specifically, because the only inputs are server-side numbers no player controls.
The cap exists so a single freak round can't bankrupt the operator. Player bankrolls are protected by the same hard ceiling — fair-cap math goes both ways.
Why Crash uses no client seed
Most games on Rust Snowball mix in a player-supplied client seed for paranoia-grade fairness. Crash doesn't. The reason is structural: every player in the round shares the same crash point. Whose client seed should the round use?
So Crash uses only the server seed plus the round ID as nonce. The cryptographic commitment IS the guarantee. This is the standard provably-fair Crash design across the whole industry, not a shortcut.
The 50x cap, calibrated
A naive mapping of HMAC bytes to a multiplier would produce occasional 10,000x rounds — fun for the player who hits them, fatal for an operator on the wrong side. So the distribution is calibrated. Roughly half of all rounds bust below 2x. About 10% reach between 2x and 5x. Around 1% reach 50x.
Above 50x is a hard ceiling. Any HMAC output that would map higher gets clamped to 50.00x exactly. The clamp is enforced on the payout side, not just the display side; a "fail-closed multiplier guard" in production prevents anything above the cap from ever paying out.
How to verify a round yourself
Open the round in your history, copy the revealed server seed and the round ID, paste them into /provably-fair. The page derives the crash point client-side and compares it to the recorded result.
The verifier on /provably-fair runs the same code path the engine uses in production. There's no separate "verifier engine" — what we compute and what you re-derive go through the identical function. The page shows the inputs, the hash, and the derived crash point so you can confirm each step.
Frequently asked questions
- Can the server cheat by picking a seed after seeing my bet?
- No. The SHA-256 hash of the seed is published before bets open. The seed is revealed after the round. A different seed produces a different hash; the mismatch would be instant proof of cheating.
- Why does the multiplier cap at 50x?
- Risk management on both sides. A true uncapped distribution produces occasional rounds that bankrupt either the operator or the player. The 50x ceiling keeps the variance bounded enough that the game stays playable.
- What's the visual 100x I sometimes see?
- Empty rounds (no real players betting) can animate up to 100x as spectacle. No one is paid on those rounds. Once a real player bets, the round is bound by the 50x real cap.
- Is the crash point random?
- Deterministic from the seed, random from your perspective. You can't predict the seed before reveal. After reveal you can re-derive the result. That's exactly what "provably fair" means.