Quick answer: There is no single universal crash game algorithm. Published implementations usually combine a commitment system, an input the operator cannot change after commitment, a cryptographic hash or HMAC, and a game-specific formula that maps part of the output to a multiplier. Stake Crash publicly documents a 32-bit formula linked to its hash-chain seeding event. BC.Game and the current Bustabit verifier use a 52-bit inverse-distribution formula. Spribe publicly documents SHA-512 seed combination for Aviator, but it does not publish the exact multiplier-conversion formula on its public Provably Fair page.
Most explanations stop at “the game uses SHA-256.” That is incomplete. A hash function produces a fixed-length digest; it does not decide by itself whether a round ends at 1.00×, 2.37×, or 500×. The multiplier appears only after the implementation selects part of the digest, converts it into a number, applies a distribution formula, and enforces rounding, minimums, caps, and the house edge.
This guide separates verified implementations from generic crash-game theory. It uses current public documentation from Stake, BC.Game, Bustabit, Spribe, and the NIST Secure Hash Standard. For a non-technical explanation of the betting round itself, read How Crash Games Work.
Important distinction: Similar-looking crash games can use different algorithms. Never take a formula published for Stake, BC.Game, Bustabit, or an old open-source crash script and assume it reproduces Aviator or another provider’s results.
Crash Game Algorithms at a Glance
| Game / platform | Public commitment model | Digest and numeric input | Published multiplier mapping | Evidence level |
|---|---|---|---|---|
| Stake Crash | 10 million SHA-256 hashes released in reverse order; future Bitcoin block hash used as an external salt in the published seeding event | HMAC-SHA256; first 8 hex characters, or 32 bits | max(1, (2^32 / (n + 1)) × 0.99) | Stake’s current documentation links to the original seeding thread |
| BC.Game Crash | 10 million verifiable hashes released in reverse order | First 13 hex characters, or 52 bits, converted to X in [0, 1) | max(1, floor(99 / (1 − X)) / 100) | Official BC.Game white paper |
| Bustabit v2 | Verifiable hash chain with a public salt or signature | HMAC-SHA256; first 13 hex characters, or 52 bits | max(1, floor(99 / (1 − X)) / 100) | Official verified Bustabit GitHub repository |
| Aviator by Spribe | Hashed server seed published before the round; server and player seeds combined for verification | Spribe documents a combined seed hashed with SHA-512 | Exact Aviator multiplier mapping is not published on Spribe’s public page | Official Spribe documentation, with a public-detail limit |
The table shows why “the crash game formula” is an unsafe phrase. Stake and BC.Game both use pre-generated chains in their published Crash systems, yet the documented bit width and mapping formula differ. Bustabit and BC.Game use a similar 52-bit inverse formula, but they do not necessarily construct the hash input in the same way. Aviator uses a documented SHA-512 seed-combination process, while its exact multiplier conversion remains provider-specific.
The Five Layers Between a Seed and a Crash Point
1. Commitment
The operator commits to hidden data before the relevant result is revealed. A platform may publish the hash of a server seed or the terminating value of a long hash chain. Because changing the hidden value also changes its hash, the commitment can later expose tampering.
2. An Uncontrollable or Pre-Committed Input
A commitment prevents silent changes, but it does not automatically prove that the operator selected a fair sequence. Some systems add a future Bitcoin block hash, player-generated seeds, or another value that was unknown when the operator committed its own input. Other systems use a server seed, client seed, and nonce for each player’s bets.
3. Hash or HMAC Calculation
The inputs are processed by SHA-256, HMAC-SHA256, SHA-512, or another documented cryptographic construction. SHA-256 and SHA-512 are standardized hash functions; HMAC adds a keyed construction around a hash function. The order of the key and message matters, so swapping them produces a different result.
4. Number Extraction
The implementation selects a defined portion of the digest. Stake’s published Crash seeding code takes 8 hexadecimal characters, giving a 32-bit integer. The current Bustabit verifier takes 13 hexadecimal characters, giving 52 bits that can be represented exactly by JavaScript’s integer precision.
5. Distribution, House Edge, and Rounding
The extracted number is mapped to a heavy-tailed multiplier distribution. The implementation may insert the house edge through a factor such as 0.99, a numerator such as 99, an instant-bust rule, a payout table, or another method. Flooring to two decimals, setting a minimum of 1.00×, and applying a maximum multiplier also affect the final displayed result.
Stake Crash Algorithm: The Published 32-Bit Formula
Stake’s current Provably Fair game-events page treats Crash differently from most single-player Stake Originals. Instead of pointing to the standard server-seed, client-seed, nonce, and cursor implementation, it links to the platform’s Crash seeding event and describes Crash as using a salt-hash-based model.
In that published event, Stake generated a chain of 10 million SHA-256 hashes. It then used the hash of Bitcoin block 584,500, which had not yet been mined when the commitment was posted, as the external input. The game hash is the HMAC key; the Bitcoin block hash is the HMAC message.
// Stake Crash formula published in the 2019 seeding event
gameHash = hashChain.pop()
hmac = HMAC_SHA256(
key = gameHash,
message = bitcoinBlockHash
)
hex8 = hmac.slice(0, 8)
n = parseInt(hex8, 16)
rawCrashPoint = max(
1,
(2^32 / (n + 1)) * 0.99
)Illustrative 32-Bit Calculation
hex8 = "7eb851ea"
n = 2,126,008,810
rawCrashPoint
= (4,294,967,296 / 2,126,008,811) * 0.99
= approximately 2.0000000005This example illustrates the conversion, not a real historical round. The short seeding-event code publishes the raw formula but does not specify every display-layer detail, such as whether a particular interface truncates or rounds the final decimal. Verification should therefore compare the exact platform result with the platform’s current verifier and round data.
Correction to a common claim: Stake Crash should not be described as an ordinary per-player Stake Originals calculation using serverSeed:clientSeed:nonce:cursor. Stake’s own game-events documentation points Crash to a separate salt-hash seeding model.
BC.Game Crash Algorithm: The Published 52-Bit Formula
BC.Game’s white paper describes a chain of 10 million hashes, with each hash corresponding to one Crash multiplier and the sequence released in reverse order. Its worked example takes the first 13 hexadecimal characters of a game hash, converts them to a 52-bit integer, normalizes that integer to a number between 0 and 1, and applies an inverse formula.
// BC.Game Crash mapping from the official white-paper example
h = parseInt(gameHash.slice(0, 13), 16)
X = h / 2^52
rawHundredths = 99 / (1 - X)
crashPoint = max(
1,
floor(rawHundredths) / 100
)BC.Game’s Published Worked Example
gameHash =
"6b5124897c3c48d0e46cc9249f08c7e560792459f1bad1171224643b5d2be231"
hex13 = "6b5124897c3c4"
h = 1,887,939,992,208,324
X = 0.419206889692064
rawHundredths = 99 / (1 - X)
= 170.4565674815...
crashPoint = floor(170.4565...) / 100
= 1.70xThe number 99 embeds a 1% house edge into this idealized mapping. Values below 1.00× are consolidated at the 1.00× minimum. This is mechanically different from multiplying a 32-bit formula by 0.99, even though both models target a similar long-run edge.
Bustabit v2: Similar 52-Bit Math, Different Inputs
The current official Bustabit verifier uses the same main inverse-distribution family as the BC.Game example, but it first calculates an HMAC-SHA256 value from the game hash and a chain-specific salt or signature. It then reads the most significant 52 bits of that HMAC result.
// Simplified from the current official Bustabit v2 verifier
hmacHex = HMAC_SHA256(
key = saltOrSignature,
message = gameHash
)
seed = hmacHex.slice(0, 13)
r = parseInt(seed, 16)
X = r / 2^52
crashPoint = max(
1,
floor(99 / (1 - X)) / 100
)Historical-code warning: Many tutorials label a divisible(hash, 101) instant-bust check as “the Bustabit formula.” That rule appears in older crash implementations and copied MoneyPot-style code. It is not present in the current official Bustabit v2 verifier’s multiplier function. Treat it as implementation-specific historical code, not a universal or current Bustabit rule.
Bustabit’s verifier also supports more than one hash-chain generation and contains chain-specific details about whether the binary hash or its hexadecimal representation is hashed to move through the chain. Those details matter for exact verification. The simplified pseudocode above explains the multiplier mapping, not the entire chain verifier.
Can You Convert SHA-256 Directly to an Aviator Multiplier?
Not with a universal public formula. Spribe’s public Provably Fair explanation says that it combines a server seed with player-generated client seeds and hashes the combined input with SHA-512. It also states that each game uses different mathematics to turn the SHA-512 output into a result. The public page does not publish Aviator’s exact multiplier-conversion code.
That makes the search phrase “convert SHA-256 to Aviator multiplier” technically misleading in two ways:
- Spribe publicly describes SHA-512, not a generic SHA-256 conversion, for its combined seed.
- A digest alone is insufficient unless you know the exact byte selection, numeric conversion, house-edge implementation, rounding, minimum, and cap rules used by Aviator.
Spribe does provide round-level verification inside the game: the player can inspect the server seed, player seeds, combined hash, and result after a round. That verifies the provider’s calculation through its disclosed interface, but it is not the same as publishing a standalone open-source Aviator multiplier formula.
Do not trust a calculator merely because it accepts a hash. A tool that claims to reproduce Aviator from any SHA-256 string must identify its primary source and exactly match Spribe’s current round data. Without that evidence, the output is a guess or a formula copied from another crash game.
Crash Game Mathematics: How the House Edge Enters the Formula
The house edge is an expected-value property, not a promise that the operator earns exactly that percentage in every session or every day. Short samples can produce large wins or losses for either side. Over a sufficiently large number of independent wagers, the average return tends toward the game’s theoretical RTP if the implementation and stated parameters are accurate.
| Implementation method | How the edge appears | Example |
|---|---|---|
| Formula scaling | The raw inverse multiplier is multiplied by an RTP factor before the minimum floor | Stake’s published × 0.99 formula |
| Reduced numerator | The inverse formula uses 99 rather than 100, then floors to hundredths | BC.Game and current Bustabit verifier |
| Instant-bust probability | A defined fraction of digest values returns the minimum result directly | Some historical and provider-specific crash implementations |
| Outcome table or other mapping | The edge is embedded in a game-specific payout distribution | Closed or proprietary provider implementations |
In an ideal uncapped inverse crash model with RTP r, the probability of reaching at least multiplier m is approximately r / m. Therefore a fixed cash-out target does not remove the edge: the payout becomes larger as the probability becomes smaller. Real games can differ because of flooring, maximum multipliers, instant-bust handling, and implementation-specific rules. The full probability treatment belongs in the Crash Game Odds Guide, while verified provider RTP values belong in the Crash Game RTP Guide.
Why Past Multipliers Do Not Reveal the Next Result
A properly implemented hash chain is deliberately one-way. Once a game hash is revealed, anyone can hash it forward to confirm its relationship with a previously committed value. The public commitment does not provide the unrevealed preimage needed for the next round. A future block hash or unrevealed salt can add another input that was unavailable when the chain was selected.
Likewise, a server-seed commitment allows later verification without revealing the active server seed in advance. Historical multipliers do not expose that hidden value. Statistical streaks will appear naturally in random-looking data, but they do not provide the missing cryptographic input.
Precise conclusion: Predicting future crash points from public round history, visible commitments, or chart patterns is not practically feasible when the system is correctly implemented. A genuine advance prediction would require leaked hidden inputs, a weak seed, an implementation flaw, or a compromised server — not a pattern-recognition app.
For the security and scam analysis, see Can You Predict Crash Games?. That page covers predictor APKs, Telegram signals, fake activation codes, and the difference between verification and prediction.
What Provably Fair Verification Actually Proves
Provably Fair verification can show that the disclosed inputs reproduce the displayed result and that a committed seed or hash chain was not changed after commitment. It does not automatically prove that the advertised RTP is correct, that the operator will process withdrawals, that the casino is licensed in your jurisdiction, or that the provider’s undisclosed implementation contains no bugs.
For a practical round-by-round process, use the Crash Game Hash Verification Guide. For the broader trust model — server seeds, client seeds, nonces, commitments, and limitations — read Provably Fair Explained.
Bottom Line
A crash game algorithm is not simply “SHA-256 plus a multiplier.” It is a pipeline. The commitment prevents silent changes, an external or player-controlled input can reduce unilateral control, the hash or HMAC produces a deterministic digest, and a provider-specific mapping turns part of that digest into the crash point.
The most important practical lesson is that formulas are not interchangeable. Stake’s published Crash model uses a 32-bit HMAC result and a 0.99 scaling factor. BC.Game and the current Bustabit verifier use 52-bit inverse mappings with 99 / (1 − X), but construct their inputs differently. Spribe publicly documents SHA-512 seed combination for Aviator without publishing the exact multiplier mapping. Any technical guide or calculator should identify which implementation it reproduces and cite the primary source.
Frequently Asked Questions
What algorithm do crash games use?
There is no universal algorithm. Common components include SHA-256 or SHA-512, HMAC, server or game seeds, client seeds or external salts, hash-chain commitments, and an inverse formula that maps a 32-bit or 52-bit number to a multiplier. The exact input order, bit width, house-edge method, rounding, and maximum result depend on the game.
What is the published Stake Crash formula?
Stake’s current documentation links to its Crash seeding event, which publishes max(1, (2^32 / (n + 1)) × 0.99). The integer n comes from the first 8 hexadecimal characters of an HMAC-SHA256 result using the game hash and a predetermined Bitcoin block hash.
What is the BC.Game Crash formula?
BC.Game’s white-paper example takes the first 13 hexadecimal characters of a game hash, sets X = n / 2^52, and calculates max(1, floor(99 / (1 − X)) / 100). The number 99 and the flooring to hundredths are part of the published 1% house-edge model.
Does Bustabit still use the divisible-by-101 instant-crash rule?
The current official Bustabit v2 verifier does not use that check in its multiplier function. It calculates HMAC-SHA256, extracts 52 bits, and applies floor(99 / (1 − X)) / 100 with a 1.00× minimum. The divisible-by-101 rule belongs to older or different crash implementations.
How do I convert SHA-256 to an Aviator multiplier?
Spribe does not publish a universal SHA-256-to-Aviator formula. Its public Provably Fair page describes combined server and player seeds hashed with SHA-512 and says each game uses its own result mathematics. Use Aviator’s round-verification interface rather than applying a Stake, BC.Game, or Bustabit formula to an arbitrary hash.
Can a crash game hash be reversed to predict the next result?
Not in practice when the seed has adequate entropy and the cryptographic implementation is correct. Public commitments are designed for verification after disclosure, not calculation of the hidden preimage in advance. Prediction would require leaked secrets, weak inputs, a software flaw, or server compromise.
Does a 1% house edge guarantee the casino makes exactly $1 per $100 wagered?
No. It means the theoretical expected loss is $1 per $100 of turnover over a very large sample under the stated model. Actual short-term results vary, sometimes substantially. RTP and house edge describe long-run expectation, not a fixed charge applied to each player session.
Primary Sources and Implementation Notes
- Stake Provably Fair: Game Events — the current page directs Crash to its salt-hash seeding model.
- Stake.com Crash Seeding Event — published 10-million-hash chain, Bitcoin block salt, and 32-bit formula.
- BC.Game White Paper: Provably Fair — hash chain and 52-bit worked example.
- Bustabit Official Verifier: Multiplier Math — current 52-bit HMAC mapping.
- Bustabit Official Verifier: Hash-Chain Logic — current and previous chain handling.
- Spribe Provably Fair — server seed, player seeds, combined seed, and SHA-512 description.
- Spribe Aviator — official game page and 97% RTP disclosure.
- NIST FIPS 180-4 — Secure Hash Standard covering SHA-256 and SHA-512.
Last implementation review: July 23, 2026. Providers can change algorithms, seeds, chain generations, verifier code, rounding, or maximum multipliers. Recheck the linked primary source before using any formula to verify a current round.
Related Guides and Tools
- SHA-256 to Crash Multiplier Formula — a calculation-focused walkthrough with intermediate values
- Crash Game Hash Verification — verify completed rounds step by step
- Provably Fair Explained — commitments, seeds, nonces, HMAC, and limitations
- Crash Game Odds — probability at each cash-out multiplier
- Crash Game RTP & House Edge — verified RTP values and expected session cost
- Can You Predict Crash Games? — cryptographic limits and predictor scams
- Multiplier Probability Calculator — calculate idealized reach probability for a target multiplier