RNG in crash games
A crash game turns one random value — the point at which a rising multiplier stops — into a round, and it usually proves that value cryptographically rather than through a testing lab. Read precisely, the commit-reveal scheme proves the outcome was fixed before you bet and not altered afterwards. It does not prove the distribution behind the crash point, the size of the house edge, or that the seed was chosen neutrally — which is exactly the boundary this chapter draws.
A crash game strips a casino round down to a single number. A multiplier climbs from 1.00× and, at a moment you cannot see coming, it “crashes”; cash out before it does and you keep your stake times the multiplier at that instant, miss it and the stake is gone. Everything hinges on one randomly-determined value per round — the crash point. Aviator is the archetype, and the same shape drives the instant “originals” — Plinko, Mines, Dice — that crypto-native casinos popularised; the crash & provably-fair originals guide covers the formats themselves. This chapter is about the machinery underneath: how that one value is generated, and precisely what the “provably fair” badge on it does and does not cover.
One random value per round
Unlike a slot, whose outcome is a mapped reel position, a crash round is a single draw. The server picks a crash multiplier before the round begins; the rising curve you watch is just that fixed number being played out in time. That is what makes crash games such a clean illustration of provably-fair cryptography: there is exactly one outcome to commit to, reveal and check per round, so the whole integrity argument fits in a single hash.
How the crash point is generated: commit then reveal
The standard construction is a commitment scheme with a keyed derivation on top — the same mechanism the provably-fair chapter derives in full, so here it is only sketched. Before the round the operator generates a secret server seed and publishes a cryptographic hash of it, typically SHA-256. That hash is a sealed envelope: a commitment scheme is defined by two phases, a commit phase “during which a value is chosen and committed to” and a reveal phase “during which the value is revealed by the sender, then the receiver verifies its authenticity”. Two properties define the commitment: hiding, so “the specific value chosen cannot be extracted from the message”, and binding, so “the value chosen during the commit phase must be the only one that the sender can compute and that validates during the reveal phase”.
The crash point itself is then derived by combining that server seed with a client seed you can set and a nonce (a per-round counter), usually through HMAC-SHA256 — RFC 2104’s “mechanism for message authentication using cryptographic hash functions”, which “can be used with any iterative cryptographic hash function… in combination with a secret shared key.” The resulting hash is a uniform-looking number, and a published formula maps it to a multiplier — commonly by reading the leading hash digits as an integer and passing them through a function that yields the crash value, often with a small share of rounds sent straight to an instant bust at 1.00×. That instant-bust share, and the shape of the formula, are exactly where the game’s economics are set. Because you choose your client seed after the server seed is already committed, the operator cannot have tailored its seed to your input.
What provably fair genuinely proves
After the round — or a batch of rounds — the operator reveals the server seed, and you can check rather than trust. First, hash the revealed seed and confirm it equals the commitment published beforehand: because the scheme is binding, a match proves the operator did not swap the seed once bets were in. Second, re-run the derivation yourself with that server seed, your client seed and each nonce, and confirm the crash point reproduces exactly. If both checks pass, the outcome verifiably came from a value fixed before you bet and computed honestly from it. That is a real, independently checkable integrity property, and it is the genuine strength of the format.
What it does not prove — the boundary that matters
Here is the line the marketing blurs, and getting it exactly right is the point of this chapter. Proving a round was not tampered with after the commit is a different claim from proving the game is fair in any value sense — and provably fair delivers only the first. Concretely, it does not prove:
— that the crash-point distribution matches what is advertised. Verifying one round confirms that round was consistent with the committed seed; it says nothing about whether the long-run distribution of crash points is the one claimed. The proof is per-round integrity, not a distribution audit.
— that the server seed had good entropy. Hiding assumes the seed was hard to guess in the first place; nothing in the published hash forces the operator to have generated a high-entropy, neutral seed rather than a cherry-picked one, the same guessable-seed lesson set out in how casino RNGs work.
— that the game is independently certified. A player recomputing a hash is not a laboratory evaluating a build against a written standard — a separate assurance covered next.
Put plainly: a verified round tells you that one outcome was consistent with a pre-committed seed. It tells you nothing about long-run return, and it does not make the expected value of playing anything other than negative. Verifiability and profitability are simply different things.
Provably fair is not certification
The two models answer different questions, and crash titles split on which they offer. Some are lab-certified like any RNG game, evaluated against a named standard for the statistical quality and unpredictability of the underlying generator — the kind of dated, bounded claim examined in what a certificate actually asserts. Many crypto-native originals instead lean on provably fair in lieu of third-party certification: the per-round cryptographic proof stands in for an external laboratory. Neither is a substitute for the other. Certification asks you to trust an independent lab and a regulator but covers the generator and a payout floor; provably fair asks you to trust nothing per round but covers only that one round’s integrity, and says nothing about the pay table, the operator’s solvency or the neutrality of the seed. Reading a “provably fair” badge for exactly that — proof of an untampered draw, not proof of a fair game — is what lets you judge a crash game honestly.
Common questions
Does “provably fair” mean a crash game has no house edge?
No — the two are unrelated. Provably fair proves that the crash point was computed from a server seed the operator committed to before the round and did not alter afterwards. It says nothing about the distribution that crash point is drawn from, and that distribution is where the house edge lives. A crash game can be perfectly provable and still be tuned to any return the operator chose; the casino guide puts a typical figure on it, with Aviator’s return around 97%. Verifiability is about integrity, not value, and over enough rounds the expected value stays negative.
Can I predict when the next round will crash?
No. Each round’s crash point is derived from a fresh combination of the committed server seed, your client seed and a per-round nonce through a one-way keyed hash, so past crash points carry no usable information about the next one — the same forward-unpredictability property required of any certified generator. A string of early crashes does not make a high multiplier “due”, and a run of high multipliers does not make a crash “overdue”; each round is independent by construction.
Is provably fair the same as being certified by a testing lab?
No — they answer different questions and are not substitutes. Provably fair lets you check, for a single round, that the result was consistent with a seed committed in advance. Independent certification is a dated statement from a laboratory that a build met a written standard, including a payout floor and adversarial-resistance requirements. Some crash titles carry both; many crypto-native “originals” rely on provably fair in place of third-party certification. Knowing which one a game offers tells you which kind of assurance you actually have.
Sources (6)
- RFC 2104 — HMAC: Keyed-Hashing for Message Authentication (IETF, February 1997): a keyed construction over a cryptographic hash such as SHArfc-editor.org
- Commitment scheme (commit and reveal phases; hiding and binding properties) — Wikipediaen.wikipedia.org
- iGamer — Provably fair, explained (the commitment scheme and per-bet derivation in full)igamerhq.com
- iGamer — What a certificate actually asserts (independent laboratory certification, and its bounds)igamerhq.com
- iGamer — How casino RNGs work (mapping a number to an outcome without bias; seed entropy)igamerhq.com
- iGamer — Crash & provably-fair originals (the crash format and instant games in the casino guide)igamerhq.com
Education, not advice. This chapter explains how the random number generators behind casino games are built, tested and certified so you can judge the claims made about them honestly. It is not a system, and nothing here treats gambling as a way to make money — over enough play the mathematics favours the house. 18+.
End of the current pathBack to the RNG pillar