StakeStats
10SC Free

Verify Any Bet Without a Terminal: Client Seed Explained

See how client seeds, server seeds, and a nonce produce provably fair results. Follow a five-step verification and a worked hash-to-dice example, then...

By Seal · 2026-09-03

Verify Any Bet Without a Terminal: Client Seed Explained

Verify Any Bet Without a Terminal: Client Seed Explained

Analyst verifying client seed result

A client seed is the random string you control that gets combined with an operator's secret server seed and a per-bet nonce to generate a game result. That combination is what lets you, not the casino, recompute the outcome after the fact. Without your client seed in the mix, there's nothing to verify: the operator alone could produce any number it wanted.

TL;DR:

  • A strong client seed should be unpredictable and unique, preferably generated with a secure random tool rather than accepting default or short seeds.
  • Verifying game outcomes requires recording the server seed hash, client seed, and nonce before betting, then recomputing hashes after the session to confirm results.
  • Most platforms use HMAC-SHA512 for hashing, with outcome calculations based on slicing the hash and scaling the number to the game's range; check specific documentation for precise methods.
  • Manual verification is impractical for multiple bets, so using an automated tool like Stake's verification system minimizes errors and streamlines proof of fairness.
  • If a platform does not allow user-set client seeds or shows missing or inconsistent seed information, consider it a red flag for compromised fairness.

Table of Contents

What Is a Client Seed and How Does It Work?

Three inputs generate every provably fair result: the client seed, the server seed, and the nonce. The client seed is a player-controlled string you either type in yourself or accept as an auto-generated default. The server seed is a secret value the operator holds, and the nonce is a counter that ticks up with every bet you place, so bet #1 and bet #2 never produce the same output even with identical seeds.

Here's the sequence that turns those three inputs into a number you can check:

  • The operator generates a server seed and publishes its cryptographic hash before you place a single bet. That's the commitment step.
  • You place bets. Each one runs your client seed, the current server seed, and the nonce through a hash function.
  • The hash output gets converted into the number you see on screen: a dice roll, a crash multiplier, a card draw.
  • Once you rotate seeds or end the session, the operator reveals the original, unhashed server seed.
  • You hash that revealed seed yourself and confirm it matches the hash published earlier.

That published hash is the entire point. If the operator could change the server seed after seeing your bet, they could rig any outcome. Provably fair systems close that loophole by forcing the commitment before play starts.

How Do You Verify a Client Seed Result?

Verification isn't complicated, but it does require you to have saved the right values before you started playing. Here's the actual sequence:

  1. Before betting, record the published server-seed hash and note your current client seed. Screenshot both if the interface allows it.
  2. Place your bets as normal, keeping track of which nonce corresponds to which round if you want to check a specific bet later.
  3. After the session or seed rotation, copy the revealed (unhashed) server seed and the exact nonce tied to the bet you're checking.
  4. Run the hash function the platform documents (HMAC-SHA512 or SHA-256, whichever it discloses) using the server seed, your client seed, and that nonce as inputs.
  5. Compare your derived result to what the game displayed. They should match exactly.

If they don't match, don't assume you've caught fraud. Check four things first: whether the revealed server seed actually hashes to the value published earlier, whether you used the correct algorithm, whether the platform's nonce convention starts at 0 or 1, and whether a mid-session seed rotation shifted which server seed applies to that bet.

Pro Tip: Keep a simple spreadsheet with three columns: server seed hash, client seed, and date. It takes ten seconds per session and turns a "trust me" system into something you can actually audit later.

Stakestats built a provably fair explanation tool specifically because most players skip this step, not because it's hard, but because copying hex strings into a terminal isn't anyone's idea of fun.

The Cryptographic Mechanics Behind Client Seed Verification

Most modern platforms use HMAC-SHA512 rather than plain SHA-256, and the reason matters. HMAC (Hash-based Message Authentication Code) uses the server seed as a cryptographic key rather than just folding it into a plaintext message, which closes off certain manipulation attacks that plain hashing doesn't guard against as tightly.

The nonce does the heavy lifting for uniqueness. Some engines add a second counter, called a cursor, that increments within a single bet when a game needs more than one random number, like drawing five cards instead of rolling one die.

Converting a hash into a usable number follows a predictable pattern:

  • Take the first several hex characters of the hash output (commonly 8).
  • Convert that hex string into an integer.
  • Divide by the maximum possible value for that byte length (2^32 for 8 hex characters).
  • Scale the resulting fraction to the game's actual range, whether that's 0 to 100 for a dice game or 0 to 1 for a crash multiplier.

Implementations diverge on byte length, rounding rules, and which slice of the hash they use. One site might take the first 8 hex characters; another takes the last 13. Neither approach is more "correct," but each requires you to check the specific documentation for the game you're auditing before you can reproduce its math by hand.

A Worked Example: From Hash to Dice Roll

Here's what the actual computation looks like, stripped down to pseudocode you could run in Python or JavaScript in about ten lines:

  1. Build the message string: client_seed:nonce:cursor (for example, myseed123:47:0).
  2. Run HMAC using the server seed as the key and that message as the input, producing a long hex digest.
  3. Extract the first 8 hex characters of that digest.
  4. Convert those 8 characters from hexadecimal into a base-10 integer.
  5. Divide that integer by 4,294,967,295 (which is 2^32 minus 1) to get a decimal between 0 and 1.
  6. Multiply by 100 to land on a dice-style result between 0.00 and 100.00.

Say the first 8 hex characters come out to 3f8a91c2. Converted to an integer, that's roughly 1,065,701,314. Divide by 4,294,967,295 and you get about 0.2482. Multiply by 100, and the displayed roll is 24.82. That's the entire pipeline: three inputs, one hash, one slice, one scaling formula.

Some games extract the last 8 characters instead of the first, or use a different divisor for a wider result range. The math is identical in spirit; only the slicing point and scale factor change.

Hash extraction and dice roll process

Best Practices for Choosing and Rotating a Client Seed

A weak or predictable client seed doesn't break the math, but it hands away the one variable you're supposed to control. Auto-generated default seeds are often short and alphanumeric, which is fine for casual play but not what you want going into a high-stakes session.

  • Generate your own seed using your browser's random string tools or a long, unpredictable passphrase rather than accepting the short default.
  • Rotate your client seed before any session where the stakes justify the extra ten seconds it takes.
  • Save the server-seed hash somewhere outside the platform (a note app, a spreadsheet) before you place your first bet of the session.
  • Watch for red flags: no pre-commit hash shown anywhere, a revealed seed that doesn't hash to match what was published earlier, or missing nonce data that makes reconstruction impossible.

Pro Tip: If a platform doesn't let you set your own client seed at all, treat that as a real limitation, not a minor inconvenience. Player-chosen seeds are the entire mechanism that keeps the operator from being the only party who influences the result.

Why Verification Tools Matter More Than the Math Itself

Why Verification Tools Matter More Than the Math Itself — overview diagram

The math behind client seeds is sound, but almost nobody uses it. Manual verification requires hashing algorithms, hex conversion, and comfort with a terminal, so most players default to trusting a platform's reputation instead of actually checking anything. Community discussions on forums like Reddit repeatedly show players who understand that a seed exists but not what it does or how to change it meaningfully.

That gap is exactly where automated tooling earns its keep. Stakestats built its verification and analyzer tools around the idea that provable fairness only means something if people actually use it. Running the Stake Originals Analyzer against thousands of historical bets turns a one-off manual check into a routine habit, which is the only way "provably fair" becomes more than a marketing phrase stamped on a footer.

— Ian

Verify Your Bets Without Touching a Terminal

Running HMAC hashes by hand works fine for one bet. It stops being practical the moment you want to check a hundred rounds across a session. Stakestats' provably fair verification tool automates the entire recompute-and-compare process for Stake Engine games, so you get the same cryptographic proof without opening a code editor.

Stakestats

Pair that with the Stake Originals Analyzer if you want RTP, volatility, and hit-rate data layered on top of the fairness check itself, useful when you're deciding which games are worth your bankroll before you ever place a bet. Head to the Stake Engine tools page to run your first verification and see exactly how your last session's results were generated.

Sources