Crash Gambling Games: How the Multiplier Is Generated
How crash games fix each multiplier in advance with a hash chain, where the 1-in-101 instant crash and 1% edge sit, and how to verify a past round.
Crash gambling games pay a multiplier that climbs until a crash point, and only bets cashed out before that point win. In the provably fair versions with published code, the crash point of every round is fixed before anyone bets by a pre-committed chain of hashes, the house edge is written into the crash-point formula itself, and anyone can recompute a finished round from its revealed hash.
The rest of this page follows the published reference code step by step: how the multiplier is generated, where the edge sits, why an auto cash-out target does not change expected value, and how to check a past round yourself.
How crash gambling sets the multiplier before a round starts
The crash point is not drawn live. It is read from a hash that already existed, so the operator's job during play is only to reveal it.
The reference method was published by Bustabit in January 2015. The operator took a server secret and built a chain of 10 million SHA-256 hashes, feeding each output back into SHA-256 to make the next link, then published the hash of the final link. That commitment means no alternate chain can be swapped in later.
Games are then played through the chain in reverse order, last link first. Each game hash is salted with a client seed the operator does not control: the hash of a Bitcoin block not yet mined at the time of the announcement. Because the seed did not exist when the chain was committed, the operator could not have picked a chain that happened to produce favourable crash points.
A second operator shows this is a reusable recipe rather than a one-off. moonSTEEM published the same 10 million hash construction, broadcasting the final hash's SHA-256 on the Steem blockchain. The open-source nvkp Go package generalises the seed step: the host commits to data that is not yet known and uses it later as a salt, which proves it had no control over the resulting crash points.
Where the house edge sits in a crash gambling game
In the Bustabit reference code the edge is built in twice: once as forced instant crashes, and once as a cut from every other multiplier.
Forced instant crashes. The code checks whether the HMAC of the game hash and client seed is divisible by 101. If it is, the round crashes instantly at 1.00x, which happens in 1 game in 101. Every bet in that round loses, whatever cash-out target it carried. moonSTEEM's code carries the identical instant-crash rule.
A cut from the fair multiplier. For all other rounds, the code takes the top 52 bits of the hash as a uniform number r between 0 and 1. The fair multiplier for a zero-sum game would be 1/(1-r). The code then removes a 1% house edge from that fair value before rounding down.
The nvkp package treats the instant-crash rate as the main dial. The host sets a rate so that every xth round crashes at 1, and the inverse of that rate roughly equals the game's margin. So a site's instant-crash frequency is a fast read on its edge, but only if it publishes the code that applies it.
Does an auto cash-out target change expected value?
No. The target decides how often a bet wins and how large the win is, but the edge comes off the crash-point formula for every round, so it applies to every target alike.
The reasoning follows from how the reference code is written. The fair multiplier 1/(1-r) is, in the code's own description, the multiplier for a zero sum game: before the edge, no cash-out target beats any other on average. The edge is then taken from the multiplier itself and from the instant-crash rounds, neither of which depends on what a player chose. A low target wins often and small, a high target wins rarely and large, and both carry the same built-in cost per bet. Auto cash-out is a convenience for hitting a target precisely, not a strategy that moves the average.
How to verify a past crash round
A round can be checked with nothing but its revealed hash, the published client seed and the formula from the reference code.
| Step | What you compute | What it proves |
|---|---|---|
| Chain check | SHA-256 of the revealed game hash | It should equal the hash of the game played just before, since games run backwards through the chain |
| Instant-crash check | HMAC of the game hash with the client seed, tested for divisibility by 101 | If divisible, the round had to crash at 1.00x |
| Crash point | Take the first 52 bits as h, then floor((100 × 2^52 − h) / (2^52 − h)) | The crash point in hundredths: 123 means 1.23x |
| Commitment | Keep hashing forward until you reach the published final hash | The round belongs to the chain committed before play |
The integer form is the one to use, because it is exactly the line a verifier recomputes in the reference code: Math.floor((100 * e - h) / (e - h)), where e is 2^52. A result that does not match the multiplier the site showed means the round was not produced by the published method.
Two limits apply. The check proves a round matches the committed chain and the published formula. It does not prove which formula a site actually runs unless that site publishes its own code and client seed.
Comparing published crash game constructions
The three public sources share one design but differ in how fixed the edge is.
| Source | Chain | Client seed | Instant crash |
|---|---|---|---|
| Bustabit reference code | 10 million SHA-256 hashes, final hash published | Bitcoin block hash not yet mined | 1 game in 101 at 1.00x |
| moonSTEEM | 10 million SHA-256 hashes, final hash broadcast on-chain | Not detailed in the seeding post | 1 game in 101 |
| nvkp Go package | Set by the host | Data the host commits to before it is known | Rate chosen by the host |
When a crash site describes itself as provably fair, these are the parts to look for: a published final hash, a client seed it could not choose, and code that shows the instant-crash rule and the edge.
Questions on this
Is there a game called Crash?
Yes. Crash is a casino game format rather than a single title: a multiplier rises until a predetermined crash point, and the round pays only players who cashed out below it. The provably fair versions published by Bustabit and moonSTEEM fix every crash point in advance through a hash chain.
Can a crash game be rigged after you bet?
Not if the operator follows the published seeding method. The chain is committed before play, and the client seed is a Bitcoin block hash that did not exist yet, so the operator cannot steer which crash points come out. A game that publishes no chain and no seed offers no such check.
How often does a crash game bust at 1.00x?
In the Bustabit reference code, 1 game in 101 crashes instantly at 1.00x. Other operators can choose a different rate, and the nvkp package lets the host set it, so check the rule in the code a given site publishes.
Does a higher auto cash-out target pay better on average?
No. The fair multiplier is built for a zero-sum game at every target, and the edge comes off the formula itself, so the target changes how often you win and how much, not the average cost of each bet.
Sources and on-chain links
- Bitcointalk (Bustabit announcement, reference code): Bustabit.com Provably Fair Seeding Event, 13 January 2015
- GitHub (nvkp): nvkp/crash: Golang package for provably fair casino crash game, undated, accessed October 2026
- Steemit (moonSTEEM operator post): moonSTEEM provably fair crash game seeding event, undated, accessed October 2026
