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 "provably fair" actually means

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.

The three ingredients: server seed, client seed, nonce

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

The hash-to-multiplier formula

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 the instant-bust rate equals 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.

Verifying a real round yourself

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 each operator implements it

• 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 verification does — and doesn't — prove

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