A crash game's randomness comes from a pseudorandom number generator (PRNG). Modern PRNGs, when seeded properly, produce sequences that are statistically indistinguishable from true randomness for any practical purpose. This article explains how PRNGs work inside a crash game, what "seeded properly" means, and how a cheating operator could still produce a passing result if nobody is watching.
What is a pseudorandom number generator?
A pseudorandom number generator (PRNG) is an algorithm that takes a starting value, called a seed, and produces a long sequence of numbers that appear random. "Pseudo" means the numbers are not truly random: given the same seed, the same algorithm will produce the identical sequence every time. But if you do not know the seed, you cannot distinguish the output from genuine randomness.
Every crash game uses a PRNG. The PRNG produces a number for each round, and that number is converted into the crash multiplier. The specific algorithm varies. Most provably fair implementations build on HMAC-SHA256 or a chain of SHA-256 hashes. Games that rely on a lab-certified generator, such as Spaceman and High Flyer, do not publish theirs, and the lab certificate is what vouches for it.
The quality of the PRNG matters enormously. A weak PRNG, one with low entropy, short cycle length, or predictable output, could allow an attacker to predict future rounds from observed past rounds. A strong PRNG makes this computationally infeasible.
What "strong" means in practice: A cryptographic PRNG like HMAC-SHA256, seeded with 256 bits of entropy, cannot be cracked by trying seeds: there are about 10^77 possible seeds, far beyond what any existing computer could search. For practical purposes, a properly seeded cryptographic PRNG produces output that is indistinguishable from true randomness.
How does a crash game turn a random number into a multiplier?
The conversion from random number to crash multiplier follows a specific mathematical formula. The formula is designed to produce the target distribution, the shape that makes crash games work as a gambling product.
The target distribution: In a crash game with house edge h, the crash multiplier m is drawn from a distribution where the probability of reaching at least m is approximately (1-h)/m. This produces:
- Many low crashes (roughly 50% below 2.0× for a 3% edge game)
- Progressively fewer high multipliers
- Occasional extreme values (100×, 500×, 1000×+)
A simplified example of the conversion:
1. The generator produces a 256-bit hash:
"a7f3b2c1d4e5..."
2. Part of the hash is read as a large integer and scaled
to a uniform number U between 0 and 1.
3. The formula applies:
multiplier = (1 - house_edge) / U
multiplier = max(1.00, floor(multiplier × 100) / 100)
4. Result: for example, crash point = 2.47×
The exact formula varies by game. In provably fair games it is documented as part of the fairness specification, so a revealed seed can be turned back into the result. Aviator is provably fair; its server seed can be checked against the hash shown before the round. In hash-committed games such as JetX, a hash of the result is published, but no formula from hash to result. In certified-RNG games such as Spaceman, players see neither.
With this formula and rounding down to two decimals, every draw below 1.01× shows as 1.00×, so the share of rounds that end at once is about h + (1 − h)/101: roughly 2% in a game designed at 99%, 4% at 97%. Some implementations add a separate instant-crash rule instead. Either way, the house edge is built into the conversion, and the rest of the rounds follow the familiar crash-game shape: many low results and a long tail of high ones.
How do you convert an Aviator hash into its multiplier?
People often search for how to turn Aviator's SHA-256 hash into the multiplier. The SHA-256 hash is not where the multiplier comes from. It is the commitment: a fingerprint of the server seed, shown before the round, so the seed cannot be swapped afterwards. The multiplier comes from a SHA-512 hash computed after the round. These are the steps Aviator uses. The lab recomputed more than 21,000 recorded Aviator rounds this way in October 2026, and every one matched the published result.
1. Before the round: Aviator shows SHA-256(server seed).
2. After the round: the server seed and the client
seeds of the first three players are revealed.
3. Join them, in that order, and hash with SHA-512:
h = SHA-512(server seed + seed 1 + seed 2 + seed 3)
4. Read the first 13 hex characters of h as a number,
and divide by 2^52 to get X between 0 and 1.
5. multiplier = max(1.00, floor(97 / (1 − X)) / 100)
6. Check: SHA-256(server seed) must equal the hash
shown in step 1.
Steps 5 and 6 are the whole check. If step 5 gives the multiplier the game showed, the result followed the formula. If step 6 matches, the server seed was fixed before the round. The 97 in step 5 is where the 97% return is built in.
This works only backwards. The next round's server seed stays hidden until that round has ended, so the formula cannot tell you what comes next. Our step-by-step guide shows how to run the hashes in a browser, and the hash commitment check runs step 6 for you. The Aviator provably fair calculator runs steps 3 to 6 on a round you paste in and shows each value.
What does it mean to "seed" the RNG?
The seed is the starting value that determines the entire output sequence of the PRNG. A good seed must have two properties:
High entropy. Entropy measures unpredictability. A seed derived from the current timestamp has low entropy. There are only so many possible timestamps, and an attacker who knows approximately when the seed was generated can narrow the possibilities. A seed drawn from a cryptographically secure source of randomness has high entropy: the number of possible seeds is astronomically large.
Secrecy. The seed must remain secret while it is in use. If an attacker learns it, they can predict every round it produces. In a provably fair system the seed is revealed only after it is retired, when it no longer produces rounds.
Two commitment designs are common, and they work differently. Hash chains, used for shared rounds, generate a long chain in advance, each hash the hash of the next, publish its end before play, and reveal one link per round; the order of every future round is fixed from the start, so there is nothing to rotate. Per-player seeds are retired and replaced over time: when a seed is rotated, the old one is revealed for checking and a new one, whose hash was already published, takes over.
In the per-player design, the rotation process itself is a potential vulnerability. If an operator times rotations to coincide with specific player behaviors (large incoming bets, for example), they could influence the distribution of outcomes even though each individual round passes hash verification. This is the timing question described in Seed Rotation. It is a known limit of what a hash check covers.
How can you tell if an RNG is well-seeded or broken?
You cannot tell from a single round or even a few dozen rounds. A broken RNG and a working RNG produce output that looks the same to the naked eye. Detection requires statistical analysis of large samples.
Tests that statisticians apply:
Distribution testing. Collect thousands of crash multipliers and compare the observed distribution to the theoretical distribution, with chi-squared goodness-of-fit or Kolmogorov-Smirnov tests. If the observed distribution deviates significantly from theory, the RNG or the game's parameters are suspect. See Reading the Multiplier Distribution.
Serial correlation testing. Check whether knowing round N's outcome helps predict round N+1. In a properly functioning RNG, consecutive rounds should be independent: the correlation coefficient should be statistically indistinguishable from zero. If rounds are correlated, the RNG may be cycling too short or the seed may have insufficient entropy.
Runs testing. Examine the sequence of above-median and below-median outcomes. In a truly random sequence, "runs" (consecutive outcomes on the same side of the median) follow a predictable distribution. Too many long runs or too few suggest the RNG is not random.
Birthday spacing test. Check whether the gaps between repeated values in the PRNG output match the expected distribution. Deviations can reveal internal state collisions in weak PRNGs.
Autocorrelation at lag k. Test whether outcomes separated by k rounds are correlated, for various values of k. This can detect subtle periodicities in the PRNG output that are not visible in consecutive-round analysis.
These tests require thousands to tens of thousands of rounds to achieve statistical power. This is why the lab publishes nothing for a game until it has counted at least 10,000 rounds, and why every figure carries its sample size and interval. See Evidence Tiers.
What does a rigged crash game look like, mathematically?
A rigged crash game is one where the RNG output is manipulated to produce a distribution that differs from the declared parameters, typically to increase the house edge beyond what is advertised.
Method 1: Parameter fraud. The operator advertises 97% RTP but uses a formula that produces 93% RTP. Every round passes provably fair verification (the hash chain is honest), but the formula that converts hashes to multipliers includes a higher house edge than disclosed. This is detectable only through large-sample counting of the return and the distribution.
Method 2: Selective seed rotation. The operator monitors incoming bets. When a large bet is placed, the operator rotates to a new seed that was pre-selected to produce a low crash point for the next few rounds. The new seed's hash was already committed, so the hash check passes. But the timing of the rotation is correlated with player behavior, which violates the independence assumption. Detection requires testing whether rotation events cluster around high-wager periods.
Method 3: Weak PRNG. The operator uses a PRNG with insufficient entropy or a short cycle length. The output can look random and even pass statistical tests, yet someone who knows or reconstructs the generator's state could predict future rounds. The risk is predictability, not a visibly odd distribution; tests catch only the cruder weaknesses.
Method 4: RNG bypass. In non-provably-fair games, the operator could simply bypass the RNG for specific rounds and insert predetermined outcomes. Without a hash-commitment scheme, there is no mechanism for players to detect this. This is the fundamental weakness of RNG-only systems, and the fundamental strength of provably fair.
Why does independent measurement matter even with provably fair RNGs?
Provably fair proves that each round's commitment was honored. It does not prove:
- That the formula is fair (parameter fraud)
- That the seed rotation timing is fair (selective rotation)
- That the PRNG has adequate entropy (weak PRNG)
- That the overall distribution matches the declared RTP (systemic deviation)
These gaps are why independent measurement matters. A hash check covers per-round integrity. A large count of rounds, published with its interval, covers the overall return and the shape of the distribution. Our hash commitment check does the first in your browser; the lab's game pages carry the second once a game passes its minimum sample.
No single verification method is complete. Hash checks without distribution analysis miss parameter fraud. Distribution analysis without hash checks misses per-round manipulation. Both together, the combination of cryptographic verification and statistical auditing, provide the most comprehensive picture of whether a crash game is operating as advertised.
The principle is that trust is layered, not binary. A game is not simply "fair" or "unfair." It is more or less checkable across several independent dimensions, and each game page states which checks apply to it. See the games list for each game's fairness badge and lab status.
Can knowing how the RNG works help predict a round?
No. Knowing the algorithm without the secret seed tells you nothing about the next result, and reversing a seed from past outputs is computationally out of reach for any properly built generator. That is why predictor apps cannot work; see the predictor bots check. Past results do not shift the next one either. History describes behaviour. It does not predict the next round.
Was this page useful?
Anonymous: no account and no cookie.