The technical core

Provably fair: how the crash point is made

Aviator’s outcome isn’t decided while the plane flies, and it isn’t decided by the casino alone. It’s fixed the instant the round starts, by a hash the operator committed to before you bet — and you can check every round afterwards. Here’s the whole mechanism.

The idea

Commit first, reveal after

“Provably fair” is a commit–reveal scheme, an old cryptographic trick:

  1. Before the round, the game publishes a hash (a cryptographic fingerprint) of its secret server seed. It’s now committed — changing the seed later would change the fingerprint and be caught.
  2. The round is generated from that seed plus inputs the operator doesn’t control.
  3. After the round, the secret seed is revealed. Anyone can re-hash it, compare with the pre-round fingerprint, and recompute the result.

The consequence: the operator cannot alter an outcome after bets are placed without the manipulation being mathematically visible.

Why a hash can’t be faked

Cryptographic hashes like SHA-512 are one-way: finding a different input producing the same fingerprint is beyond any realistic computation. Publishing the hash locks the seed in place as surely as sealing it in an envelope — an envelope everyone can check was never swapped.

Aviator specifically

Server seed + three player seeds

Aviator adds a twist that most crash games skip: the result doesn’t come from the server seed alone. Each round is generated from four participants — the game’s server seed plus the client seeds of the first three players who bet in that round.

When the round starts, the four seeds are merged and hashed — Spribe’s rules describe a SHA-512 hash of the combined value — and the round’s flyaway coefficient is derived from that hash. Because the server seed was committed in advance and the client seeds come from players’ own devices, neither side can steer the result: the operator can’t change it after seeing the bets, and no player knows the server seed before the reveal.

Labeling note: the pre-round commitment field appears in some operators’ rule panels as “Next server seed SHA256”. Third-party guides often mix the two hashes up; the in-game Provably Fair panel of the version you play is the authority on the exact labels.

Server seed hash published first Client seed 1 bettor 1 Client seed 2 bettor 2 Client seed 3 bettor 3 SHA-512 combined hash Coefficient e.g. 2.31x Fixed the moment the round starts — before anyone can react to it.
Hands on

Verify a round, step by step

  1. Open the bet history in the game and pick any finished round.
  2. Tap the fairness (shield) icon next to it. The game reveals the round’s server seed, the three client seeds, the combined hash, and the resulting coefficient.
  3. Check the commitment: hash the revealed server seed in any SHA tool and compare it with the fingerprint published before the round.
  4. Check the result: recombine the four seeds as the panel shows, hash them, and confirm the displayed coefficient follows from the hash.

You don’t need to verify every round — the point is that anyone can, at any time, which is what keeps the mechanism honest.

No cryptography degree required

Free SHA-512 calculators run in any browser: paste, hash, compare. The in-game panel lays out the exact concatenation of the seeds so the recomputation is mechanical.

Fewer than three bettors?

Spribe’s public rules don’t document what happens when fewer than three players bet in a round (whose seeds are used then) — one of the few genuinely undocumented corners. Nothing about the commitment scheme changes, but we won’t state what we can’t verify.

Honesty about honesty

What verification proves — and what it doesn’t

It proves: the round you played matched the pre-round commitment — the outcome wasn’t altered after bets were placed, by anyone.

It does not prove:

  • that your odds are good — the verified game still has its built-in 3% house edge;
  • that a prediction is possible — the opposite: the scheme is precisely what makes predictor apps impossible;
  • that the site you’re on is the real game — a clone can fake or omit the whole fairness menu.

Spotting a fake Aviator

Play only inside a casino licensed in your country; check that the game frame carries Spribe’s branding; check that the provably-fair menu exists and that its numbers actually verify. “Official Aviator” websites, APK downloads and Telegram versions are not the game — the real Aviator lives only in licensed casino lobbies.

The economics

RTP 97%, house edge 3%

Aviator’s published return to player is 97%: across a very large number of bets, players get back an average of 97 cents per $1 staked. The missing 3 cents are the house edge — the price of the game.

Under the standard crash model this makes the chance of reaching any multiplier m about 0.97 ÷ m, which has two consequences worth internalising:

  • Every cashout target has the same −3% expected value. 1.5x, 2x, 10x, 100x — same average loss per $1. Targets choose variance, not profit.
  • About 1 round in 33 crashes at exactly 1.00x — instantly, before any cashout is possible. That’s not a malfunction; it’s the model working.

Some reviews report operator-configurable RTP variants below 97%; Spribe hasn’t confirmed this publicly. The in-game rules panel states the RTP of the version you’re playing.

RTP is not a session promise

97% emerges over millions of rounds. In one evening you can double your money or lose it all — variance dwarfs the average at session scale. What RTP guarantees is only this: the longer you play, the closer your total result drifts to −3% of everything you staked.

The one honest “edge”

The only lever you control is how much you expose to the 3% — stake size, number of rounds, and when you stop. That’s what the play-safe tools are for.