Server Seed Client Seed

The three inputs that make a casino round mathematically verifiable

Every provably fair round at Stake, BC.Game, Roobet, Shuffle, Cloudbet and any other crypto casino running the protocol resolves from exactly three inputs: a server seed, a client seed, and a nonce. The server seed is the casino's secret committed before betting begins. The client seed is the player's contribution, editable at any time. The nonce is a counter ensuring identical seeds produce different outcomes per round. Together they feed an HMAC-SHA512 (or sometimes SHA-256) hash function, the output of which is converted into the game's result. This guide is a deep dive into the cryptography — not the user-facing fairness panel, but what happens at the byte level when a Dice roll or Plinko drop resolves. By the end you will be able to recompute any Stake bet from its inputs and understand why every reputable operator publishes their hashing algorithm in full.

What is a server seed?

A server seed is a long random hexadecimal string — typically 64 characters representing 256 bits of entropy — generated by the casino server. The seed is the secret half of the commitment scheme. It is generated using a cryptographically secure pseudo-random number generator (CSPRNG), usually pulling from operating-system entropy sources (/dev/urandom on Linux), and stored in a database with a hashed reference.

The casino does not reveal the server seed at generation. Instead, the SHA-256 hash of the seed is published in the player's fairness panel — a 64-character hex string that uniquely identifies the seed but cannot be reversed to recover the seed itself. SHA-256 is a one-way function: given the hash, computing the original requires brute-forcing 2^256 possibilities, which is computationally infeasible.

The seed remains secret throughout the session. When the player chooses to "rotate" seeds — typically by clicking "rotate" in the fairness panel — the server seed is revealed and a new one is generated. The new seed's hash is shown immediately; the old seed is published so the player can hash it themselves and confirm it matches the original committed hash. Any tampering between commit and reveal would break the hash match.

What is a client seed?

A client seed is the player's contribution to the round's entropy. It is a string of any length, editable by the player at any time, that the casino combines with its server seed to produce the outcome. Most casinos auto-generate an initial client seed (Stake uses an eight-character alphanumeric), but the player can replace it with anything — a word, a timestamp, a friend's name. As long as the player picks something the casino could not have predicted at the moment the server seed was generated, the casino cannot bias the round.

Why this matters: if only the casino contributed entropy, it could in principle generate many candidate server seeds, compute outcomes for each, and pick the one most favorable to the house — then commit to that seed's hash. Adding the player's seed breaks this. The casino has to commit to its server seed before seeing the client seed (or before the next session begins), so it cannot bias outcomes by seed-shopping.

For maximum paranoia, change your client seed regularly. Some serious players rotate before every high-stakes session. The choice does not need to be random in a cryptographic sense — it only needs to be unpredictable to the casino at the moment they committed.

What is a nonce?

A nonce is "a number used once" — in provably fair systems, an integer counter that increments by one on every bet. The first bet under a given seed pair uses nonce 0 (Stake) or 1 (some others), the second bet uses 1, then 2, and so on. The nonce is what allows the same seed pair to produce different outcomes for every bet without the casino changing the seeds mid-session.

The cryptographic role: HMAC-SHA512 is deterministic. Given identical inputs it produces identical outputs. Without the nonce, every bet under one seed pair would have the same outcome — useless for a casino. With the nonce, each bet's outcome is deterministically tied to a unique input combination, so each bet has a fresh random-looking result, but every bet remains verifiable from the three published inputs.

Some games use additional cursors. Stake Crash includes a "cursor" parameter that increments through the hash output to produce multiple game-relevant numbers from a single HMAC computation. For Dice, only the first eight characters of the hash are used; for Crash, the algorithm processes hash chunks differently.

How outcomes resolve step by step

The full computation for a Stake Dice roll, in order:

1. Inputs: server seed (64 hex chars), client seed (string), nonce (integer).
2. Construct the HMAC message: concatenate client seed, nonce and cursor with colons. For Dice: client_seed:nonce:0.
3. Run HMAC-SHA512: using the server seed as the key and the constructed message as the message. Output is a 128-character hex string.
4. Take the first eight characters: e.g., 3a7b9c2d.
5. Convert to a 32-bit unsigned integer: 3a7b9c2d hex = 980,065,837 decimal.
6. Divide by 2^32 (4,294,967,296): 980065837 / 4294967296 = 0.22818... — a float between 0 and 1.
7. Multiply by 10,001 and floor: 0.22818 × 10001 = 2,282.1 → 2,282.
8. Divide by 100: 22.82 — the displayed Dice roll value.

If the player bet on "roll under 50" with target 50.00, the roll of 22.82 wins. The casino reveals the inputs after the round (or at seed rotation), the player re-runs the algorithm, the result matches, fairness confirmed. If the player ran the verification and got a different number, the round was tampered.

Practical examples — verifying outcomes

The verifier on Stake's site embeds an open-source JavaScript implementation. The full procedure, manually:

1. Find the bet in your "Bet History" or "Casino → My Bets".
2. Click the bet to expand. Stake shows server seed, client seed, nonce and computed result.
3. Open the Verify page. Paste the four inputs.
4. The page recomputes the result client-side in your browser. The displayed result should match the bet's outcome.

For a deeper check, run the algorithm in your own environment:

// Node.js example for Stake Dice
const crypto = require('crypto');
const serverSeed = '...';      // revealed after rotation
const clientSeed = '...';
const nonce = 0;
const message = `${clientSeed}:${nonce}:0`;
const hash = crypto.createHmac('sha512', serverSeed)
                   .update(message).digest('hex');
const slice = hash.slice(0, 8);
const integer = parseInt(slice, 16);
const float = integer / Math.pow(2, 32);
const roll = Math.floor(float * 10001) / 100;
console.log(roll);  // matches Stake's displayed roll

BC.Game uses a similar HMAC-SHA256 approach with slightly different formatting. Spribe games (Aviator, Mines, Plinko) publish their algorithm in the in-game verifier. BGaming publishes a full algorithm specification on their developer documentation site.

Common mistakes and red flags

The math works only if a few preconditions hold:

• The server seed hash must be published before any bet. If the fairness panel shows only the seed after the round, with no committed hash, the casino could have generated the seed after seeing the bet. Look for the hash, screenshot it for high-stakes sessions.
• Rotation must reveal the original seed, not a substitute. Check that the revealed seed hashes to the originally committed hash. If it does not, the casino swapped seeds.
• The verifier must be open-source. A closed verifier the casino runs internally is not verifiable. Stake, BC.Game and BGaming publish their algorithms in full.

Subtle points: the nonce increments per game type per seed pair, not globally. If you switch from Dice to Crash mid-session, Crash typically starts at nonce 0 for that seed pair. If you switch back to Dice, Dice's nonce continues where it left off. Some operators reset the nonce on seed rotation; others increment continuously.

FAQ

Why use HMAC instead of plain SHA-256? HMAC includes the secret key (server seed) as part of the construction, preventing length-extension attacks and ensuring the server seed cannot be inferred from outputs. SHA-256 alone is fine for simpler implementations but HMAC-SHA512 is the modern standard.

Can I predict outcomes if I change my client seed many times? No. The server seed is unknown to you until reveal. Without the server seed, no combination of client seeds and nonces lets you compute future results.

Why does Crash have a "previous block hash" mechanism? For multi-round commit chains. The server seed for round N+1 is the SHA-256 of round N's server seed. The whole chain is revealed at rotation, so every round in history can be verified independently.

Are all in-house games provably fair? The major ones at Stake (Dice, Plinko, Mines, Crash, Limbo, Hilo, Keno, Wheel, Slide, Diamonds, plus 15 more) and BC.Game (74+ originals) are. Third-party slots are not — they use RNG audits instead.

What is the difference between provably fair and RNG-certified? Provably fair lets the player verify each round independently. RNG-certified means a lab tested the RNG and audits it periodically. Provably fair is mathematically stronger but only applies to games where the casino controls the entire logic.

Updated 22 May 2026.