Quick answer: A SHA-256 hash becomes a crash point multiplier in 4 steps: (1) combine server seed + client seed + nonce via HMAC-SHA256, (2) take the first 8 or 13 hex characters, (3) convert hex to a decimal integer, (4) apply the crash formula with house edge. This page walks through each step with real numbers so you can follow the math yourself.
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, Roobet)
This formula is used by Stake Originals, Roobet, and other platforms with HMAC-SHA256 + 32-bit extraction.
Step 1: Generate the HMAC-SHA256 hash
Combine the server seed (as key) with the client seed, nonce, and cursor (as message):
key: “server_seed_revealed_after_round”,
message: “client_seed:nonce:0”
)
The :0 at the end is the cursor (game index within a single nonce). For crash games it’s always 0.
Server Seed:
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6Client Seed:
my_custom_seedNonce:
42HMAC-SHA256 message: my_custom_seed:42:0
Result hash: a3bf29c1e7d4f8b2... (64 hex characters)
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:
Step 3: Convert hex to decimal integer
Convert the 8-character hex string to a base-10 number:
// a = 10, 3 = 3, b = 11, f = 15, 2 = 2, 9 = 9, c = 12, 1 = 1
// = 10×16^7 + 3×16^6 + 11×16^5 + 15×16^4 + 2×16^3 + 9×16^2 + 12×16^1 + 1×16^0
// = 2,747,600,321
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 a 1% house edge (Stake):
= max(1, 1.5632 × 0.99)
= max(1, 1.5476)
= 1.54 // rounded down to 2 decimal places
The crash point for this round is 1.54x.
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.
House edge variants
| Platform | House Edge | Multiplier Factor | Same hex “a3bf29c1” produces |
|---|---|---|---|
| Stake, Roobet | 1% | × 0.99 | 1.54x |
| Aviator, JetX | 3% | × 0.97 | 1.51x |
| Spaceman | 3.5% | × 0.965 | 1.50x |
| F777 Fighter | 5% | × 0.95 | 1.48x |
Same hash, same integer, different crash points — because the house edge parameter differs.
Formula B: The 52-Bit Method (Bustabit)
This formula is used by Bustabit and classic Bustabit-derived crash games. It uses more bits for higher precision and enforces the house edge differently.
Step 1: Generate the HMAC-SHA256 hash
key: “game_hash_from_chain”,
message: “bitcoin_block_hash”
)
In Bustabit, the key is the game hash (from the pre-generated hash chain) and the message is a Bitcoin block hash that neither the operator nor players can predict.
Step 2: Check for instant crash
Before calculating the multiplier, check if the round is forced to crash at 1.00x:
if hashInt % 101 === 0:
return 1.00 // instant crash — ~0.99% of rounds
This is how Bustabit enforces its ~1% house edge: approximately 1 in 101 rounds crashes at 1.00x regardless of the hash value. This replaces the (1 − houseEdge) multiplier used in Formula A.
Step 3: Extract 13 hex characters (52 bits)
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 4: Apply the crash point formula
crashPoint = floor((100 * e – int52) / (e – int52)) / 100
This formula is often summarized informally as 0.99 × e / (e − h), though the actual implementation includes the floor/division steps shown above. The two notations describe the same logic but are not interchangeable in code.
Worked example (Bustabit)
3dfc2a1b7e...hex13 =
3dfc2a1b7e000int52 = hexToDecimal(“3dfc2a1b7e000”) = 1,099,243,192,090,624
Instant crash check:
hashInt (first 8 chars “3dfc2a1b”) = 1,040,308,763
1,040,308,763 % 101 = 62 ≠ 0 → not instant crash
Apply formula:
e = 4,503,599,627,370,496
crashPoint = floor((100 × 4,503,599,627,370,496 − 1,099,243,192,090,624) / (4,503,599,627,370,496 − 1,099,243,192,090,624)) / 100
= floor(449,260,719,544,959,200 / 3,404,356,435,279,872) / 100
= floor(131.96) / 100
= 1.31x
Both Formulas Side by Side
| Aspect | Formula A (232) | Formula B (52-bit) |
|---|---|---|
| Used by | Stake, Roobet | Bustabit, classic crash |
| Hash method | HMAC-SHA256(server, client:nonce:0) | HMAC-SHA256(gameHash, blockHash) |
| Bits extracted | 32 (8 hex chars) | 52 (13 hex chars) |
| House edge mechanism | Multiply by (1 − houseEdge) | ~1% instant crash (divisible by 101) |
| Formula | max(1, 232 / (int+1) × (1−HE)) | floor((100×e − int) / (e − int)) / 100 |
| Configurable RTP | Yes (HE parameter) | Fixed at ~99% |
| 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 hash, and you cannot get the hash without the server seed, 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.
Frequently Asked Questions
How do you convert a SHA-256 hash to a crash multiplier?
Take the HMAC-SHA256 hash of the combined seeds, extract the first 8 hex characters (for 232 method) or 13 hex characters (for 52-bit method), convert hex to a decimal integer, then apply the crash formula with the house edge parameter. The full step-by-step with example values is shown above.
What does “crash multiplier = 0.99 × e / (e − h)” mean?
This is the simplified form of the Bustabit 52-bit formula. e = 2^52 (a constant), h is the integer derived from the hash, and 0.99 reflects the ~1% house edge enforced via the instant crash mechanism (divisible by 101). Note: in Formula A (Stake-style), you can directly change the house edge parameter (e.g., 0.97 for 3%). In Formula B (Bustabit-style), the house edge is structurally baked into the instant crash check, not a simple multiplier swap.
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 crash point formula logic is similar (both use the inverse-distribution approach), but the seed combination method differs. Aviator uses SHA-512 with client seeds from three players, while Stake uses HMAC-SHA256 with a player-set client seed and nonce. The house edge also differs: Aviator uses 3%, Stake uses 1%. The formula step (hash → multiplier) follows the same mathematical principle.
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 or any programming language that supports big integers. The key steps: get the HMAC-SHA256 hash, extract 13 hex characters, convert to decimal, check for divisibility by 101 (instant crash), then apply the formula.
Why do different casinos show different crash points for the same hash?
Several reasons. Within the same formula family (e.g., Stake-style 232), the difference is the house edge parameter: the same hex “a3bf29c1” produces 1.54x at 1% edge but 1.51x at 3% edge. Across different formula families, differences also come from the seed combination method (HMAC-SHA256 vs SHA-512), the number of bits extracted (32 vs 52), and the house edge mechanism (multiplier vs instant crash). Two platforms using different formula families will produce entirely different crash points from the same raw inputs.