How provably fair crash works: hash chains, salts and the 1% edge

By the CashoutScore testing team · Updated 27 October 2026

In crash, a multiplier climbs from 1.00x until it “crashes”; you win your stake times the multiplier if you cashed out before that moment. Unlike dice or mines, there is no client seed per player - everyone at the table sees the same crash point. So the fairness proof has to commit to every future round at once, before anyone bets. The standard way to do that is a hash chain plus a salt nobody could know in advance. This guide walks through the scheme Stake published for its crash game in July 2019, then verifies a real round. For the general seed-and-nonce model used by most other games, see what provably fair means.

The hash chain: generate forward, play backwards

The casino picks a secret starting value and hashes it over and over:

h1 = SHA256(secret)
h2 = SHA256(h1 as hex text)
...
hN = SHA256(h(N-1) as hex text)

In Stake’s bitcointalk seeding post the chain has 10,000,000 hashes, each one the SHA-256 of the hexadecimal text of the previous one. The casino publishes only the last hash first (for Stake: 78a9757d3be42b74a3f70239078ad9317125fe9ee630d5bdada46de963e56752) and then plays the chain in reverse order: each new round uses the hash just before the one used by the previous round.

Why each round locks in the next

Hashing goes one way only. Given a round’s hash, anyone can compute SHA-256 of it and check that it equals the hash of the round before it, all the way back to the published end of the chain. The casino cannot swap in a different future hash, because it would have to find another value whose SHA-256 equals the current one - a preimage, which is not feasible. Players cannot look ahead for the same reason: the next hash is the preimage of the current one. Once the end hash is public, every round in the chain is fixed.

The salt: a Bitcoin block that did not exist yet

A chain alone has a weakness: the casino generated it and knows every result. It could create many chains and publish the one that happens to pay players least. To rule that out, each result is mixed with a value chosen after the chain was committed. Stake used the hash of Bitcoin block 584,500, which, as the post says, had not been mined when the chain’s end hash was posted. Once the block was found, the operator posted the block hash as an update in the same thread: 0000000000000000001b34dc6a1e86083f95500b096231436e9b25cbdd0075c4. You can confirm that hash belongs to height 584,500 on a public explorer such as mempool.space.

The formula, line by line

From the seeding post (JavaScript, lightly reformatted):

hmac  = HMAC_SHA256(key = gameHash, message = blockHash)
hex   = first 8 hex characters of hmac
int   = parseInt(hex, 16)            // 0 … 4,294,967,295
crash = max(1, 2^32 / (int + 1) × (1 − 0.01))

• 8 hex characters are 32 bits, so int is a whole number from 0 to 2^32 − 1.
• 2^32 / (int + 1) runs from 1 (when int is at its maximum) up to 2^32 (when int is 0). The +1 avoids dividing by zero. If int is uniform, the chance this value is at least x is about 1 ÷ x - which is exactly a fair game: betting to cash out at x returns x × 1/x = 1 on average.
• × (1 − 0.01) scales every result down by 1%. Now the chance of reaching x is about 0.99 ÷ x, and the average return of any cash-out target is 0.99. That is the 1% house edge.
• max(1, …) catches the results the scaling pushed below 1. About 1% of int values land there and become a 1.00x crash, where no cash-out can make a profit. This is the visible face of the edge.

Worked example with a published vector

Take the game hash 5844bf329a6334074778ab8a5f0960e24f9eec43f83bbd98ac0a9f8bcd87184e (a round from Stake’s chain used as a public test vector) and the block-584,500 salt above. Computing the HMAC with Node’s built-in crypto module gives:

A player who cashed out at 2.35x or below in that round won; anyone aiming higher lost. The chain check for the same round: SHA-256 of the game hash (as text) is 59bd990a98f7d7a18395b186f4a232a1dedfd65048968b9b9a6493dcb2a0939d, which must be the game hash of the round played just before it.

How to verify a round with our tool

1. Open the round in the casino’s game history and copy its game hash.
2. Find the salt the casino announced (for Stake’s chain, the block-584,500 hash above).
3. In the provably fair verifier, choose the game Crash, paste the game hash and the salt, and run it. The tool shows the HMAC, the int, the crash point and the previous-round hash. “Load public test vector” fills in the example above.
4. Compare the crash point with the history, and the previous-round hash with the round before it. For a deeper check, hash forward repeatedly until you reach the published end hash.

The calculation runs in your browser. For seed-and-nonce games, see verify a casino round yourself.

What it does not prove

• Re-seeding. A chain runs out (10 million rounds in Stake’s case) or may be replaced. A new chain is only as good as its own seeding: an end hash and a future salt published before play starts. If you cannot find that announcement, the old proof does not cover the new rounds.
• That nobody knows the results. Once the salt is known, the operator can compute every upcoming crash point. The scheme proves results cannot be changed, not that they are secret from the house.
• Settlement. It does not prove your cash-out was recorded at the moment you clicked, or that a withdrawal will be paid.
• Other casinos. Variants differ. From their own pages, BC.Game salts a seed chain with a Bitcoin block hash, Roobet uses a hash chain with a block-hash salt for crash and slide, and Gamdom uses chains of 10 million SHA-256 hashes played in reverse - but the HMAC inputs, edge and rounding may not match Stake’s formula. Always verify against the casino’s own published formula.

Cash-out timing and auto-cashout

The crash point is fixed before the round starts; watching the curve or clicking at a “feeling” cannot change it. With auto-cashout at a target x, you win whenever the crash point is at least x - probability about 0.99 ÷ x - and receive x times your stake:

expected return = x × 0.99 / x = 0.99 of the stake

At 1.5x you win about 66% of rounds; at 10x about 9.9%; at 100x about 0.99%. The average is 99% every time. Auto-cashout only removes the risk of reacting late; manual play can do worse (missed clicks, network lag) but never better on average. A target changes volatility, not the edge - see house edge, RTP and volatility, and set limits with the bankroll tool before you play.

18+. Gambling involves risk of loss. Help and self-exclusion.