Seeds, Nonces, and Hashes

Every provably fair result comes from three ingredients. The server seed is the casino's secret number, and the client seed is yours, usually editable. The nonce is a counter that rises by one with each bet. Mix them through a hash function and out comes your roll, card, or crash point.

None of the three is scary once you see the job it does. The server seed provides randomness the casino controls. The client seed provides randomness you control. The nonce keeps every bet distinct. And the hash function is the blender that turns those inputs into one unpredictable, repeatable output.

Hashes: one-way fingerprints

A hash function like SHA-256 takes any input, a word, a number, a whole book, and returns a fixed-length string of letters and digits. The same input always produces the same output. But the function only runs one way: given the output, you can't work backward to the input. And the output is chaotic, so changing a single character produces a completely different fingerprint. Hash the word 'dice' and you get one string; hash 'Dice' and you get something unrecognizably different.

Those two properties do all the work in provably fair. One-way means publishing the server seed's hash gives nothing away: you can see the fingerprint without learning the secret. Deterministic means that once the seed is revealed, anyone can re-run the hash and confirm the fingerprint matches. Commitment first, verification later.

What each ingredient does

• Server seed: the casino's secret random string. You see its hash before betting, and the seed itself only after it's retired.
• Client seed: your contribution. Because you can set it after seeing the server seed's hash, the casino can't pre-pick results that favor the house.
• Nonce: a bet counter (0, 1, 2, and so on) so every bet under the same seed pair produces a unique result without new seeds each round.
• Hash: the published fingerprint that locks the server seed in place before you play a single round.

Notice the asymmetry in when things go public. The client seed and nonce are visible the whole time; you can screenshot them mid-session. The server seed stays hidden until rotation, because revealing it early would let you compute upcoming results and bet only on winners. Hiding it while you play, and proving it afterward, is the entire design.

One seed pair, step by step

Follow one full cycle. The casino generates server seed S and publishes its hash, H(S). You set your client seed to 'lucky-42'. Your first bet uses S, 'lucky-42', and nonce 0. Your second bet uses the same seeds with nonce 1, the third nonce 2, and so on. Two hundred bets later you rotate seeds. The site reveals S, you hash it yourself, and you confirm the output equals the H(S) you saw before bet one. Every result in between is now checkable.

Why bother with the nonce? Without it, every bet under the same seed pair would produce an identical result, which would make the game pointless after round one. The counter changes the input slightly each time, and because hashes are chaotic, a nonce of 7 gives a wildly different outcome than a nonce of 8. Same ingredients, fresh outcome, every single round.

Two mistakes come up constantly. First, players leave the default client seed untouched, which weakens the guarantee: setting your own seed after seeing the hash is what proves the casino committed blind. Change it to anything, your cat's name works fine. Second, players assume a revealed seed means past results were fair without checking. The reveal enables verification; it isn't verification. Until you re-hash and compare, you've proven nothing. Five minutes with a hash tool closes that gap, and the next lesson walks through the whole check step by step.