The moments that start the argument
Nobody asks this question as a general enquiry into random number generation. It arrives attached to a specific bad evening.
Nine rounds busting under 1.5×. The plane dying at 1.01× the one time there was real money on it. A 50× round landing in the gap while you were topping up your balance. Those moments feel targeted, and the obvious explanation is that something saw your stake and reacted to it. That is a common selective-memory pattern, not evidence about the game: the rounds that stung are the ones that stayed with you.
That suspicion is worth taking apart, because two different things get filed under the same word. Part of what you are feeling is the game doing precisely what its published maths says it will do. Another part would be straightforward cheating if it were happening. They have different answers and different tests, so it is worth knowing which one you are actually accusing the game of.
The edge is disclosed; altering results is not
Start with the designed-in part. Crash games take a fixed slice out of the payout maths, so across many rounds the operator keeps a small share of everything wagered. At a 2× cash-out target the average return in the simple model used on this page comes out at 97.00% of the stake, and with un-rounded payouts that same average holds whichever target you choose. Move from 1.3× to 10× and you change how often you win and how hard your balance swings, while the long-run return stays where it was. Low targets bring frequent small wins and smaller swings from round to round; high targets lose more often and pay out rarely but in bigger amounts. That trade-off surprises people more than the edge itself does.
So a brutal losing night is entirely compatible with an honest game. The edge does not need to watch you or respond to you. It sits in the formula and applies to everyone identically, round after round, which is also why a game can be fully verifiable and still grind your bankroll down.
The heavier accusation is the other one. That an operator sees the bet come in and quietly pushes the crash point down to avoid paying it. That is a result changed after the fact, and it is the thing commitment schemes were designed to make impossible.
The mechanism is old enough to follow without any cryptography background, and it has a traceable history. Hash commitments of this kind spread through Bitcoin dice sites in the early 2010s, and the crash games that arrived later inherited the design in various forms. What follows is the example scheme documented on our verifier page; real games commit and randomise in their own ways, and many of them never publish the details. In this scheme, before bets open the operator generates a secret server seed and publishes its SHA-256 hash. SHA-256 is a one-way fingerprint function from NIST, issued as a draft in 2001 and finalised in FIPS 180-2 in 2002, with no known practical way to run it backwards. The hash gives away nothing useful about the seed, but it pins the seed down, because changing the seed afterwards makes the fingerprint stop matching.
Each round then runs that still-secret server seed, a client seed and a nonce through HMAC-SHA256. The client seed is set by you, or generated for you. The nonce is a counter that ticks up by one each round, which is what lets a single pair of seeds produce a long series of different results. Feed the same nonce back in and you get the same result back. That is expected behaviour. The output is a long hexadecimal string, and the game turns the first chunk of it into a number, then into a bust point through a published formula. Nothing in that path can look at your stake, because your stake is never one of the inputs. Other providers use different byte layouts, different formulas, sometimes a different commitment structure altogether.
The reveal comes later, usually when the seeds rotate. The operator publishes the server seed in full; hash it yourself and you should land on exactly the commitment that was shown before you played, then re-run the formula and you should recover every round you played under that pair. The timing is the part people trip over. The seed cannot be published while it is still in use, because anyone holding it could compute the next bust point before placing a bet. So verification is always retrospective, on rounds that are already settled.
The client seed is carrying more weight here than people realise. Without it, an operator could sit and search for a server seed whose results suit the house against a particular player. That search only becomes impractical if your client seed is genuinely unknown and unpredictable to the operator at the moment it commits to the hash. A seed that is nominally yours but was assigned by the site, left at a default, or taken from your username is no obstacle at all. So three things have to hold: the hash is committed and recorded somewhere checkable before your client seed is fixed, the client seed is one the operator could not have anticipated, and it is never quietly overwritten afterwards. If a site sets your client seed for you and won't let you change it, the whole structure collapses back into trust.
Watch it work on seeds you control
This is the part worth doing with your hands. The provably fair verifier implements that one open scheme, where every step is visible. Fix the server seed and the client seed and the first five rounds come out as below; anyone can recompute them in any browser from the seeds alone.
| Nonce | Crash bust | Verify |
|---|---|---|
| 0 | 4.26× | check nonce 0 |
| 1 | 1.46× | check nonce 1 |
| 2 | 3.60× | check nonce 2 |
| 3 | 1.41× | check nonce 3 |
| 4 | 1.59× | check nonce 4 |
serverSeed "cashoutodds-demo-v1" hashes to add850c92de9586e… (match: yes) Those bust points are demo rounds from the scheme above, not a live game's figures. Follow any check link and that bust point is rebuilt from the server seed, client seed and nonce, in your browser, where the scheme is written out and the inputs are yours to change. Alter one character of the client seed and the whole series goes somewhere else entirely, which is the quickest way to see why a hash committed in advance matters at all.
What a passing check buys you is narrow and real. The result you saw is consistent with a seed committed to before the round, under the scheme being checked and the inputs you were handed. A failed check is much weaker evidence than players assume. A pasted seed with a trailing space, a dropped digit in the nonce, numbers run against a different scheme altogether, all produce mismatches. Re-check your inputs before you draw conclusions. And a passing check leaves these completely untouched:
- Whether payouts are processed correctly or promptly. A fair result can still be followed by a withdrawal dispute.
- Whether the operator holds a valid licence. Verifying a round tells you nothing about licensing.
- Whether the advertised RTP is the build actually deployed. The check confirms round-against-seed consistency, not which payout table was in use.
- Whether the seed was picked to favour the house, or whether some rounds were cancelled and never shown. A consistent result can still sit inside a rigged selection.
Aviator itself is outside what can be tested here, as is any other branded game. Providers run their own servers and their own seed schemes, often undisclosed. What can be shown is the mechanism, running on seeds you set yourself.
Streaks, licences and the uncomfortable bit
Most stories told as rigged-game stories turn out, read closely, to be stories about an operator nobody can identify. So before blaming an algorithm, check that the site publishes a licence number tied to a named regulator, that the number is confirmable on the regulator's own public register under the operating company's real legal name, and that each crash, Mines or Plinko title names the provider behind it. We don't recommend or name specific casinos or regulators. Look the number up yourself. A footer badge is just an image file.
Which brings us back to the nine busts. Crash is unusually good at manufacturing that impression, and the format is partly responsible. Rounds last seconds, so an hour at the table runs to dozens of outcomes, and every one of them is logged in the history strip running along the top of the screen. Slow games hide their clumps; this one displays them, colour-coded, as a permanent scoreboard sitting above the betting panel. A short run of low busts is ordinary in any sequence of independent results, but here you watch it accumulate in real time with a row of red numbers confirming it, and that reads as a pattern. Tversky and Kahneman gave this its name in 1971, writing about belief in the law of small numbers: we expect short runs to look like the long-run average, and they rarely do.
It cuts both ways, too. A hot streak doesn't show a game is generous, and plenty of players have decided a site was paying well on evidence no stronger than the evidence they'd use to call it crooked. The only thing genuinely testable is whether a given round matches a seed committed to before it was played. Your sense of how the evening went is not a measurement.
So "is it rigged" and "did I lose money" come apart. You can play a verified, flawlessly fair game every single round and still finish behind, because the edge makes that the average outcome. The expected loss calculator puts a figure on that for your stake, round count and house edge.
And if you find yourself re-running verifications at 2am, or adding rounds to settle whether the game is honest, the honesty of the game has stopped being the issue. The responsible gambling page lists places to get support.




