Server seeds, client seeds and the hash behind every crash round

A server seed is a secret random string that the game operator creates before a crash round. A client seed is a string that comes from a player's own device. In a provably fair game the two are combined and run through a hash function, and the round's multiplier is read from the result.

This page explains what each part does and what a check can prove. For the button-by-button routine on a finished round, see how to verify a provably fair crash round.

What is a server seed?

Spribe, the provider of Aviator, says the operator generates the server seed as 16 random symbols. The seed is the operator's share of the randomness for a round. On its own it does not decide the result, because client seeds are mixed in before the hash is taken.

The server seed stays secret until the round is over. Before the round, the game publishes only a hash of it. In Aviator that hash sits in the user menu under Provably Fair Settings, labelled Next server seed SHA256.

After the round, the seed itself appears in that round's provably fair window, next to the player seeds, the combined hash and the result. That reveal is what makes a later check possible.

What is a client seed?

A client seed is generated on the player's side, in the browser or the app. Spribe's Aviator rules say you can change your own client seed in the same Provably Fair Settings window.

Not every player's seed goes into every round. The Aviator rules say the result of a round comes from four participants: the operator's server seed and the client seeds of the first three players to bet. If you were not among the first three, your seed played no part, but your bet is still settled by the same crash point as everyone else's.

Each Aviator room works out its results separately, with its own server and player seeds, according to the same rules. Two rooms can therefore show different multipliers at the same moment. The wider mechanics of a round are covered in how Aviator-style crash games work.

How the hash commits the server to a result

A hash function turns any input into a fixed-length string of letters and digits called a digest. The US standard that defines SHA-256 and SHA-512, NIST's FIPS 180-4, says it is computationally infeasible to find an input that matches a given digest, or two inputs that share one. It adds that any change to the input will, with a very high probability, give a different digest.

Those two properties turn the published hash into a commitment. The operator shows the SHA-256 digest of the server seed before anyone bets, so it cannot quietly swap in another seed later without the digest failing to match. And because the hash cannot be run backwards, nobody can read the seed, or the coming multiplier, out of it in advance.

Spribe's Provably Fair page shows the chain with a toy sample: server seed AB, player seed CD, combined seed ABCD, then the SHA512 hash of ABCD, from which the round result is produced. The digest in that sample begins 49EC55BD, and any standard SHA-512 tool gives the same string from the input ABCD. The table below adds four more inputs so you can see how far a single letter moves the output.

Real seeds are longer than these two-letter samples, which only show the principle. The digests were computed with the standard SHA-256 and SHA-512 functions.

How the client seed changes the outcome

Because the multiplier is read from the combined hash, a change to any client seed changes the hash completely, and the multiplier with it. In the table, swapping one letter of the client seed turns a digest starting 49ec55bd into one starting f6d80da2.

This is why players are allowed to add seeds at all. The operator commits to its server seed first, before it knows which client seeds the first three bets will carry. It therefore cannot choose a server seed that lands on a multiplier it wants, unless it could also predict or control those player seeds.

A new client seed does not make a win more likely. It changes which multiplier comes out, not the odds behind it. Spribe states Aviator's return to player as 97%, no seed choice moves that figure, and the long-run cost is set out in crash game RTP of 97% and what it means.

What you can verify and what you cannot

A seed check answers one narrow question. Was this round's result produced from the seeds shown, using a server seed fixed before the round began? It does not answer every question a player might have about a game.

The first check works only if you note the hash before the round. Copy the Next server seed SHA256 value first, then compare it with the seed revealed afterwards: a mismatch would show the seed was replaced.

The last two rows are why seeds sit alongside regulation rather than replacing it. Regulation 45(2) of the Gambling Control (Conduct of Gambling Operations) Regulations, 2026 (L.N. 112) requires the random number generator for all games of chance to be certified by the Authority or its approved agent. Regulation 45(4) requires the theoretical return to player of each game to be disclosed to the Authority.

Testing labs describe what such certification looks at. GLI, one independent lab, says a random number generator must be fully tested so that results cannot be predicted and no bias exists towards certain outcomes, and its evaluations include a review of the source code.

Why seeds rule out predictor apps

A predictor app would need the server seed before the round, the first three client seeds and the method that turns the hash into a multiplier. Before take-off the only public piece is the SHA-256 digest, and FIPS 180-4 treats working back from a digest to its input as computationally infeasible.

So an app that shows the next crash point is either guessing or inventing its numbers after the fact. The guide to why Aviator predictor apps are scams explains how those schemes take money and personal data.

The same logic applies to anyone selling server seeds. A seed revealed in the round history belongs to a round that has already ended, and the next seed stays hidden behind its hash until that round is over too.