How Client and Server Seeds Work—and How to Check Them

The client seed and server seed differ in who supplies them and when they are visible. The player supplies or can change the client seed where supported, while the operator generates the server seed and usually keeps its raw value hidden while it is active. In protocols that use this approach, the server seed hash is published before play as a commitment, and the nonce is an additional input that distinguishes calculations using the same seed pair.

These inputs work together, rather than being alternatives to choose between. Not every Provably Fair system uses a seed pair and nonce, so verification must follow the provider’s published protocol, not merely familiar field names. Our introduction to Provably Fair gambling explains the broader principle.

A SHA-256 hash is not an encrypted server seed. It is a fixed-length output of a hash function; disclosure means releasing the original input, not decrypting the hash. Its security relies on practical cryptographic assumptions, not mathematical impossibility of collisions. See the NIST SHA standard.

When should you save the hash and choose a client seed?

Save the operator’s commitment first, then choose an independent client seed if the protocol supports that sequence, and record the inputs accepted for the round. Obtain the old server seed later through the documented disclosure process.

1. Read the protocol. Identify the committed input, encoding, message format, disclosure workflow and conversion from bytes to game outcomes.
2. Save the commitment before wagering. Keep the algorithm description or version with it. A hash supplied only after the result is known establishes string consistency, not that a commitment existed beforehand.
3. Choose your client input after the commitment, where supported. An input that the operator could not predict beforehand limits server seed preselection for that specific input. Once submitted, however, the operator sees it and can compute outputs when it has all required inputs.
4. Record the accepted round data. Save the active seed pair, original nonce, round identifier, displayed outcome and any additional parameters required by the algorithm.
5. Follow the later disclosure workflow. Rotate the seed pair or use the documented alternative, then retain the revealed old server seed with the old history.

In Stake’s documented implementation, rotation reveals the old server seed. That is a protocol-specific workflow, not a guarantee of immediate disclosure after every bet across all casinos. Rotation alone also does not establish unbiased seed selection.

How does the nonce differ from the byte-stream cursor?

The nonce changes the input message for a new calculation; the byte-stream cursor specifies where to read bytes within a calculation. Neither should be reconstructed by counting the bets you can see.

Use the nonce recorded in the original history. A system may share a counter across games, so gaps alone do not prove manipulation. Do not manually reset it or substitute a row number from your own spreadsheet.

In Stake’s implementation, each HMAC-SHA256 block supplies 32 bytes. The HMAC block counter is floor(cursor / 32), while the offset within that block is cursor % 32. One round may consume multiple blocks; one block supplies eight four-byte values.

A new nonce creates a different message, but does not guarantee a unique displayed outcome. Different generated bytes can map to the same game result.

How do seeds generate bytes in Stake’s protocol?

Stake’s published implementation uses the literal UTF-8 server seed as the HMAC-SHA256 key and clientSeed:nonce:blockIndex as the message. Four generated bytes can then produce a fraction, but that fraction is not yet a Dice result or payout.

An ordinary SHA-256 hash of the server seed and an HMAC output are different calculations. The former supports commitment verification; the latter uses a key and message to generate bytes. RFC 2104 defines HMAC’s key/message distinction, while Stake’s implementation defines this particular message format.

The following is a synthetic educational example, not an actual bet. It uses server seed toolsgambling-demo-seed-2026, client seed user-demo-client, nonce 42 and HMAC block counter 0. Run this short sample in Node.js:

const { createHash, createHmac } = require('node:crypto');

const serverSeed = 'toolsgambling-demo-seed-2026';
const clientSeed = 'user-demo-client';
const nonce = 42;
const blockIndex = 0;

const hash = createHash('sha256').update(serverSeed, 'utf8').digest('hex');
const bytes = createHmac('sha256', Buffer.from(serverSeed, 'utf8'))
  .update(`${clientSeed}:${nonce}:${blockIndex}`, 'utf8')
  .digest();
const fraction = [...bytes.subarray(0, 4)]
  .reduce((sum, byte, i) => sum + byte / 256 ** (i + 1), 0);

console.log({ hash, hmac: bytes.toString('hex'), fraction });

The SHA-256 commitment string is:

9d948b54fb3d5557e30a3e100a052de2f83d4d3ad6c0166729528dd059c53b8f

The HMAC-SHA256 output for user-demo-client:42:0 is:

89ae4d041d340aa2798f70bdad3ce5a2d37caf81c723c866c8d87d6a85d55436

Its first four bytes are 137, 174, 77 and 4. Following Stake’s conversion rule, the fraction is:

137/256 + 174/256² + 77/256³ + 4/256⁴
= 0.5378158697858453

Each successive byte contributes a smaller fractional place. No rounding to a game number is applied here: the next conversion depends on the specific game.

The server seed remains the same in every row. This demonstrates determinism: identical inputs reproduce the same calculation, while these input changes produce different values. It does not identify a luckier seed or show any payouts.

Why is this not a universal provider formula?

Other protocols can commit to different data and use a different outcome transformation. In BGaming’s published example, the committed payload includes a server result, secret and game identifier; client input is applied afterward.

Official BGaming source excerpt showing committed JSON with server result 2, a secret and the AmericanRoulette game identifier

BGaming’s original English source excerpt shows a different committed payload. This is a published worked example, not a verified historical wager.

Exact-byte verification matters here: changing whitespace, field order, quotation marks or encoding can change the hash even when the parsed data appear equivalent. Do not replace this payload with a bare server seed or reformat it before hashing.

How can you repeat the ToolsGambling example?

Open the ToolsGambling Provably Fair verifier, select Try with example, then select VERIFY HASH. This standalone example checks SHA-256 and separately demonstrates an HMAC-SHA512 calculation; it does not replay a Stake bet or any named game.

The two screenshots below show an English-language local UI demonstration tested on localhost, not production casino verification.

ToolsGambling example inputs showing the server seed, client seed, commitment hash and nonce

Example inputs populated using Try with example.

1. Open the verifier and select Try with example.
2. Compare its four populated values with the table below. Use the full hash provided here; a narrow screenshot field may show only its beginning.
3. Select VERIFY HASH.
4. Compare the entire calculated SHA-256 hash with the commitment hash, not just its first characters.
5. Treat the additional 78.35 value only as the output of this demonstration’s formula.

ToolsGambling example results showing a matching SHA-256 hash and the illustrative value 78.35

The hash match concerns the entered string. The value 78.35 comes from a separate ToolsGambling demonstration formula.

That additional calculation uses HMAC-SHA512 with the literal UTF-8 server seed as its key and user-demo-client:42 as its message:

Here, 78.35 comes from dividing the remainder, not rounding the fraction in the Stake example. The HMAC algorithm, message and conversion are all different.

For a real round, use this commitment check only if the protocol specifies SHA-256 of the literal UTF-8 server seed. If it commits to another payload or requires different serialization, use the exact official algorithm or provider verifier instead.

What does a matching hash prove?

A matching hash verifies that disclosed data are consistent with the saved commitment; result replay additionally requires the exact game algorithm and recorded inputs. Independent audit or certification is a separate level of assurance.

Commitment verification requires the disclosed original input and the commitment recorded before wagering. Result replay also requires the correct key, message, encoding, separators, nonce, HMAC block counter, byte-stream cursor and conversion rules, wherever applicable. Compare the reconstructed outcome with the recorded result; checking settlement also requires the payout rules.

Even the standalone tool’s GAME IS FAIR banner means only that its hash comparison matched. One hash does not establish RTP, licensing, reliable withdrawals, unbiased seed selection or overall operator integrity. For more detail, see our verification guide and Provably Fair versus certified RNG comparison.

Before using the educational widget below: its commitment check always uses SHA-256. Selecting HMAC-SHA256 or HMAC-SHA512 affects only the calculation using client:nonce. Its Dice and Crash fields are illustrative—not exact Stake formulas or formulas for any other provider. Do not use these game numbers as casino outcome proof, and do not confuse this widget with the standalone ToolsGambling demonstration above.

What changes when you rotate the seed pair?

Seed-pair rotation changes the inputs for future calculations and may disclose the old server seed under the protocol. It does not alter accepted bets or create more favorable probabilities.

Before rotation, save the old history, commitment hash and client seed. After disclosure, add the old server seed: historical rounds remain checkable using their original inputs.

For the next pair:

• Save the new commitment before submitting a new client seed, if the protocol supports this order.
• Choose independent client input where editing is supported.
• Check the available records to confirm which pair and nonce were accepted for the next bet.
• Do not substitute the new pair into an old round’s calculation.

Rotate for disclosure and auditing, not for a lucky streak or a mandatory 50–100-bet schedule. Possessing the active seed’s hash does not reveal its hidden raw value.

What should you do if verification fails?

First check the inputs and algorithm: a mismatch alone does not prove manipulation. Preserve the original evidence before correcting anything so the discrepancy remains reproducible.

If the discrepancy persists, retain the commitment, when you obtained it, round history, original strings and algorithm version. Give support a reproducible mismatch rather than only a screenshot of a warning.

Verification does not imply a working “predictor” or winning seed. Replaying a completed round after disclosure is different from predicting a future result with a hidden server seed. No wallet secrets are needed for verification.

Can a new client seed improve expected profit?

No: changing the client seed does not by itself improve the probabilities or house edge in a specified game model. Verifiability and a favorable bet are different questions.

For a hypothetical example, assume a 50% win probability and a gross payout of 1.98 per unit wagered, including the returned stake. Expected payout per unit is 0.5 × 1.98 = 0.99, giving 99% RTP and a 1% house edge.

With total wagering turnover of 1000, expected net profit is −10. Turnover means the sum of all wagers, not necessarily the initial deposit. These figures describe only this conditional model, not an actual game’s RTP or a guaranteed session result. Changing a seed changes the calculation input; it does not remove negative expected value.