how to verify client seed and server seed: Full Guide

Key takeaways

how to verify client seed and server seed: check the server-seed hash commitment, recompute the HMAC-SHA256 with your client seed and nonce, and reproduce the raw hash bytes.
Use a third-party verifier or run a short Python/Node script to recompute the HMAC and confirm the revealed server seed matches the pre-round SHA-256 hash.
Converting hash bytes to game results (dice, crash, plinko) requires a game-specific formula—common examples are provided, but always verify provider documentation.
Provably fair proves a round’s randomness came from the revealed seed pair, not that the game’s RTP or house edge is guaranteed.
Log client seeds, server-seed hashes and nonces before big bets. Keep screenshots or exported logs for a full audit trail.

Direct answer

how to verify client seed and server seed: first confirm the server seed hash (the SHA-256 commitment) published before play; then compute HMAC-SHA256 using the revealed server seed as key and the string formed by your client seed plus the round nonce as message. If the HMAC-derived hex matches the game’s output and the revealed server seed hashes back to the published commitment, the round outcome derives from that seed pair.

Why you should verify client seed and server seed

Provably fair systems let you independently confirm that a game result came from a specific server seed combined with your client seed and the round nonce. Verification builds trust. It removes the need to trust only the operator’s on-site widget.

It does not replace understanding RTP or house edge. Provably fair confirms randomness, not payout rules or odds. For math on house edge and long-run expectation, reputable references such as Wizard of Odds explain casino maths in depth.

Core concepts: client seed, server seed, nonce and commitment

Keep these definitions in mind:

Client seed: a value you set in your account or per session. You can use the default or supply your own. It is public and part of the input to the HMAC.
Server seed: a secret generated by the casino for each seed period. Before play the casino publishes the SHA-256 hash of the server seed (the commitment). After rounds or at rotation it reveals the plain server seed so players can verify.
Nonce: a counter that increments each round for the same seed pair. It prevents reuse. Typical format: 0, 1, 2… or a round ID.
Commitment phase: the casino publishes SHA-256(server_seed). That commitment proves the casino cannot change the server seed later without detection.

how to verify client seed and server seed: the two-step model

Verification has two separate checks. Both must pass for a clean audit:

Commitment check: SHA-256(revealed_server_seed) ?= published_server_seed_hash.
Outcome reproduction: HMAC-SHA256(key=revealed_server_seed, message=client_seed + nonce) ?= hash used to derive the game outcome.

Both checks use well-known cryptographic functions: SHA-256 for the commitment and HMAC-SHA256 for generating per-round entropy.

Common HMAC patterns and how to detect which one a game uses

Different platforms use slightly different concatenation styles. The two most common patterns are:

message = client_seed + '-' + nonce
message = client_seed + ':' + nonce
message = client_seed + nonce (no separator)

To detect which pattern a game uses, try reproducing the HMAC with each pattern and compare to the game’s published round hash. A match indicates the correct pattern.

Practical scripts: compute HMAC-SHA256 and check commitment

Below are two short, copy-pasteable examples you can run locally. They compute the SHA-256 of the revealed server seed, compute HMAC-SHA256 with a chosen pattern, and print the hex result. Adjust client_seed, nonce and revealed_server_seed for your round.

Python (local verification)

Save as verify_round.py and run with Python 3.6+.

Script (replace values as needed):

import hashlib, hmac client_seed = "your-client-seed" nonce = "1" # or the round nonce revealed_server_seed = "REVEALED_SERVER_SEED_HEX_OR_TEXT" published_server_seed_hash = "PUBLISHED_SHA256_HEX" # Commitment check computed_commit = hashlib.sha256(revealed_server_seed.encode()).hexdigest() print("commit matches:", computed_commit == published_server_seed_hash) print("computed_commit:", computed_commit) # HMAC-SHA256 (try a few separators) for sep in ["-", ":", ""]: message = f"{client_seed}{sep}{nonce}".encode() h = hmac.new(revealed_server_seed.encode(), message, hashlib.sha256).hexdigest() print(f"hmac (sep='{sep}'):", h)

Node.js / JavaScript (browser console or node)

Requires Node.js to run with built-in crypto.

Script:

const crypto = require('crypto') const clientSeed = 'your-client-seed' const nonce = '1' const revealedServerSeed = 'REVEALED_SERVER_SEED' const publishedHash = 'PUBLISHED_SHA256' // Commitment check const commit = crypto.createHash('sha256').update(revealedServerSeed).digest('hex') console.log('commit matches:', commit === publishedHash) console.log('commit:', commit) // HMAC patterns ['-', ':', ''].forEach(sep => { const message = Buffer.from(clientSeed + sep + nonce) const hmac = crypto.createHmac('sha256', revealedServerSeed).update(message).digest('hex') console.log(`hmac (sep='${sep}') :`, hmac) })

How to convert hash bytes into game outcomes (common formulas)

Once you have the HMAC hex, the game maps those bytes to an outcome. The mapping is game-specific. Below are commonly used conversions. Treat them as practical examples—check the game's docs or on-site verifier to confirm the exact mapping.

Dice (0.00 - 99.99 typical)

Common method: take the first 4 bytes (8 hex chars) of the HMAC, convert to an integer, divide by 2^32 and scale to 0-100.

hex_part = hmac_hex[0:8]
int_val = int(hex_part, 16)
result = (int_val / 2**32) * 100
round to the precision the game uses (often two decimals).

This yields a uniformly distributed number in [0,100).

Crash (multiplier) — common 52-bit method

A widely used crash formula uses 52 bits of entropy. The steps below show a common variant. Many independent verifiers use the same approach, but confirm with the game’s documentation before assuming exact constants.

Take the first 13 hex characters of the HMAC (13 hex chars = 52 bits).
h = int(hmac_hex[0:13], 16)
r = h / 2**52
multiplier = floor((100 * (1 / (1 - r))) * 100) / 100 (or an equivalent expression used by the site)

Different providers apply small variations and caps. Use this as a starting point and cross-check against the on-site verifier.

Plinko / multi-branch games

Plinko-style games often slice the HMAC into chunks and map each chunk to a step or column using modulo arithmetic. Example approach:

Split the HMAC into N chunks of 2 or 4 bytes.
For each chunk compute int(chunk,16) % columns to pick the next column.
Aggregate the path to compute a payout.

Again, rules vary. If the site provides a verifier, use it to confirm the exact mapping.

Worked example: verify one past round (numbered how-to)

Open the round details on the platform and copy: published server-seed hash, revealed server seed (if released), your client seed, the nonce, and the round hash/output printed by the game.
Run a SHA-256 of the revealed server seed. If it equals the published hash, the commitment check passes.
Compute HMAC-SHA256 using revealed_server_seed as key and client_seed + separator + nonce as message. Try separators '-', ':', and '' if unknown.
Compare the HMAC hex to the game’s reported round hash. If they match, you reproduced the round entropy.
Apply the game-specific conversion formula (dice, crash, etc.) to the HMAC hex and confirm the numeric outcome equals the round result shown by the game.
If all checks pass, the round can be cryptographically traced to the revealed server seed and your client seed + nonce. Save your logs or screenshots for record-keeping.

Comparison: on-site verifier vs third-party verifier vs DIY scripts

Method	Trust model	Effort	Best for
On-site verifier	Relies on operator code (easy to use). Good for quick checks.	Low	Casual verification
Third-party verifier	Independent, open-source tools reduce operator trust. Needs care choosing a vetted tool.	Medium	Regular players who want independent checks
DIY script (Python/Node)	Full control. You see every step. Highest transparency.	Medium–High (one-time setup)	Power users, auditors

Limitations and what provably fair does not prove

Provably fair confirms that the game used the revealed server seed + your client seed + nonce to generate entropy. It does not prove the game’s RTP or house edge. RTP is a separate, published metric tied to game rules and odds.
Games with complex payout systems still rely on provider code to map entropy to payouts. The mapping must be auditable to fully trust results.
If the server seed is rotated and you try to verify rounds that took place under a previous seed, use the correct revealed seed for that period—otherwise checks will fail.
Provably fair does not stop unfair business rules, API-level manipulation, or front-end bugs. It only covers the cryptographic link between seeds and entropy.

Best practices for players

Set and save your own client seed. Don’t rely on a default if you want full traceability.
Log the published server seed hash before you play. Take screenshots or copy the hash to a text file.
Rotate client seed regularly for privacy and variety. Remember that changing client seed requires a new HMAC pattern when verifying.
Use small verification tests after sessions to confirm your understanding of the conversion formula before trusting large wagers.
If you need support during verification, contact the platform’s 24/7 live chat or support bot for clarification. Keep your transaction reference if you report delays.

Third-party verifiers and open-source tools

Several community verifiers exist. When choosing one, prefer open-source projects with clear code. Check GitHub activity, issues and community reviews. Run the tool locally if possible so you don’t submit private seeds to a remote service.

FAQ

What is the difference between a client seed and a server seed?

The client seed is a value you own and provide; it is public and used to produce the HMAC input. The server seed is generated and kept secret by the operator until they reveal it. Together with the nonce they deterministically produce the round entropy.

How do I check if the revealed server seed matches the pre-round hash?

Compute SHA-256 of the revealed server seed (text or hex as provided). If the resulting hex equals the pre-published server-seed hash, the seed matches the commitment. Use standard SHA-256 tools or the short scripts above.

Why do I have to rotate my seed pair before verifying previous bets?

If the operator rotates the active server seed, new rounds will use the new seed. Rounds produced under the previous seed must be verified with that specific revealed seed. Rotating only affects which server seed applies; it does not retroactively change past rounds without breaking the SHA-256 commitment check.

Can a crypto casino change the server seed during a bet without detection?

No. If the casino changes the server seed after publishing its SHA-256 commitment, the revealed seed would not hash back to the published commitment. That mismatch is detectable with a simple SHA-256 check.

How is HMAC-SHA256 used to convert seed pairs into game outcomes?

The server seed (as HMAC key) and client seed+nonce (as message) are fed into HMAC-SHA256 to produce a 256-bit hash. The platform then slices bytes from that hash and maps those bytes to numeric outcomes using a game-specific conversion (divide by 2^32 for dice, use 52 bits for crash, modulo for plinko, etc.). The HMAC ensures the operator cannot predict or alter the output after the server-seed commitment.

Does provably fair verification guarantee that the casino has a fair RTP?

No. Provably fair demonstrates that the randomness for a round derived from a specific seed pair. RTP and house edge depend on payout tables and rules, which are separate. If you want to understand long-term expected return, consult game RTP information from the provider and independent math resources such as Wizard of Odds.

Where to go next: tools and MST88 pages

If you want a place to test verification workflows, you can create a free account and use the platform verifier. Check the promotions page for current offers such as the sign-up 20 Free Spins and the deposit offer up to 388% + 200 Free Spins before depositing; full terms are on the promotions page.

For background on the platform and products, see the official portal guide and product pages: MST88 Global official guide, Slots, and the Promotions page. If you bet with crypto and want sportsbook context, our USDT betting site guide explains the role of on-chain currencies.

Final checklist before you trust a verified round

Commitment check passed: SHA-256(revealed_server_seed) equals published hash.
HMAC reproduced: HMAC-SHA256 with revealed_server_seed, your client_seed and correct nonce pattern matched the round hash.
Conversion matched: the game-specific mapping produced the same numeric result shown in the round.
Log saved: you kept the hashes, seeds, nonce and verification output for records.

Conclusion

Understanding how to verify client seed and server seed gives you a practical way to audit individual rounds. Use the two-step model: check the SHA-256 commitment, then recompute the HMAC and apply the correct conversion formula for the game. Prefer local or audited open-source tools for maximum transparency. Remember that provably fair covers randomness, not RTP or business rules.

Need help during verification? Contact on-site support or the Telegram bot for assistance and keep your round IDs. If you’re testing, start with small stakes and confirm formulas with a few rounds before scaling up.

Adults only. 18+ (or the legal gambling age where you live; Philippines 21+). Gambling is entertainment, not a way to make money. Set limits, never chase losses, and seek help from local support services or organisations such as Gambling Therapy if gambling causes harm.