Server Seed, Client Seed, Nonce - and Why On-Chain Is Different
Crack open the "fairness" tab on nearly any crypto casino and three phrases turn up almost immediately: server seed, client seed, nonce. Intimidating at first glance. But the machinery behind them is simple once you see how the parts click together. These three values are also the backbone of every classic provably fair setup, and knowing them tells you exactly what such a setup can and cannot promise.
I will cover each of the three values in plain terms, walk the commit-and-reveal loop that binds them, then set the whole thing against on-chain randomness, where no hidden seed exists at all. Written for players, but exact enough for operators sizing up Sui casino software. Read it, and you should be able to glance at a fairness page and know what is actually being checked.
Some technical detail is unavoidable. No cryptography degree needed, though. If you can picture stirring two ingredients together and counting your turns, you are fine.
The 3 ingredients in one sentence each
Server seed
A secret random value the casino generates and keeps hidden while you play. This is the house’s ingredient in every outcome. Before play starts, though, the casino commits to it by publishing a hash of the seed. The hash locks the value in but shows nothing. That commitment is the thing that stops an operator from swapping the seed once it has seen your bet.
Client seed
Your ingredient. Either a value you type in yourself or one your browser generates that you are free to change. You control it, so the casino never knows the full recipe in advance. Your seed folds into the math, which means the operator cannot decide the result on its own. Want to flex your influence over the randomness? Change it now and then.
Nonce
A counter, nothing fancier. It starts at 0 or 1 and ticks up by one with every bet on the same seed pair. That is what makes bet #1 and bet #2 land on different results even though the server seed and client seed never moved. Think turn number.
How they combine into a result
Glue the three values together, feed them through a cryptographic hash function, usually SHA-256 from the SHA-2 family, and out comes a 256-bit digest. On screen that is a 64-character hexadecimal string. It looks random. It is not: the inputs fully determine it. The casino grabs a slice of that string and maps it onto the game outcome, whether that is a number between 0 and 1, a card, a multiplier, or a Plinko slot. Feed in the same three inputs and you get the same output. Every time.
That determinism is the point. The function is reproducible, so once you hold all three inputs you can recompute the outcome on your own machine. Our breakdown of provably fair Plinko shows the mapping inside a real game, where a hash slice steers the ball down through the pegs.
The commit-and-reveal cycle
This loop is the heart of seed-based fairness. Worth stepping through in order.
- Commit. Before you wager, the casino hands you a hash of the server seed. You cannot run it backward to recover the seed, but later it lets you prove the seed was never swapped.
- Set your seed. You supply a client seed or accept the one offered. Now the recipe is partly yours, so the operator cannot pre-bake your particular outcomes.
- Play. Every bet bumps the nonce. Both seeds stay put while the counter climbs, so each round gets a fresh result.
- Reveal. Rotate to a new server seed and the casino hands over the old one. Hash it yourself, then check that it matches the commitment from step 1.
- Verify. Take the revealed server seed, your client seed, and each nonce, recompute every result, and confirm each one matches what you actually got paid on.
If your recomputed results line up, the casino could not have cheated those rounds without breaking the hash function, and breaking SHA-256 is computationally infeasible. That is the proof in "provably fair." Real proof, and a big step up from a sealed-box RNG you just have to trust.
The weak spot: the seed still starts on the server
Elegant as it is, the seed model carries one built-in weakness. The server seed comes from the operator, on the operator’s hardware, and you only ever get to check it after the operator decides to reveal it. The commitment scheme catches mid-session swaps, sure. But it still asks you to trust that the seed was generated honestly to begin with, and that the reveal actually happens.
With reputable operators this is usually fine. But "usually fine" is precisely the leftover trust that on-chain systems set out to kill. We dig into that gap in our piece on whether provably fair gambling is actually fair, which pulls apart two different things: verifying a result versus trusting the system that cooked up the seed.
On-chain randomness: no hidden seed at all
On-chain systems drop the server seed completely. Instead of the casino committing to a secret and revealing it later, the randomness comes from a verifiable function that lives on the blockchain. On Sui, that is on-chain verifiable randomness, produced during transaction execution and written to a public ledger in roughly 390 ms. The value drawn is a 256-bit number, the same width as a SHA-256 digest, but it comes straight from the chain. No secret tucked away in a data center, because the chain is the source, not the operator.
The idea echoes how Chainlink VRF brought tamper-evident randomness to smart contracts on other chains, with one difference: Suigar leans on Sui’s native randomness instead of an external oracle. And the question you ask shifts. No longer "did the operator reveal an honest server seed" but "what does the public ledger show." Anyone can answer that, no operator permission required.
Seed model versus on-chain VRF, side by side
Both designs swap blind trust for verification. They just place the remaining trust in different spots. Here is the contrast that matters.
- Source of randomness: the seed model blends an operator-made server seed with your client seed. On-chain VRF pulls the random value from the blockchain itself, with no operator-held secret anywhere.
- When you can verify: with seeds you can only check after the server seed is revealed. On-chain, anyone can check the moment the transaction settles.
- Residual trust: the seed model still leans on you trusting where the seed came from and that the reveal will happen. The on-chain model deletes the hidden seed, so nothing is left to take on faith.
- What is unchanged: neither one touches the house edge or the payout table. Both verify that the process was honest, not that your odds got better.
Why this matters for operators, not just players
For a player, the payoff is peace of mind. For an operator, it is a structural call about how much your fairness story rests on trust. A seed-based casino has to guard its server seeds, handle rotations, and stand behind every reveal. An on-chain casino hands the randomness to the chain and the audit trail to the ledger. Fewer parts to secure. Fewer claims a suspicious player can pick apart. That stripped-down setup is exactly what makes a white-label casino on Sui workable without bankrolling or babysitting a private RNG.
It also props up outside validation. Once the randomness and settlement live on-chain and the contracts have been audited by MoveBit (audit completed 2025-11-10), the fairness claim leans on infrastructure a third party can inspect rather than on the operator’s word. Settlement on Sui lands in roughly 390 ms at a fee under $0.01, so producing that public audit trail on every single bet costs almost nothing. Much stronger ground to market from, and to defend if a regulator comes asking.
Common misunderstandings about seeds
A few myths stick to these three terms, and knocking them down makes the whole model easier to reason about. Myth one: changing your client seed improves your odds. It does not. A fresh client seed gives you a different sequence of results, but the probability behind each result stays identical. You are reshuffling the deck, not loading the dice.
Myth two: the published hash of the server seed leaks something you can exploit before play. It does not. A secure hash runs one way only, so you cannot reverse it to recover the seed. Myth three: a revealed seed lets you predict future bets. Nope. The instant a seed is revealed it gets retired, so it only ever helps you verify the past, never call the next round. Every one of these confusions evaporates once you remember what verification is for: checking honesty, not bending odds.
Verifying a result in practice
Reading about verification is one thing. Doing it is what actually builds confidence. On a seed-based site you collect the revealed server seed, your client seed, and the nonce, then run the casino’s stated hashing and mapping steps to rebuild each outcome. On an on-chain casino it is easier still, since the result already sits on the ledger. Our guide on how to verify a casino bet on-chain walks through reading that record straight off the chain, with no seeds to gather and no reveal to wait around for.
The contrast tells you a lot. The seed model hands you a procedure you can only run once the operator cooperates. The on-chain model hands you a fact you can read whenever you want. Both are honest. One just asks less of you, and trusts the operator less in return.
Frequently asked questions
What is a server seed in simple terms?
The casino’s secret random value for a session. The casino commits to it by publishing its hash before you play, then reveals the seed afterward so you can confirm nothing was changed. It is the operator’s ingredient in the outcome.
What is the client seed for?
It is your input into the result. You control it, so the casino cannot fully pre-set your outcomes. Changing it now and then is the simplest way to stamp your own influence on the randomness.
What does the nonce do?
It is a counter that ticks up with each bet on the same seed pair. That is what makes back-to-back bets land on different results even though neither seed changed.
How do I verify a result myself?
Once the server seed is revealed, join all three inputs together (server seed, client seed, nonce), hash that combination with SHA-256 for a 256-bit digest, then map the output onto the game outcome using the casino’s stated method. Matches what you were paid on? The round was honest.
Why is on-chain randomness considered better?
Because it gets rid of the hidden server seed. The random value is generated and stored out in the open on the blockchain, so there is no operator-held secret and no reveal step you have to trust. Anyone can verify, any time.
Does removing the server seed change my odds?
No. Seed pair or on-chain function, the house edge and payout table stay exactly the same. These mechanisms prove the process was fair. They do not tilt the odds your way.
Can I still change my seed on an on-chain casino?
The idea works differently. On a seed-based site, changing your client seed lets you push back on a recipe that hides a value. With on-chain VRF there is no hidden server seed to push back against, because the randomness is drawn in public, from the chain.
The bottom line
Server seed, client seed, nonce. The three gears of classic provably fair gambling. The server seed is the casino’s committed secret, the client seed is your input, the nonce counts your bets, and a hash you can recompute binds them so you can verify any result. A genuine, well-built improvement over a sealed RNG.
The catch sits in the seed’s origin. It still starts life on the operator’s server. On-chain randomness wipes out that hidden value by pulling the result from the blockchain and recording it in public. If you want a fairness story that leans on trust as little as possible, on-chain is the natural next step past seeds.
Sources and further reading
Sui on-chain randomness, Sui documentation.
Verifiable random functions, Chainlink VRF overview.
Smart-contract audits, MoveBit.
Sui developer documentation, Sui docs.
Gambling involves risk and is intended for adults only. Operators are responsible for compliance, age verification, and responsible-gambling practices in every market they serve.
