Every provably fair round across the ten operators we audit depends on the same three values. Once you understand what each one does and why all three are needed, the rest of the fairness pipeline (the SHA-256 commitment, the HMAC byte-stream, the brand-published mapping formula) starts to make sense as one connected mechanism rather than a stack of crypto jargon. This post walks through the role of each input separately, the meaning of the nonce in gambling math, and then through the provably fair seed rotation flow that ties them together.
If you have not read the foundational primer yet, that is the better starting point, it covers the high-level guarantee and the boundary of what verification proves. This post assumes the primer is read and dives into the seed mechanics.
- Server seed: operator-generated, hashed before the bet, revealed when you rotate. Carries the commitment anchor.
- Client seed: player-controlled, can be rotated at any time. Carries the player-side trust anchor.
- Nonce: per-bet counter, increments by one on every bet. Carries the uniqueness anchor.
- All three feed into HMAC-SHA256 together. Take any one away and the guarantee collapses.
Why server seed, client seed, and nonce together (not one input)
A fairness scheme with only a server seed would let the brand pre-compute outcomes and serve them at will. A scheme with only a client seed would have nothing committed by the brand at all. A scheme with only a server-plus-client seed would produce the same outcome on every bet, because there would be no per-bet variable. Each input solves a different problem.
- The server seed is the brand's contribution. It is what the brand commits to via the published SHA-256 hash before the bet. Once committed, it cannot be changed without breaking the hash check.
- The client seed is your contribution. By making the client seed an input, the brand cannot pre-compute outcomes against the specific server seed in isolation, your value joins the calculation and is rotatable by you.
- The nonce is the per-bet counter. It guarantees that even with the same server seed and same client seed, every consecutive bet produces a different HMAC output.
The three together produce a deterministic byte stream that the brand's published mapping formula turns into the visible round (chip path on Plinko, cash-out point on Crash, bomb layout on Mines).
Server seed: the commitment anchor
The server seed is a random string generated by the brand. The byte length depends on the brand; commonly 32 or 64 hex characters. Before any bet you place with this seed, the brand publishes its SHA-256 hash in the game UI's fairness panel.
That hash is the commitment. SHA-256 is a one-way function: given the seed, anyone can compute the hash; given the hash alone, nobody can recover the seed. the brand broadcasts the hash, then keeps the seed itself private until you choose to rotate.
While the server seed is private, the brand can use it across thousands of consecutive bets, each with a different nonce, and you cannot recover the seed even if you have all the HMAC outputs in the world. That is what makes the scheme practical for a casino: the brand does not have to publish a fresh server seed for every single drop on Plinko.
- Pre-bet: server generates a random seed, computes its SHA-256, publishes the hash in the UI.
- In use: every bet you place with this server seed pulls the next nonce, runs HMAC, returns an outcome. The seed stays private.
- Rotation request: you click "rotate server seed" in account settings. Operator stops using the seed for any new bets.
- Reveal: operator displays the raw seed. You hash it locally. The hash must equal the original commitment.
- Verification: with the revealed seed, you can replay HMAC for any past bet on that seed and confirm the outcome.
- New seed: operator generates a new server seed and publishes its hash. Cycle restarts.
The commitment anchor depends on the brand not changing the server seed mid-stream. If they did, the hash of the revealed seed would not match the original commitment, and you would catch the mismatch. That is what makes the scheme tamper-evident: lying breaks SHA-256, which is harder than any brand-side incentive could justify.
Client seed: the player-side anchor
The client seed is a string controlled by you. On the typical UI it starts at an operator default (often the casino domain plus a timestamp). You can leave it as-is, type your own value, or rotate it later. Any string works as a client seed, the casino does not constrain its content beyond a length limit.
The reason the client seed exists is to prevent a specific attack: an operator who knows the server seed in advance and runs the casino. Without a player input, that operator could pre-compute the outcome of every future bet against the committed server seed and arrange the UI to serve favourable losses. Including the client seed in the HMAC calculation makes that attack impossible because the brand cannot pre-compute against an input they do not know.
- After a big loss session that felt unusual. Rotating client seed forces the HMAC stream into a different deterministic path from that point onward, which is a psychological clean-slate.
- After any session where you suspect brand-side observation of your client seed (rare; the seed is not secret, but rotating is free).
- When you change brand-game (some players prefer different client seeds per game type as an organisational habit).
- Before publishing a verification chain in editorial work or community posts, so the client seed in the chain reflects what you actually used.
- Never feel obligated to rotate it for "luck" reasons, rotation does not change the long-run RTP. Each round remains independent.
The client seed is not secret. It is published in the same fairness panel as the server seed hash and the nonce. The protection is not from anyone knowing the value; the protection is from the brand being unable to commit to a server seed that depends on your client seed in any sophisticated way.
Nonce: the uniqueness anchor
The nonce is a counter that increments by one on every bet you place with the active server seed and client seed pair. Most operators start the counter at zero or one when a fresh server seed is committed, and increment per bet.
Without a nonce, every bet with the same (server seed, client seed) pair would produce the same HMAC output, which means the same outcome. The nonce guarantees per-bet uniqueness.
- Does: ensure two consecutive bets on the same seed pair produce different HMAC byte streams.
- Does: let you replay any historical bet by feeding the same (server seed, client seed, nonce) into HMAC-SHA256.
- Does NOT: introduce additional randomness. It is a simple deterministic counter.
- Does NOT: reset on rotation of the client seed alone. (Some operators reset, some keep counting. Check operator documentation.)
- Does NOT: protect against operator manipulation if the server seed itself is compromised. Nonce is a uniqueness primitive, not a security primitive.
The nonce is displayed in the fairness panel for the bet currently being placed and for any historical bet you look up. Saving the nonce along with the server seed hash and client seed is part of any verification work.
How server seed, client seed, and nonce feed HMAC-SHA256
The cryptographic call that produces the byte stream is:
``
HMAC-SHA256(key = server_seed, message = client_seed + ":" + nonce)
`
The separator and concatenation style depends on the brand's published formula. Stake uses client_seed:nonce. Some operators use client_seed-nonce` or include a cursor counter for games that need multiple bytes per round (Plinko 16-row drops consume 16 bytes for direction decisions; Mines reveals consume one byte per tile pick).
The output is a 32-byte (256-bit) hex string. the brand's mapping formula tells you how to slice those bytes into game outcomes. For deep detail on the byte-mapping per mechanic class, see the algorithm post.
Provably fair seed rotation flow end-to-end
Putting the three inputs together, a typical session goes like this:
- Start of session: operator commits a server seed by publishing
sha256(server_seed). Your client seed shows in the UI; you can rotate it now if you want a custom value. Nonce shows zero or one. - Bet 1: nonce increments. HMAC-SHA256 produces output. Mapping formula gives outcome. UI shows you the result.
- Bet 2: nonce increments again. Different HMAC output (because nonce changed). Different outcome. Result shown.
- Bet N: continue. Nonce keeps incrementing.
- You rotate the server seed: operator stops using the current seed for any new bets. Reveals the raw seed.
- Local verification: you SHA-256 the revealed seed. Hash matches the original commitment? Anchor one passes.
- You pick a historical bet: take its (server seed, client seed, nonce) and run HMAC-SHA256 yourself. Apply the brand's mapping formula. The output you get must match the outcome the casino recorded.
- Anchor two passes: the round was honest math.
- New server seed: operator commits a new one. Cycle restarts.
The rotation is the gating event. As long as a server seed is in active use, you cannot verify any bet placed against it (because the seed is private). Only after rotation does the revealed-seed step become available. Most players rotate after sessions, but you can rotate at any moment.
Common pitfalls with server seed, client seed, and nonce
A few recurring confusions show up in community posts and editorial work. They are worth flagging because they affect whether your verification actually proves anything.
- Verifying before rotation. Some players try to verify a bet while the server seed is still in active use. That cannot work, because the raw server seed has not been revealed yet. Rotate first, then verify.
- Mixing client seeds. If you rotated the client seed mid-session, bets placed before and after the rotation will use different client-seed values. Make sure the client seed in your HMAC call matches the one active at the moment of the bet.
- Wrong nonce. Off-by-one errors are common. Some operators start at zero, some at one. Some reset on client-seed rotation, some do not. Pull the exact nonce from the bet history, not your memory.
- Wrong concatenation format. The order and separator of the HMAC message string varies per operator. Stake uses
client_seed:nonce. Some use a different format. Match the brand-published formula exactly. - Cursor advance for multi-byte rounds. Plinko 16-row drops consume 16 separate byte-decisions per round, not one. Mines reveals consume one byte per tile click, with the byte cursor advancing across the HMAC output. If you only use the first byte, you only verify the first decision of the round.
Variations across the ten audited operators
The general scheme is consistent across our audit set, but specific implementations differ in detail. We tested each of the ten brands in our most recent 90-day cycle and ran the same three-input reproduction on every fairness panel. The differences do not affect whether the verification works, they affect how the brand structures the UI and the mapping formula.
- Stake: reference implementation.
client_seed:nonceconcatenation. Cursor variable for multi-byte rounds. Full UI exposure of all three values. - Roobet: inline fairness panel inside the game tab. Same HMAC pipeline. Smaller UI footprint than Stake.
- Shuffle: identical scheme inherited from the Stake-alumni founder team. Anjouan-licensed.
- Gamdom: standard scheme. Marketing claim of "100% RTP" on some games does not affect the seed mechanics.
- BetFury: standard HMAC pipeline. The BFG token economy does not interact with seed rotation.
- Rollbit: standard scheme. The RLB-token VIP overlay does not interact with seed rotation.
- Duel: standard scheme. 99.9 percent RTP target.
- Fairspin: a stronger variant where the per-round commitment is also written to a public blockchain in addition to the SHA-256 hash. Same three-input HMAC structure underneath.
- Winna: standard scheme. The 7-minute rakeback cadence sits on top of the cashier, not on top of the seed mechanics.
- Yeet: standard scheme. Smaller catalogue, no token layer.
Why the three-anchor design resists adversarial operators
If you imagine an operator with an incentive to lie about a specific roll, the design forces them to break one of three things to succeed:
1. Pre-image SHA-256. the brand would have to find a different server seed that hashes to the same commitment. SHA-256 has resisted pre-image attacks for two decades. Breaking SHA-256 would be a generational cryptographic event. 2. Forge HMAC-SHA256. the brand would have to produce HMAC outputs that did not come from the published seeds. HMAC-SHA256 has the same security base as SHA-256. 3. Defraud the player-controlled client seed. the brand cannot control what client seed you typed. If they tried to compute an outcome that depends on a specific client seed value other than yours, they would produce a result that does not match what you would compute.
Each of those failure modes is either mathematically infeasible or detectable. The adversarial resistance does not require the player to trust the brand. It requires the player to trust SHA-256, which is the same primitive securing your Bitcoin wallet.
Frequently asked questions
What is the server seed vs the client seed?
The server seed is generated and committed by the brand before the bet. The client seed is controlled by you and can be rotated at any moment. Both feed into the same HMAC-SHA256 call; the difference is who controls each value.
How does the nonce ensure two bets produce different outcomes?
The nonce is included as part of the HMAC message string. Two bets with the same server seed and client seed but different nonces produce different HMAC outputs by design, SHA-256 maps even tiny input differences to wildly different outputs.
Is it safe to rotate the server seed frequently?
Safe and useful. Any one rotation event triggers a fresh commitment. But the math is the same whether you rotate after every bet or after a thousand bets. Frequent rotation is convenient for verification (smaller batches to replay) and useful as a habit. It does not change the underlying fairness guarantee.
Server seed vs client seed, who controls each?
Server seed is generated by the brand and committed by SHA-256 hash before the bet; it stays private until you rotate. Client seed is yours; you can type any string, leave the default, or rotate at will. The split is what makes the scheme tamper-evident on both sides.
How much friction does seed rotation add for the average player?
Almost none. Rotation is one click in the fairness panel on every brand we audit. The cost is zero; the only ongoing requirement is saving the active client seed and nonce range if you plan to verify later.
Where can I find the current nonce in the UI?
every brand in our audit set shows the next nonce in the fairness panel before each bet, and the nonce of every historical bet in the bet history. Exact UI placement differs per brand; check the per-brand audit pages on this site for screenshots.
Where to go next on server seed, client seed, and nonce mechanics
Once the three-input HMAC scheme makes intuitive sense, the next steps are either to dive into the byte-level mapping that converts HMAC output into a visible game outcome, or to run the seed rotation and verification yourself. These follow-up posts continue the provably fair seed rotation work from a different angle.
- For the byte mapping that turns HMAC output into a visible Plinko / Crash / Mines result, read the algorithm internals post.
- For the worked walkthrough on a real Stake Plinko roll using all three inputs, read the seven-step verification walkthrough.
- For the high-level explainer if you skipped it, read the introductory primer.
- For how our editorial team uses seed rotation in the 90-day audit cycle, see the methodology page.
Authority sources
- The Bitcoin.com gambling registry catalogues seed-implementation specifics across operators.
- GamCare and BeGambleAware inform the responsible-play guidance referenced in the brand-game audit pages.
The editor on this post is Karssen Avelara. Corrections and questions: editor@casino-originals.com.
Karssen Avelara · editor@casino-originals.com