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.

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.

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 exposes a Fairness tab with an editable client seed, hashed server seed, nonce and a built-in verifier. 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 tab with editable client seed, pre-shown hashed server seed, nonce, and a built-in verifier. The cleanest mainstream implementation.
• 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.

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+.