Provably Fair, Explained Without Math (and With Math)

"Provably fair" is a cryptographic technique that lets players verify, after the fact, that a game operator didn't change a round's outcome. It uses SHA-256 hashing to commit to a random seed before play and reveal it after: if the revealed seed matches the pre-committed hash, the round was not tampered with. This article explains the concept intuitively, shows the math for those who want it, and describes what provably fair does and does not prove.

What does "provably fair" actually mean?

"Provably fair" means one precise thing: you can prove, after the fact, that the game operator did not change the outcome of a round after you placed your bet.

That is it. Not "the game is fair." Not "you will win." Not "the odds are good." Just: the operator committed to the result before you bet, and you can verify they honored that commitment.

This is a narrower guarantee than most players assume. But it is also a real one, and in an industry where opacity is the default, even a narrow guarantee backed by mathematics is worth understanding.

The concept grew up in cryptocurrency gambling communities, where early operators needed to solve a trust problem: how do you convince a player in one country that a server in another country is not cheating, when there is no regulator in between? The answer was cryptography: specifically, hash functions.

Today, provably fair designs are used by provider games such as Spribe's Aviator, Mines and Plinko, and by site-run crash games such as Stake Crash. Many other popular games use different systems. JetX commits its result as a hash before revealing it but publishes no way to recompute the result, so it is hash-committed rather than provably fair. Spaceman and High Flyer rely on a random number generator certified by a testing lab, which players cannot check round by round. Each approach has strengths and weaknesses, which we cover below.

How does provably fair work without math?

Think of a sealed envelope.

1. Before the round, the operator writes the crash point on a piece of paper, puts it in an envelope, seals it, and places it on the table. Everyone can see the sealed envelope. Nobody can see what is inside.

2. You place your bet. The envelope is already sealed. The operator cannot change what is inside.

3. The round plays out. The multiplier rises and crashes.

4. After the round, the operator opens the envelope. Everyone can see that the number inside matches the crash point. The envelope was sealed before bets were placed, so the operator did not change the outcome.

That is the entire concept. In the physical world, you would need a trusted third party to hold the envelope. In the digital world, you replace the envelope with a cryptographic hash function, a mathematical operation that is easy to compute in one direction and practically impossible to reverse.

The hash is the sealed envelope. The seed is the paper inside. When the operator reveals the seed after the round, anyone can hash it and confirm it matches the hash that was published before the round. If it matches, the commitment was honored.

How does it work with math: SHA-256 and HMAC?

For readers who want the technical detail, here is the general shape. Provably fair crash games usually follow one of two designs. Which one a given game uses is set out in its own fairness documentation; the description below is generic and is not a description of any named site.

Design 1: a pre-committed hash chain, for shared rounds. A long chain of hashes is generated in advance, each one the hash of the next. The final hash is published before play, and the chain is used backwards, one hash per round. Each revealed round hash must hash to the one revealed before it, so no round can be swapped or inserted without breaking the chain.

Design 2: server seed, client seed and nonce, per player.

• Server seed: a random string generated by the game's server. It stays secret until it is retired.
• Server seed hash: the SHA-256 hash of the server seed, published before any rounds are played with it.
• Client seed: a string the player can usually set, so the server does not control every input.
• Nonce: a counter that rises by one with each bet.

For each bet, the game computes a keyed hash (HMAC-SHA256) of the client seed and nonce, using the server seed as the key, and turns that hash into a result with a formula it documents. Formulas differ between games. A common pattern reads part of the hash as a uniform random number and converts it so that the chance of reaching any multiplier falls in proportion to the multiplier.

Verification after the seed is retired. Once the server seed is revealed, the player can:

1. Hash the revealed server seed with SHA-256.
2. Confirm the hash matches the one published before play.
3. Recompute the HMAC for any bet using the revealed server seed, their client seed and the nonce.
4. Apply the game's documented formula and confirm the result matches what happened.

If step 2 fails, the commitment was broken. If every step matches, the game honoured its commitment for every bet made with that seed.

A worked example (illustrative values, not from any real game):

Server seed (revealed later, illustrative):
  "illustrative-server-seed-7c41"

SHA-256 of the server seed (published before play):
  "85a9b32448bc3b3bbe6087200611cc1838ba4e2f569a73a5e643a84eeabc8a6f"

Client seed: "illustrative-client-seed"
Nonce: 42

HMAC-SHA256(key = server seed, message = "illustrative-client-seed:42"):
  "c1b8ab5363a5d7bde17398e8a48818a5bdd42bbdb58739c3beba377041ebf52a"

Both hashes above are real: you can recompute them yourself. The final step, from that HMAC to a multiplier, depends on the formula a particular game documents, so we do not show an invented multiplier here. You can check the first step, seed against published hash, with our hash commitment check.

What does provably fair prove, and what does it NOT prove?

This is the most important section of this article. Provably fair proves a specific, narrow thing. Players, journalists, and even some operators frequently overstate what it guarantees.

What provably fair proves:

• The crash point for each round was determined before bets were placed.
• The operator did not change the crash point after seeing your bet.
• The same server seed produces the same hash: consistency is mathematically verifiable.

What provably fair does NOT prove:

• It does not prove the game's RTP is what the operator claims. An operator could set a 90% RTP (predatory) and still pass every hash check. The hash proves commitment, not fairness of parameters.

• It does not prove the randomness is high-quality. If the server seed is poorly generated (low entropy), the resulting crash points could be predictable to someone who knows how seeds are made. The hash will still verify, because the commitment was honored.

• It does not prove the operator isn't manipulating seed rotations. An operator could rotate the server seed at strategically chosen moments: for example, after a large bet is placed but before the round starts. This is called a rotation attack, and it is undetectable by standard hash verification. Seed Rotation explains the idea and what data it would take to test for it.

• It does not prove the client seed was not manipulated. If the platform generates the client seed (rather than letting the player choose their own), the operator could theoretically select client seeds that produce favorable outcomes. A strong implementation lets the player set their own client seed.

This is why counting rounds matters alongside hash checks. A hash check tells you the operator honored a commitment. A large count of rounds, published with its sample size and a 95% interval, tells you whether the overall return and the distribution match the claim. The lab publishes those counts game by game once a game passes its minimum sample; see the games list.

What attacks can slip past provably fair?

Understanding the limits of provably fair requires understanding the specific attacks it does not prevent:

The parameter attack. The operator sets an undisclosed or misrepresented RTP. Every round verifies correctly because the hash chain is honest, but the mathematical formula that converts hashes to multipliers includes a hidden parameter that shifts the distribution in the house's favor. Detection requires comparing the observed distribution of crash points against the theoretical distribution for the claimed RTP. This is what the lab's round counts measure: the return at each cash-out target and the shape of the distribution, each with its interval.

The rotation timing attack. The operator watches for large incoming bets and rotates the server seed at a moment that ensures the next few rounds crash low. Each individual round still verifies, because the new seed's hash was committed before those rounds, but the timing of the rotation is correlated with player behavior. Detection requires statistical analysis of whether rotations cluster around high-wager events. Seed Rotation covers this in detail.

The entropy attack. The operator generates server seeds with low entropy, for example, using a weak PRNG or a predictable seed. The resulting crash points pass hash verification and can look perfectly random, but someone who knows how the seeds were made could predict them. The risk is predictability, not a visibly odd distribution, which is why seeds should come from a strong source of randomness and why a player-set client seed helps.

None of these attacks are easy to execute at scale without detection. But they are possible, and they are why "provably fair" alone is not sufficient. It is a necessary floor, not a sufficient ceiling.

How do you verify a provably fair round yourself?

Verification needs no special software. In general terms:

1. Note the commitment shown before play: a server seed hash, or the published end of a hash chain.
2. Wait for the reveal. A seed in use cannot be checked until it is retired and revealed.
3. Check the commitment. Compute the SHA-256 of the revealed value and compare it with the hash published before play. Our hash commitment check does this in your browser and sends nothing to us.
4. Recompute the result, if the game documents its formula, and compare it with the crash point you saw.

For a detailed step-by-step walkthrough with code you can copy-paste, see How to Verify a Provably Fair Hash Yourself.

The most important thing to understand about verification is not the technical process. It is the incentive structure. Provably fair works not because every player verifies every round, but because every player could. The credible threat of verification is the mechanism that keeps operators honest.

Can provably fair help predict the next round?

No. A seed is revealed only after the rounds it produced are over, so verification always looks backwards. Apps that claim to read the next result from the hash or from recent rounds cannot see the secret seed; see the predictor bots check. Past results do not change the next one either: history describes behaviour. It does not predict the next round. The patterns and hot hours check explains why.