Quick answer: A SHA-256 hash becomes a crash point multiplier in 4 steps: (1) combine the round’s game hash with the public salt via HMAC-SHA256, (2) take the first 8 hex characters (Stake Crash) or 13 (Bustabit), (3) convert hex to a decimal integer, (4) apply the published crash formula. This page walks through each step with real, recomputable numbers — the same values our Provably Fair Verifier ships as test vectors.
This is the guide people look for when they search “crash game provably fair formula” or “how to convert a hash to a crash multiplier.” We skip the theory and go straight to the calculation — hex to decimal to crash point, with every intermediate value shown. (Note: Aviator by Spribe uses SHA-512 with a different seed model — the formulas below cover SHA-256/HMAC-SHA256 implementations like Stake and Bustabit.)
Two formula families are used in production crash games. We walk through both below with worked examples.
Formula A: The 232 Method (Stake Crash)
This formula is published in Stake’s Crash seeding event. Results come from a pre-committed chain of 10,000,000 SHA-256 hashes; each round’s game hash is combined with a fixed public salt — the hash of Bitcoin block 584,500, mined only after the chain was committed.
Step 1: Generate the HMAC-SHA256 hash
The round’s game hash is the HMAC key; the public salt is the message:
key: “game_hash_from_the_chain”,
message: “0000000000000000001b34dc6a1e86083f95500b096231436e9b25cbdd0075c4”
)
There is no server seed, client seed, or nonce here — Stake documents those inputs for its per-player originals (dice, limbo), not for Crash. Confusing the two constructions is the most common reason a manual recalculation fails.
Game Hash:
78a9757d3be42b74a3f70239078ad9317125fe9ee630d5bdada46de963e56752Salt (block 584,500):
0000000000000000001b34dc6a1e86083f95500b096231436e9b25cbdd0075c4Result hash: d688998885e406b4e5491e86829373b16f053312d6673d0bd2f1a2183b520d92
Step 2: Extract the first 8 hex characters
Take characters 0 through 7 of the hash. These 8 hex characters represent 32 bits of data:
// From “d688998885e406b4…” → “d6889988”
Step 3: Convert hex to decimal integer
Convert the 8-character hex string to a base-10 number:
// d = 13, 6 = 6, 8 = 8, 8 = 8, 9 = 9, 9 = 9, 8 = 8, 8 = 8
// = 13×16^7 + 6×16^6 + 8×16^5 + 8×16^4 + 9×16^3 + 9×16^2 + 8×16^1 + 8×16^0
// = 3,599,276,424
The result is a number between 0 and 4,294,967,295 (232 − 1).
Step 4: Apply the crash point formula
Plugging in our example values with the documented 1% house edge:
= max(1, 1.19329 × 0.99)
= max(1, 1.18135)
= 1.18 // truncated to 2 decimal places
The crash point for this example is 1.18x — the same value our verifier’s test-vector table lists for these inputs, so you can confirm every step of this walkthrough in the tool.
What each part means
232 / (int + 1) — converts the random integer into a multiplier. Small integers produce high multipliers (rare), large integers produce low multipliers (common). This creates the characteristic distribution where most rounds crash below 2x.
(1 − houseEdge) — scales every result down by the house edge. With 1% edge, every multiplier is multiplied by 0.99. With 3% edge (Aviator), by 0.97. This is not hidden — it’s an explicit parameter.
max(1, ...) — ensures the crash point is never below 1.00x. When the formula produces a value below 1, the game “instant crashes” at exactly 1.00x.
Which games this formula does NOT cover
Formula B: The 52-Bit Method (Bustabit)
This formula is implemented in Bustabit’s official open-source verifier; BC.Game’s white paper documents the same 52-bit mapping. It uses more bits for higher precision and builds the house edge into the formula constant rather than a separate multiplier.
Step 1: Generate the HMAC-SHA256 hash
key: “salt_from_the_seeding_event”,
message: gameHashBytes // raw bytes of the 64-hex game hash
)
Note the argument order is the opposite of Stake’s: in Bustabit the salt (a Bitcoin block hash committed at a public seeding event) is the HMAC key, and the game hash — decoded to raw bytes — is the message. Swapping them produces a valid-looking but wrong result.
Step 2: Extract 13 hex characters (52 bits)
int52 = hexToDecimal(hex13) // Range: 0 to 2^52 − 1 (4,503,599,627,370,495)
52 bits gives much higher precision than 32 bits. The maximum safe integer in JavaScript is 253 − 1, so 52 bits stays within safe calculation range.
Step 3: Apply the crash point formula
crashPoint = max(1.00, floor(99 / (1 – X)) / 100)
The 99 in the numerator (instead of 100) is what produces the 1% house edge. Older v1 code expressed the same idea as floor((100e − h) / (e − h)) / 100 with a separate divisible-by-101 check — the current official verifier uses the direct 99 / (1 − X) form shown here.
Worked example (Bustabit)
Game Hash:
567a98370fb7545137ddb53687723cf0b8a1f5e93b1f76f4a1da29416930fa59Salt:
00000000000000000001e08b7fd44f95e3e950ac65650a8031a6d5e1750e34beHMAC-SHA256 result: 085cb1d8fc3dfb24fff9bd709b90eca4f68aef122f01b516df7ff169c61fbd3b
hex13 = 085cb1d8fc3df → int52 = 147,107,420,816,351
Apply formula:
X = 147,107,420,816,351 / 4,503,599,627,370,496 = 0.0326644…
99 / (1 − X) = 102.3429…
floor(102.3429…) / 100 = 1.02x
The same inputs and result appear in our verifier’s test-vector table — run them there to confirm this walkthrough.
Both Formulas Side by Side
| Aspect | Formula A (232) | Formula B (52-bit) |
|---|---|---|
| Used by | Stake Crash (documented) | Bustabit (current); BC.Game per white paper |
| Hash method | HMAC-SHA256(key=gameHash, msg=salt) | HMAC-SHA256(key=salt, msg=gameHash bytes) |
| Bits extracted | 32 (8 hex chars) | 52 (13 hex chars) |
| House edge mechanism | Multiply by (1 − 0.01) | The 99 constant in 99/(1 − X); ≈2% of rounds land at 1.00× |
| Formula | max(1, 232 / (int+1) × 0.99) | max(1.00, floor(99 / (1 − X)) / 100) |
| Configurable RTP | In principle; Stake documents 1% | Fixed by the 99 constant (99% RTP) |
| Precision | ~4.3 billion possible values | ~4.5 quadrillion possible values |
Both formulas produce the same type of distribution — low crash points are common, high ones are rare — because they both convert a uniform random input into a multiplier using an inverse function. The house edge is applied differently but achieves the same mathematical effect.
Common Misunderstandings
“The formula can be reversed to predict crash points”
The formula itself is reversible — given a crash point, you can calculate what integer produced it. But you cannot get the integer without the HMAC result, and you cannot compute that without the round’s game hash, which is only revealed after the round. The unpredictability comes from SHA-256, not from the formula. For more on why prediction is impossible, see our Crash Game Algorithm Guide.
“Different house edges mean different algorithms”
Within the same formula family, the algorithm is the same — the house edge is a single parameter. Changing it from 0.01 to 0.03 in Formula A doesn’t change the logic, just the multiplier applied to every result. However, Formula A and Formula B are structurally different algorithms that enforce the house edge through different mechanisms (parameter multiplier vs instant crash check).
“The 52-bit formula is more fair than the 32-bit formula”
Both are equally fair if properly implemented. The 52-bit method has higher precision (more distinct possible crash points) but this doesn’t affect the expected return. The RTP is determined by the house edge parameter, not by the number of bits extracted.
Verify It Yourself
You can check any of these calculations independently:
Use our verifier: Paste seeds into our Provably Fair Verifier to see the step-by-step calculation for any completed round.
Use any HMAC-SHA256 tool: Any standard HMAC-SHA256 calculator will produce the same hash from the same inputs. Then apply the formula manually. If the crash point matches what the game showed, the result is consistent with the disclosed formula and inputs — a strong indicator that the round was not tampered with.
Run the code yourself: The formulas above are complete — you can implement them in any programming language (Python, JavaScript, etc.) and verify independently.
→ For the full algorithm architecture (hash chains, seed commitment, why prediction is impossible), see our Crash Game Algorithm Guide.
→ For step-by-step verification walkthroughs per platform, see our Provably Fair Verification Guide.
→ For what RTP and house edge cost you per session, see our RTP & House Edge Guide.
Primary Sources
- Stake Crash seeding event — the chain, the block-584,500 salt, and the 232 formula.
- Bustabit official verifier — the current 52-bit implementation, chain salts, and hashing details.
- BC.Game white paper — the published 52-bit Crash example.
Last implementation review: August 20, 2026. Both worked examples on this page were recomputed against the sources above on that date.
Frequently Asked Questions
How do you convert a SHA-256 hash to a crash multiplier?
Take the HMAC-SHA256 of the round’s game hash and the public salt (key and message order depends on the platform — see above), extract the first 8 hex characters (232 method) or 13 hex characters (52-bit method), convert hex to a decimal integer, then apply the published crash formula. The full step-by-step with real values is shown above.
What does “crash multiplier = 0.99 × e / (e − h)” mean?
This is an informal shorthand for the 52-bit family. The current official Bustabit code computes X = h / 2^52 and then floor(99 / (1 − X)) / 100 with a 1.00× minimum — the 99 constant is what carries the 1% house edge. The older v1 notation floor((100e − h) / (e − h)) / 100 plus a divisible-by-101 check described the same economics but is no longer the shipped implementation.
What is the provably fair crash game formula 1/(1−r)?
The formula 1 / (1 − r) is a simplified representation of the crash point distribution, where r is a uniform random number between 0 and ~0.99. When r is close to 0, the crash point is near 1.00x. When r is close to 0.99, the crash point is very high. This is essentially the same as the 232 formula: 2^32 / (int + 1) produces the same distribution because the integer is uniformly distributed.
Is the Aviator formula the same as Stake’s?
The distribution logic is similar (both use an inverse mapping), but the constructions differ completely. Aviator uses SHA-512 over a server seed combined with client seeds from the first three players who bet in the round. Stake Crash uses HMAC-SHA256 over a pre-committed chain hash and a fixed public salt — no client seed or nonce is involved. The house edge also differs: Aviator uses 3%, Stake Crash 1%.
Can I recalculate a Bustabit crash point by hand?
In theory, yes — the formula is fully documented above. In practice, the 52-bit integers are too large for mental math. Use our Provably Fair Verifier (Bustabit mode, with both chain salts preset) or any programming language. The key steps: HMAC-SHA256 with the salt as key and the game hash bytes as message, extract 13 hex characters, convert to decimal, then apply 99 / (1 − X) with flooring and the 1.00× minimum — there is no divisibility check in the current implementation.
Why do different casinos show different crash points for the same hash?
Because the constructions differ, not just the constants. Different platforms use different HMAC argument orders, different salts, different bit counts (32 vs 52), and different formulas — so the same 64-hex string fed into two implementations produces entirely different crash points. That is also why a “universal” calculator that accepts any hash without asking which platform it came from cannot be trusted.