How It Works

A casino that picks the result after seeing your bet can always win. Provably fair schemes remove the "after". The casino fixes its half of the randomness first, shows you a fingerprint of it, and can't swap it later without the fingerprint giving it away.

No code on this page. If you'd rather read code, your first verified round is the same story as a program.

One Bet, Step by Step

1. The server makes a secret. Thirty-two random bytes, written as 64 hex characters. This is the server seed.
2. It publishes a fingerprint of that secret. The SHA-256 hash of the seed, called the commitment. You can't work backwards from the hash to the seed, and the server can't find a different seed with the same hash. The player sees the commitment before betting. A careful player saves it.
3. The player adds their own input. The client seed is any text up to 64 characters. The server hands out a random one by default, and the player can change it whenever they like. Because the outcome mixes both seeds, the server can't have arranged a run of results in advance without knowing what the player would type.
4. Each bet gets a number. The nonce starts at 0 and goes up by one per bet, so a thousand bets under the same two seeds give a thousand different results.
5. The three are mixed. HMAC-SHA256, keyed with the server seed, over the text clientSeed:nonce:cursor. Out come 32 bytes that look like noise and are completely determined by the inputs.
6. Bytes become fractions. Four bytes at a time, each group read as a number between 0 and 1. One digest gives eight of them. A game that needs more, a card shuffle for instance, asks for the next digest by raising the cursor.
7. A mapper turns fractions into a game result. A dice roll, a roulette pocket, a shuffled deck. Every mapper is a few lines of arithmetic with no randomness of its own, and none of them uses modulo, which is where older schemes picked up bias.
8. The server writes a record. Game, parameters, commitment, client seed, nonce, result, time. Not the server seed. That stays secret while it's in use.
9. Later, the seed is retired and revealed. This is rotation. The server publishes the old seed, starts a new one, and shows you the new commitment before your next bet.
10. Now anyone can check. Hash the revealed seed: does it match the commitment you saved? Run steps 5 to 7 yourself: do you get the recorded result? If both are yes, the result was fixed before you bet.

That last step doesn't need the casino's cooperation or its software. The verifier does it in your browser, and the arithmetic is small enough to redo in a dozen lines of Python.

What the Scheme Depends On

Step 2 carries the whole scheme. A commitment you never saw, or saw only after the bet, proves nothing. Checking a record confirms that the seed matches the commitment written in that record. It can't confirm when the commitment was shown to you. Keep your own copy.

Step 9 is the awkward one. While a seed is live the casino holds both seeds and the next nonce, so it can calculate upcoming results. It can't change them. It can know them. GFS 1.0 describes the scheme the industry already runs, this weakness included, and says so. The planned fix is a third input from a public randomness beacon that neither side can see ahead of time.

The Crash Profile

A shared game can't use one player's client seed, because everybody in the round has to get the same result. Crash uses a chain of hashes instead. The server generates the whole chain in advance and publishes only its last link, then plays the chain backwards, so each round's hash can be checked against the one revealed before it. The Crash page has the details.