Server seed, client seed and nonce explained
The inputs at a glance
| Input | Typical form | Controlled by | Secret? |
|---|---|---|---|
| Server seed | Random string, often 64 hex characters | Casino | Yes, until rotated |
| Hashed server seed | 64 hex characters (SHA-256) | Casino | No, public commitment |
| Client seed | Any text | Player | No |
| Nonce | Integer starting at 0 or 1 | Increments per bet | No |
| Round or cursor | Integer starting at 0 | Increments within a bet when more bytes are needed | No |
In the common scheme they combine as:
HMAC-SHA256(serverSeed, clientSeed:nonce:round)
The server seed
The server seed is the casino's source of randomness. It should be generated with a cryptographically secure random number generator and be long enough that it cannot be guessed. A 64-character hexadecimal string represents 256 bits.
Why it must stay secret
Anyone who knows the active server seed, client seed and nonce can compute the next result. If you knew it, you could bet only when you would win. So the casino keeps it hidden while it is in use.
Why it must be committed
Secrecy alone would let the casino change the seed whenever it liked. To prevent that, the casino publishes the SHA-256 hash of the seed before you play.
The hashed server seed
SHA-256 has two properties that make the commitment work:
- Preimage resistance. Given the hash, it is not feasible to find the seed. Your future results remain unpredictable.
- Collision resistance. It is not feasible to find two different seeds with the same hash. The casino cannot reveal a different seed later and claim it matches.
The commitment is only useful if you keep a record of it. If you rely on the casino's interface to show you the hash later, a dishonest casino could show a different one. Note the hash before you play.
Text or bytes?
Most casinos hash the seed exactly as displayed, as a text string. Some hash the underlying bytes. These give different hashes. Check the documentation if your hash check fails.
The client seed
The client seed is your contribution. It is usually a random string by default, but you can replace it with any text.
Why it must be changeable
Consider what the casino could do without it. Before committing, it could generate a huge number of candidate server seeds, simulate what results each would produce for typical bets, and pick a bad one. The commitment would still be valid, because it really would use that seed.
The client seed blocks this, because it enters the calculation after the commitment. As long as the casino cannot predict your client seed, it cannot know what results a given server seed will produce for you.
For this to hold:
- You must be able to change the client seed.
- The casino must actually use the value you set.
- You should change it after the new server seed hash is shown, not before.
A default client seed generated by the casino offers weaker protection, because the casino could in principle influence it. Setting your own is the safest choice.
The nonce
The nonce is a counter. With the same server seed and client seed, the first bet uses nonce 0 (or 1), the second uses 1, and so on. It makes every bet unique while keeping the whole sequence reproducible.
What to check:
- It increases by exactly one per bet.
- There are no gaps. A gap might mean a bet was computed but not shown.
- There are no repeats. A repeat would mean two bets used identical inputs.
- It resets when you rotate seeds.
Nonces are usually shared across games for the same seed pair. A dice bet at nonce 41 and a limbo bet at nonce 42 come from the same seed sequence.
The round and cursor
One HMAC-SHA256 output has 32 bytes. With 4 bytes per float, that is 8 floats. Dice and limbo need one. Plinko with 16 rows needs 16. Mines needs one float per shuffle step. Card games can need many.
When a game needs more than 8 floats, the generator computes another HMAC with the round number increased by one, and keeps reading bytes. The position in this stream is often called the cursor. In code, a typical generator computes round = floor(cursor / 32), uses the byte at cursor - round x 32 within that HMAC, and moves on.
The nonce stays the same for the whole bet; only the round changes.
Seed rotation
Rotation ends the current seed pair. The casino:
- Reveals the old server seed.
- Generates a new server seed and shows its hash.
- Resets the nonce.
You can then verify all bets from the old pair. Many casinos rotate automatically when you change your client seed. Some also let you see the hash of the next server seed before you switch, which allows you to record the commitment in advance.
Why reveal only after rotation
Revealing a seed that will still be used would make future results predictable. So seeds are always revealed after their last use. That is why you cannot verify a bet you have just placed until you rotate.
Putting it together
A good provably fair session looks like this:
- Note the hashed server seed.
- Set your own client seed.
- Play.
- Rotate.
- Check SHA-256 of the revealed seed against your note.
- Recompute a sample of results from the seeds, nonces and rounds, for example with our verifier.
Implementations differ
Casinos vary in message format, which value is the HMAC key, the nonce starting value, byte-to-float conversion and game formulas. Some multiplayer games use a public hash chain and an external value such as a future blockchain block hash rather than per-player seeds. The principles stay the same; the details must come from the casino's documentation.
Common questions about seeds
Does the casino know my client seed?
Yes, once you set it, because the casino needs it to compute results. That is fine. What matters is that the casino had already committed to the server seed before it knew your client seed.
Should I change my client seed often?
Changing it does not improve your odds; every seed pair produces results with the same distribution. Changing it does refresh the commitment and lets you verify the previous batch. A sensible routine is to set your own client seed at the start of each session.
Can I see the next server seed hash in advance?
Many casinos show the hash of the next server seed alongside the current one. Recording it in advance gives you a commitment you noted before the seed came into use.
Is a longer client seed safer?
The client seed does not need to be secret or long; it needs to be something the casino could not predict when it committed. Any value you choose yourself after seeing the server seed hash does that job.
What if the casino reuses a server seed?
A server seed should never be used again after it has been revealed. If you see the same seed or hash reappear, record it and report it.