Transparency · verification

How to verify a provably fair crash game, step by step

'Provably fair' only means something if you can actually do the proof. Here's the full mechanism — server seed, client seed, nonce, and the hash-to-multiplier formula — plus exactly how to recompute a real round and confirm it was fixed before you bet.

What does provably fair mean in a crash game?

It means you can prove after the round that the operator committed to the result before you bet and could not change it once your wager was in. The operator publishes a hash of a secret server seed in advance and reveals the seed afterwards; because the hash cannot be reversed, the two must match. It is a guarantee of integrity, not of good odds.

A provably-fair game lets you prove, after the fact, that the operator committed to a result before you bet and could not have altered it based on your wager. It does this with cryptographic commitment: the server picks a secret (the server seed), shows you a hash of it in advance, and only reveals the secret later. Because a good hash can't be reversed, the operator is locked in — the hashed value they showed you can only have come from the seed they later reveal.

Critically, this proves integrity (the result wasn't manipulated), not fairness of odds in the everyday sense. The house edge is still baked into the formula. Provably fair means "not rigged against you beyond the stated edge" — not "a good bet". Keep that distinction in mind throughout.

What are the server seed, client seed and nonce?

The server seed is the operator's secret, shown only as a hash until revealed; the client seed is a string you control, so neither side can fix the result alone; the nonce is a counter that increments every round so one seed pair yields a fresh result each time. Combined, usually as HMAC_SHA256(serverSeed, clientSeed:nonce), they produce the hash the crash point is read from.

• Server seed: a long random string the operator generates and keeps secret. You see only its hash (e.g. SHA-256) until it is revealed.
• Client seed: a string you control (often editable in settings). Because the result depends on your input, the operator can't have pre-computed a result tailored against you — neither side can fix the outcome alone.
• Nonce: a counter that increments each round, so the same seed pair produces a fresh result every round without re-seeding.

The three are combined — typically HMAC_SHA256(serverSeed, clientSeed:nonce) — to produce the hash that determines the crash point. Change any one and you get a completely different, unpredictable result. That per-player recipe fits single-player games such as dice. A shared multiplayer crash round has one result for every player, so it cannot depend on each player's own client seed: Bustabit and BC.Game instead commit a whole chain of hashes in advance and salt it with a value nobody controls, and Aviator mixes in the seeds of the first three players to bet (details below).

How is the crash point calculated from the hash?

Take the first 13 hex characters of the round hash, read them as an integer and divide by 2⁵², giving a uniform fraction h between 0 and 1. The crash point is then floor((100 − houseEdge) ÷ (1 − h)) ÷ 100: a small h gives a low multiplier, an h close to 1 a huge one, and the uniform distribution of h is what makes P(reach m) = RTP ÷ m. The industry-standard conversion from hash to crash point is:

where h is a fraction in [0,1) derived from the hash. The common derivation takes the first 13 hex characters of the hash, reads them as an integer, and divides by 2^52 — a 52-bit value (13 hex digits × 4 bits = 52 bits). So:

Worked intuition: when h is small, 1 − h ≈ 1 and the crash point is near (100 − edge)/100 — a low multiplier. When h is close to 1, 1 − h is tiny and the multiplier balloons toward the game's maximum. The distribution of h being uniform is exactly what makes P(reach m) = (100 − edge)/100 ÷ m = RTP/m. This is the distribution implied when every cashout target returns the same RTP. Bustabit publishes this formula in full (its verify.js computes 99 / (1 − X), floors it, divides by 100 and never returns less than 1.00); most operators publish the RTP but not their full distribution, so for them the formula is the standard model rather than a published fact.

Why does the instant-bust rate equal the house edge?

Here is the elegant part. The house edge isn't an extra fee bolted on — it's produced by forcing a small fraction of rounds to bust instantly at 1.00×. Specifically, a fraction of rounds equal to the house edge is mapped to an immediate bust:

• 99% RTP (1% edge): ~1% of rounds instant-bust at 1.00×
• 97% RTP (3% edge, Aviator): ~3% of rounds instant-bust
• 95% RTP (5% edge, Rollbit X Crash): ~5% instant-bust

That's why a higher-edge game "feels" like it busts early more often — because it literally does, on more rounds. Our simulator reproduces this faithfully: switch the edge and watch the instant-bust frequency (and your ruin rate) rise.

How do you verify a crash round yourself?

Five steps: note the hashed server seed and your client seed before playing, play your rounds, rotate the seed so the old one is revealed, hash the revealed seed and confirm it equals the hash you noted, then recompute each round's HMAC and crash point and compare with what you saw. Any offline SHA-256 tool reproduces the numbers. The general procedure, which works on any operator that exposes the seeds:

1. Before playing, note the hashed server seed the operator displays, and set (or note) your client seed.
2. Play your rounds. The nonce increments each round.
3. Rotate / reveal the server seed. Most sites require you to "rotate" to a new seed before they'll reveal the old one — this prevents you peeking at future results.
4. Confirm the commitment: hash the revealed server seed and check it matches the hash shown in step 1. If it matches, the operator couldn't have changed the seed after you bet.
5. Recompute each crash point: compute HMAC_SHA256(serverSeed, clientSeed:nonce) for each round, take the first 13 hex chars, derive h, and apply the formula. The result must match the crash points you observed.

How do Stake, BC.Game and Bustabit implement provably fair?

Stake publishes seed and hash data for its shared Crash rounds in its Fairness section; its editable client seed, hashed server seed and nonce apply to single-player Originals such as Dice. BC.Game commits a chain of 10,000,000 results in advance and plays it in reverse. Bustabit, the 2014 original, publishes an open 52-bit formula and seeded its chain through public BitcoinTalk events. Aviator offers a seed reveal; Spaceman does not.

• Stake: a Fairness section with a built-in verifier. For single-player Originals you get an editable client seed, a pre-shown hashed server seed and a nonce; Crash is a shared round, so you check it against the seed and hash data Stake publishes for Crash rather than against your own seed.
• BC.Game: a pre-generated chain of 10,000,000 results played in reverse — the whole sequence is committed in advance and consumed backwards, so outcomes can't be reordered.
• Bustabit: the original and most open — a self-verifiable 52-bit formula, public BitcoinTalk seeding events, and open-source elements. The gold standard.
• Provider games (Aviator, Spaceman): Aviator offers provably-fair verification; Spaceman is RNG-based and generally does not expose a crypto seed reveal — a real transparency gap versus the crypto originals.
• Aviator in Spribe's own words (Aviator game client's Provably Fair text, read 29 October 2026): the round result is "generated from four independent participants of the round: game operator and first 3 betters of the round." The operator generates a server seed of 16 random symbols and shows its SHA-256 hash in Provably Fair Settings ("Next server seed SHA256") before the round; when the round starts the game merges that seed with the three client seeds and derives the result from the SHA-512 hash of the merge. The fairness window then shows the server seed, the three players' seeds, the combined hash and the result. Two limits: Spribe does not publish how the SHA-512 hash becomes a multiplier, so you can confirm the commitment and the combined hash but not recompute the multiplier from a public formula; and in multi-room mode each room has its own server and player seeds. The game's rules also say a crash at 1.25× means the multiplier reached only 1.24×, so an auto-cashout set exactly at the crash multiplier loses, and that bets affected by a malfunction are void and refunded.

What does provably-fair verification prove, and what does it not?

Be precise about the guarantee:

• It proves: the result was fixed before your bet and matches the published formula; the operator didn't tamper round-by-round.
• It does not prove: that the game is a good bet (the edge is real and negative), that the operator is solvent or licensed, or that an unrevealed server seed was generated randomly rather than cherry-picked from many candidates (a subtle attack reputable, audited operators mitigate). Verification is necessary for trust, not sufficient on its own.

In short: provably fair is a powerful, checkable integrity guarantee — and a great reason to prefer crypto originals over black-box RNG. It is not a route to profit. The maths in our strategy guide still holds: EV = −(house edge), verified or not.

Frequently asked questions

Formula and derivations reflect the standard industry model; exact implementation details (hash function, hex-digit count) can vary slightly by operator — always check the operator's own fairness documentation. Educational content, 18+.