Aviator provably fair: verify a round yourself

The problem it solves

In an ordinary online casino game you are asked to trust that the operator's random number generator is honest. Maybe a testing lab audited it, months ago, on a build that may or may not be the one you are playing.

Provably fair replaces trust with arithmetic. The operator publishes a commitment to the result before betting opens — a cryptographic hash — and reveals the ingredients afterwards. Because a hash cannot be reversed and cannot be made to match a different input, an operator that changed the result after seeing the bets would produce a hash that no longer matches what it published. Anyone can check, and the check is cheap.

How Aviator does it

Aviator's implementation has one distinctive feature: the players supply part of the randomness.

Those four values are combined and hashed with SHA-512; the resulting hash determines where the plane crashes.

The design point is that no single party controls the result. Spribe controls the server seed but not the three player seeds. A player controls their own seed but not the server's, and not the other two players'. The result does not exist until real bets from real players have arrived — which is why nobody, including the operator, can know it in advance.

Your own client seed is visible and editable in the game's Provably Fair settings. Changing it is worth doing once, not because the old one was suspect, but because doing it makes concrete that it is genuinely yours.

How to verify a round, step by step

Inside Aviator:

1. Open the menu (☰) and choose Provably Fair — or tap the shield icon next to a round in the history bar.
2. Pick a completed round. You can only verify rounds that have finished; that is the whole point of the commitment scheme.
3. Read the four seeds: the now-revealed server seed and the three client seeds, in the order shown.
4. Copy the round's SHA-512 hash as displayed by the game.
5. Recompute it. Concatenate the seeds exactly as the game presents them — same order, no extra spaces — and run SHA-512 over the result with any hash tool. The game also links its own verifier.
6. Compare. Identical hash means the round used exactly those inputs, decided before your bet, and unaltered afterwards. A mismatch would mean the inputs were not what was published — which is what the whole scheme exists to detect.

The commitment side works the same way in reverse: the SHA-256 hash of the server seed is published before betting opens, so once the seed is revealed you can confirm it hashes to the value that was posted in advance.

What the hash-to-multiplier step actually is

This is where most guides quietly overstate things, so we will be blunt.

The standard model in crash games converts the first 13 hex characters of the round hash into a number and applies:

e = 2^52
h = parseInt(hash.substring(0, 13), 16)
multiplier = floor((100 * e - h) / (e - h)) / 100

That formula produces exactly the distribution the game behaves like — a 97% RTP crash curve where P(reach x) = 0.97 ÷ x, including the ~3% of rounds that die instantly at 1.00×.

But Spribe has not published its production source, so treat that conversion as the widely used model of the mechanism rather than a verbatim copy of Spribe's code. Rounding, input formatting and seed concatenation order are implementation details that vary between operators and builds.

What you can verify without any of that ambiguity is the part that matters most: the hash match. That is what proves the round's inputs were fixed before betting and not touched afterwards. Anyone showing you a "verified crash prediction" has skipped the fact that the verification only ever runs backwards.

What provably fair proves — and what it does not

That third column deserves its own paragraph, because it is where players get hurt. Provable fairness is a statement about the game engine, not about the casino operating it. A fully fair Aviator round can sit inside a platform that runs a lower RTP configuration, sets punishing withdrawal terms, or simply stops paying. Fairness of the round and trustworthiness of the operator are separate questions, and the second one is not solved by cryptography.

And the fourth: because the outcome is committed before the flight starts, no tool can predict it. Not an APK, not a Telegram signal, not a "pattern" in the history bar. The maths that makes the game verifiable is the same maths that makes prediction impossible — the two are the same property viewed from opposite ends. What the predictor apps really are.

Common misunderstandings

• "The casino picks the crash point when it sees the bets." It cannot. The server seed is committed by hash before betting opens, and the three client seeds come from players.
• "Changing my client seed changes my luck." It changes an input to a random function. Your expected return is 97% before and after.
• "Provably fair means I can't lose." It means you can't be cheated by an altered result. Losing is the design, not the exception.
• "The history bar shows the seed pattern." The history bar shows past results. Past results carry no information about the next round, whatever the pattern-spotting part of your brain reports.
• "If it's verifiable, someone must have reverse-engineered it." Reversing SHA-512 is not a matter of effort. That is what the function is for.

Practise the verification without money

Our free simulator runs the same 0.97 ÷ x crash model with virtual credits, so you can watch the distribution behave exactly as the tables on our RTP page predict — instant crashes at 3%, a median around 1.94×, and the occasional huge multiplier — without staking anything.