Provably Fair, Explained: How to Verify a Crash Round Yourself

Every online casino says it's fair. Provably fair means something stricter: you don't have to believe it, because you can check the arithmetic yourself after the fact. The claim is falsifiable — and that's the whole point.

The problem it solves

In an ordinary online game, the operator picks the outcome on their own server. Nothing visible to you distinguishes an honest one from an operator who peeks at the bets and then decides the result. You're trusting a black box.

Provable fairness closes that hole with a commitment. The operator locks in the outcome before anyone bets, publishes proof of the commitment, and reveals the secret afterwards so you can confirm the two match.

Commit, play, reveal

The scheme has three steps, and the order is everything.

1. Commit. Before betting opens, the server generates a random secret (the server seed) and publishes SHA-256 of it — the seed hash. The hash reveals nothing about the seed, but it's a binding promise: only one seed produces that hash.
2. Play. Bets are placed and the round runs. The server can't change the seed now, because the hash is already public and it can't find a different seed producing the same hash.
3. Reveal. After the round ends, the server publishes the seed itself. You hash it, compare it to what was published earlier, and recompute the crash point from it.

If the hash matches and the recomputed crash point matches what actually happened, the round was fixed before you bet. If either check fails, you've caught the operator — publicly and provably.

Why SHA-256 makes the promise binding

Two properties do the work. Pre-image resistance means you can't work backwards from the hash to the seed, so publishing it early doesn't leak the outcome. Collision resistance means nobody can find a second seed with the same hash, so the operator can't swap in a more profitable seed after seeing the bets.

That's what turns a published hash from a decoration into a commitment. Breaking it would require breaking SHA-256, which would be a much bigger story than a rigged crash game.

From seed to crash point

The seed alone isn't the multiplier — it has to be turned into a number in a specific distribution. The standard construction:

hmac  = HMAC_SHA256(server_seed, "<client_seed>:<nonce>")
bits  = first 13 hex chars of hmac, as an integer   // 52 bits
u     = (bits + 1) / 2^52                            // uniform in (0, 1]
crash = floor(min(max(1, 0.98 / u), 1000) × 100) / 100

The 0.98 is the house edge — a 2% shave off the survival probability. The 52 bits are the full mantissa of a double-precision float, so the uniform draw uses every bit that can be represented exactly. Flooring to two decimals means the number you saw on screen is exactly the number that settled your bet, with no rounding disagreement between the animation and the payout.

How Solacrash does it (and one honest caveat)

Solacrash runs shared rounds: everyone rides the same plane, so a round has exactly one crash point for all players. That has an implication worth stating plainly rather than glossing over.

In per-player games, the client seed is a value you choose, which stops the operator from targeting you specifically. In a shared round there is only one outcome, so a personal client seed can't apply — Solacrash uses the round's own published seed hash as the client seed input. The commitment is just as binding: the hash goes out before betting opens and the seed is revealed afterwards, so the outcome still can't be changed once bets are in. What shared rounds give up is per-player seed control; what they give you instead is that everyone in the round is looking at the same number, and any player can catch a discrepancy.

Verifying a round yourself

Take any finished round's server seed from the fairness page and run this. It needs nothing but Node — no library, no site involvement:

const { createHash, createHmac } = require("crypto");

const serverSeed = "PASTE_THE_REVEALED_SEED";
const seedHash   = "PASTE_THE_PUBLISHED_HASH";

// 1. Did the revealed seed produce the hash published before betting?
const ok = createHash("sha256").update(serverSeed).digest("hex") === seedHash;
console.log("hash matches:", ok);

// 2. Recompute the crash point.
const hmac  = createHmac("sha256", serverSeed).update(`${seedHash}:0`).digest("hex");
const bits  = parseInt(hmac.slice(0, 13), 16);
const u     = (bits + 1) / 2 ** 52;
const crash = Math.floor(Math.min(Math.max(1, 0.98 / u), 1000) * 100) / 100;
console.log("crash point:", crash);

Compare that number to the round's recorded result. There's also a server endpoint that does both checks for you — GET /api/game/verify/:roundId — but running it yourself is the point: the verification doesn't depend on us.

What provable fairness does not cover

Worth being straight about the limits, because plenty of sites imply the badge covers everything:

• It proves the outcome wasn't changed after bets were placed. It doesn't prove the operator will pay you.
• It says nothing about withdrawal solvency, uptime, or how support treats you.
• It doesn't remove the house edge — a provably fair game is provably fair about being 2% in the house's favour.
• It only works if you actually check. An unverified hash is just a long string.

Provable fairness is a strong, narrow guarantee: the outcome was sealed before you committed money, and you can prove it. That's a genuinely higher standard than 'trust us' — and it's worth knowing exactly how far it goes.