Crash Game Development Guide — Provably Fair Math & Architecture

A standard crash curve uses an exponential growth function bounded by a target RTP (typically 96–99%). The crash point is sampled from a distribution whose CDF is calibrated so the expected payout across all multipliers equals the target RTP.

A common implementation samples u ∈ (0,1] uniformly and returns max(1, floor(100 * (1 - houseEdge) / (1 - u)) / 100). This yields the long-tail distribution players intuitively recognise.

Publish a hashed server seed before the round. After the round, reveal the seed plus the client seed and round nonce. Players can recompute SHA-256(serverSeed:clientSeed:nonce), slice the first 13 hex chars, normalise to [0,1) and verify the published crash point. Anything else is just marketing.

A single round runs for 2–30 seconds. Clients connect over WebSocket and receive 20–30 multiplier ticks per second. Use a single authoritative game-loop process per shard (Node.js + uWebSockets, Go + Gorilla, or Elixir) and broadcast deltas — never let clients drive the curve.

• Pre-generate the next 100 rounds' crash points server-side.
• Persist bets to Redis on accept, flush to Postgres on settle.
• Run a separate settlement worker so the game loop never blocks on DB I/O.

Crash games are the favourite playground for collusion rings. Enforce per-IP and per-device cashout-time entropy checks, deposit-velocity caps and bonus-abuse heuristics. Flag accounts whose median cashout falls within 0.05× of a public multiplier — that is almost always botting.