Server Seed, Client Seed, Nonce: Provably-Fair Mechanics Explained
Every provably-fair casino outcome is built from three ingredients: a server seed, a client seed and a nonce. Understand what each one does and you understand the entire trust model — why the house cannot cheat, what you contribute, and how you verify any result yourself. This is the full mechanism, ingredient by ingredient, with the verification loop as Llamabet runs it on Sui.
Verify a hand yourself →The three ingredients, defined
The server seed is a long random secret generated by the casino before any betting happens. It is the house's contribution to randomness — and the thing the house must be prevented from manipulating. The client seed is a value contributed from the player's side; on many platforms you can set it yourself to any string you like. It is your contribution, and crucially, the house cannot predict it. The nonce is a simple counter that increments with each bet made under the same seed pair: bet one uses nonce 1, bet two uses nonce 2, and so on. Combine all three through a cryptographic hash function and you get a unique, deterministic fingerprint for every individual bet. Same inputs, same outcome, every time — which is exactly what makes verification possible later. None of the three is sufficient alone; the security comes from how they interlock.
Why the server seed is committed before you bet
If the casino simply generated a server seed and used it, you would have to trust that it did not pick a seed after seeing your bet — one chosen specifically to make you lose. The commit-reveal scheme kills that possibility. Before any betting, the casino publishes the SHA-256 hash of its server seed. A cryptographic hash is a one-way fingerprint: it reveals nothing about the seed itself, but it binds the casino to exactly one value, because finding a different seed that produces the same hash is computationally infeasible. Llamabet goes a step further than most: the commitment is published on the Sui blockchain, timestamped and immutable, rather than sitting on the casino's own server where it could be quietly swapped. Once that hash is on-chain, the house is locked in. Whatever happens in your session, the seed that gets revealed afterward must hash to the commitment — and you can check that it does. Every contract address involved is published at /contracts.
Why your client seed matters
A committed server seed alone still leaves a subtle attack: the house knows its own seed, so if outcomes depended only on it, the house could compute every future result in advance — and, say, throttle a player who is about to hit a winning streak. The client seed closes this hole. Because you contribute entropy the house cannot predict at commitment time, the house cannot know outcomes in advance even though it knows its own seed. The final result depends on a value that did not exist, from the house's perspective, when it locked in its commitment. This is also why changing your client seed is meaningful: pick a fresh string and you have re-randomized your future results in a way neither party controls alone. The outcome becomes a joint product — house entropy, committed and bound; player entropy, unpredictable and yours. Neither side can steer it unilaterally, which is the entire point.
What the nonce does
Without a nonce, one server-seed-plus-client-seed pair would produce exactly one outcome — you would need fresh seeds for every single bet, and every bet would require a new on-chain commitment. The nonce solves this elegantly: by hashing the seed pair together with an incrementing counter, each bet gets its own unique, independent outcome while the commitment stays fixed. Bet 47 under a seed pair is fully determined by seeds plus the number 47, and bet 48 is a completely different hash. The counter also creates an audit trail: after the seed reveal you can verify not just one bet but your entire session in sequence, confirming no outcome was skipped, reordered or replayed. It is the same concept nonces serve across cryptography — a number used once, guaranteeing that identical inputs never produce identical outputs twice when they should not.
From hash to cards: deterministic derivation
So the three ingredients produce a hash — a string of bytes. How does that become a shuffled deck or a roll? Deterministically. For a dice-style game, bytes of the hash are read as a large number and mapped into the result range, giving a roll between 0 and the maximum. For card games, the bytes drive the shuffle itself: Llamabet uses the hash output to determine insertion positions while building a multi-deck shoe, so the full order of the shoe is a pure function of the hash. The key property is that there is no randomness left at this stage — no hidden dice roll on the server, no last-moment choice. Given the seeds and nonce, anyone running the same published algorithm gets bit-for-bit the same deck. The casino is not generating your outcome when you click bet; it is revealing a consequence that was mathematically fixed the moment the inputs were.
The verification loop on Llamabet, end to end
Here is the complete cycle as it runs in production. One: Llamabet generates a server seed and publishes its SHA-256 commitment on the Sui blockchain — on-chain, before any bets under that seed. Two: you play. Blackjack hands, rolls, poker hands — each outcome derives from the committed server seed, your client seed and the incrementing nonce. Three: after the seed rotates out of use, the server seed is revealed. Four: you verify. Hash the revealed seed and confirm it matches the on-chain commitment (checkable on any Sui explorer), then recompute your outcomes with the published derivation and confirm they match what you were dealt. Llamabet provides a self-serve verifier at /poker/verify, and because the commitment lives on Sui rather than on Llamabet's servers, the audit trail survives independently of the casino. You are not trusting a fairness certificate — you are re-running the math.
Common misconceptions
Two errors come up constantly. First: a revealed seed does not make future outcomes predictable. Reveals happen only after a seed is retired; active play always runs under a seed whose hash you can see but whose value remains secret, and your unpredictable client seed guards the rest. Past reveals let you audit the past — they say nothing about the future. Second: hashing is not encryption. Encryption is reversible with a key; a hash has no key and no inverse. Publishing a SHA-256 commitment does not leak the seed in any recoverable form — its role is binding, not hiding-with-a-backdoor. A third misconception worth retiring: provably fair does not mean you will win. The house edge is disclosed and fully intact. What the mechanism proves is that the stated odds are the real odds — the game you were promised is the game you got. That is the honest claim, and it is verifiable.
Frequently asked questions
What is the difference between a server seed and a client seed?
The server seed is the casino's secret random value, committed as a SHA-256 hash before betting so it cannot be changed afterward. The client seed comes from your side and the house cannot predict it. Outcomes are derived from both together plus a nonce, so neither party can control results alone.
What does the nonce do in provably fair gambling?
The nonce is a counter that increments with every bet under the same seed pair. Hashing it together with the seeds gives each bet a unique, independent outcome without needing new seeds and new commitments per bet — and lets you audit an entire session in order after the seed is revealed.
If the server seed is revealed, can someone predict future results?
No. Seeds are revealed only after they are retired from play. Live bets always run under a currently secret seed whose hash commitment is already published — on Sui, in Llamabet's case — and your client seed adds entropy the house never controlled. Reveals enable auditing the past, not predicting the future.