Provably Fair Crash Games: Verify Any Round Yourself

A crash multiplier climbs, you hesitate, and it is gone in under three seconds. Nothing on screen tells you whether that number was fixed before the round or picked the moment your finger moved. Provably fair crash games close the gap: the operator publishes a cryptographic commitment before the round and the values behind it afterwards, so you can rebuild the result yourself.

What provably fair actually proves

A provably fair crash game derives its result from values the operator commits to in public before betting opens, so any player can recompute the multiplier afterwards and confirm it was not altered. That is the whole claim, and it is narrower than it sounds.

It proves two things: the outcome was locked in before your bet, and it was not changed after. It does not prove the odds are good, that the return constant matches what the game advertises, or that a withdrawal clears quickly.

The idea predates online casinos. Manuel Blum set out the same commit-then-reveal protocol in Coin Flipping by Telephone at CRYPTO 1981, so two people who did not trust each other could settle a coin toss by phone.

The three inputs behind every crash round

The server seed and the hash you see first

The server seed is a long random string the operator generates and keeps hidden. Before the round it publishes the SHA-256 hash of it instead. SHA-256 returns a 256-bit digest, written as 64 hexadecimal characters, and finding a message that matches a given digest is computationally infeasible, both set out in NIST FIPS 180-4. The hash gives away nothing while pinning the operator to one value.

The client seed, your half of the input

The client seed is a string you control. Because your value enters after the operator has committed, it cannot pick a server seed that suits your input. Replace the default the game hands you: that default is the part an operator already knows.

The nonce, the counter that moves

The nonce increases by one each round: 1, 2, 3, and so on. It lets a single committed seed pair produce a different multiplier every round without either seed changing.

The commitment: why one hash locks the operator in

Change one character of the server seed and the SHA-256 digest changes completely. Once the hash is public, exactly one string can reproduce it, and after the round you hash the revealed seed yourself to check.

One detail sinks most manual checks. The commitment uses plain SHA-256 of the server seed alone. The round result uses HMAC-SHA256, the keyed construction defined in RFC 2104, where the server seed is the key and the client seed plus nonce is the message. Key and message do different jobs, and swapping them gives a digest that looks valid and matches nothing.

Verify a crash round yourself

The chain below runs five rounds off one commitment. Any HMAC tool that lets you set key and message separately reproduces it.

The operator publishes one commitment before the chain begins: 0830995119d4ba5a65f48d3d5c60ba852e8a72ad94649196988c3a2b3280406c. When the seed is retired it reveals the server seed b7a1f0c3d9e2481a5f6c0b3d7e9a2c48. Run SHA-256 on that seed and the commitment comes back. If it does not, nothing below matters.

Step two rebuilds each round. Compute HMAC-SHA256 with the server seed as the key and the client seed, a colon and the nonce as the message. At a client seed of tbilisi-2026 and nonce 2 that message is tbilisi-2026:2, and the digest is cfa2152aecdf09fc1eb234fc08956d3d8683644230680ccb8909e7794166d103.

Step three maps the digest to a multiplier. Read the first 13 hexadecimal characters as one integer, 52 bits of randomness. Call it H. Take 2 to the power of 52, divide it by that figure minus H, multiply by the return constant R and by 100, round down, then divide by 100. No studio publishes an RTP for Aviator or most crash titles. An R of 0.97 is the figure the market runs on, it sets the house edge at 3 percent, and every number below is computed from it.

One committed seed produced 1.11x, 5.13x, 2.33x, 1.24x and 43.79x, all fixed before the first round opened. Return constants and slice lengths differ between titles, so the same three inputs at a different R give a different crash point, and that constant drives Aviator's multiplier math.

A generic online SHA-256 box will not reproduce this. It computes an unkeyed hash, and many append a trailing newline to what you paste, which changes the digest. Use a tool that does HMAC and lets you set the exact bytes.

Where the house edge lives in that formula

Look at R again. At 0.97 the game returns 97 percent and keeps 3. That constant sits inside the calculation you just ran, and verification confirms it was applied.

The formula produces a clean survival rule: the chance a round reaches a multiplier of m is R divided by m. Cashing out at m therefore returns m multiplied by R divided by m, which is simply R.

Expected return is identical at every cash-out target. At an R of 0.97 you get back 0.97 of your stake on average whether auto cashout sits at 1.20x or at 40x. Variance changes enormously. Expectation holds still.

In lari: on a 20 GEL stake the expected return is 19.40 GEL and the expected loss 0.60 GEL per round, at any target. Play 200 rounds and you have wagered 4,000 GEL against roughly 120 GEL of expected loss. That same 120 GEL is what a bonus costs to clear whatever the headline figure, which is why a 35x multiple outweighs a large number beside it.

What one verified round cannot tell you

Recomputing a round proves that round. It proves nothing about the constant the operator plugged into the formula, and that is where a rigged game would hide. The distribution at 0.97 is fully determined, so you can measure your own history against it.

The median crash point is 1.94x, and 51.50 percent of rounds end below 2.00x. Set R to 100 divided by 101 and the edge falls to 0.99 percent, the median moves to 1.98x and the chance of reaching 2.00x becomes 49.50 percent. Reading a crash game honestly means reading its return constant and its distribution together, which is why a configurable JetX build changes both at once.

Catching a wrong constant takes rounds. Count how many of yours reach 2.00x and test that share against the 48.50 percent above. At 5 percent significance and 80 percent power, a game advertising 0.97 while running 0.90 takes about 1,260 rounds to expose, and 0.96 posing as 0.97 takes about 61,700. Hash checks catch tampering with one round; only the distribution catches a wrong constant.

What provably fair does not prove

It does not prove the server seed was chosen fairly

One seed covers a whole chain of rounds and the nonce advances predictably, so an operator can compute every multiplier before publishing the commitment. The hash conceals how many chains were generated and which one was kept. That is the practical reason to set your own client seed: a value the operator has not seen cannot be selected around. Verification tests output against a stated method, so the build serving your session, and any bug in how it makes seeds, stays out of reach.

It does not cover the whole lobby

Only in-house games carry a seed chain you can recompute. Third-party slots run the studio's own generator under its own scheme: BGaming documents a hash of the result plus a secret string, revealed once the round ends. Most titles on a slot site cannot be rebuilt round by round, and live dealer tables are dealt on camera, so a live dealer round rests on the shoe and the stream rather than a digest.

It does not prove the money moves

A verified round says nothing about how fast a withdrawal clears. Payout speed is a separate measurement and the spread is wide: Stake settles crypto withdrawals instantly, five of the operators we rank clear inside a 0 to 24 hour band, and 7Slots runs 0 to 3 days.

Why your client seed may not change the multiplier

Two architectures both get called provably fair. In single-player games such as Dice or Limbo, the result is an HMAC of your personal client seed and nonce, so your seed genuinely moves your outcome. In multiplayer crash, every player at the table watches the same multiplier, and one shared result cannot depend on a dozen different client seeds.

Shared rounds are commonly derived from a shared chain instead, in some designs one where each round's seed is the SHA-256 preimage of the previous round's. That lets the whole history be verified backwards from one revealed seed, a stronger guarantee than a per-player chain.

So in a shared crash round your client seed may only feed a public salt, or may not enter the round at all. Check which model a game uses before assuming yours did anything.

Checking a provably fair claim before you play

Six things separate a verifiable game from a badge graphic.

1. The next round's server seed hash is visible before you bet, not only after.
2. The client seed field accepts a value you type in.
3. Rotating the seed reveals the retired server seed in plain text at once.
4. The page names the exact algorithm and message format, separators included. A bare mention of SHA-256 is not a specification.
5. A verifier accepts your own inputs, and the numbers match when you compute them independently.
6. The return constant is stated, so you know what R you are checking against.

An in-house series tells you the operator wrote the game. Whether each round carries a rebuildable seed chain is a separate question, and our data records Setanta's Originals only as an in-house series.

Among operators serving Georgia, Stake is the one whose Originals series, covering Plinko, Mines, Crash and Dice, is described as running on provably fair mechanics, so the same recomputation applies to a Plinko drop, where the bucket a ball lands in is fixed before it moves. Its crypto accounts in BTC, ETH, USDT and LTC follow the pattern across the crypto-first sites built around in-house games. Our data records no verification model either way for 1win, which lists Aviator, Crystalbet, whose crash section sits inside more than 4,220 games, or Betlive, which carries JetX and Aviatrix on lari accounts. Run the six checks in the lobby yourself, since the crash game ranking is built on payout speed and game range.

Key takeaways

• A published SHA-256 commitment pins the operator to one server seed, and revealing it afterwards is what makes the round checkable.
• The result uses HMAC-SHA256 with the seed as key and client seed plus nonce as message; the two do different jobs.
• The return constant R sits inside the formula. Verification confirms it was applied, it does not move it.
• Expected return is the same at every cash-out target: 19.40 GEL on a 20 GEL stake at an R of 0.97.
• One verified round proves one round. Exposing a wrong constant takes about 1,260 rounds at best and 61,700 at worst.
• Verification says nothing about payout speed.