How to Verify a Provably Fair Bet Step by Step

A provably fair bet is verified only when you can reproduce the path from the original commitment to the displayed result. A matching server-seed hash is one checkpoint. You still need the correct client seed, nonce, cryptographic calculation, game mapping and payout rules.

Before you start: use the rules for the exact game

Provably fair systems are not one universal protocol. Operators can use different input orders, separators, byte conversions, cursor rules and result formulas.

This guide uses Shuffle’s published implementation for a worked Dice example. The values are synthetic. They did not come from a real bet. Do not use the formula for another game unless its documentation matches every stage.

You need the historical rules that applied when the bet was settled. A current verifier may have changed since an old wager. Save the game name, version and documentation when possible.

Our broader guide explains how provably fair gambling works. This page focuses on performing and diagnosing one verification.

Step 1: Save the pre-bet evidence

Start before rotating or revealing the server seed. Record the commitment hash shown for the active server seed. Save the client seed, nonce, game name and bet or round ID. Also record the selected settings, displayed result and payout.

A screenshot is useful, but copy the values as text too. Screenshots can hide characters or truncate hashes. Text is easier to compare and enter into a local script.

The commitment hash matters because it existed before the reveal. If you record only the server seed afterwards, you cannot independently show that the operator committed to it earlier.

Keep the evidence together. A commitment from one seed pair and a nonce from another will produce a clean-looking but incorrect calculation.

Click to zoom

Step 2: Rotate and reveal the server seed

A secret server seed cannot remain secret and be verified at the same time. The operator normally reveals an old seed after you rotate to a new pair.

Shuffle’s verification instructions tell players to finish existing games, rotate the pair and choose the next client seed. The completed bet then shows its old server seed. The client seed and nonce used for that bet remain unchanged.

This is an operator-specific interface flow. Another site may call the action “change seed,” “reveal” or “verify fairness.” Some systems reveal data after every round. Others reveal a sequence only after a seed rotation.

Check that the revealed seed belongs to the bet you recorded. Do not accidentally copy the new server-seed commitment or the next client seed.

Never paste an active, unrevealed server seed into an unknown website. A server seed should normally be public only after its betting sequence has ended.

Step 3: Compare the seed with the commitment

The operator should disclose the hash function used for the commitment. SHA-256 is common. NIST FIPS 180-4 defines secure hash algorithms that create message digests. A changed input produces a different digest.

Our synthetic server seed is:

server-secret-2026

Its SHA-256 digest is:

b1ead5aa8b682ccc470781bd070ee2b053351a3cf6b7120b2522ec76edf3faf7

You can reproduce it with OpenSSL:

printf '%s' 'server-secret-2026' | openssl dgst -sha256

Compare the returned digest with the commitment saved before the reveal. Every hexadecimal character must match.

Use the exact seed string. A trailing line break, extra space or changed letter case creates another digest. The printf command above omits a newline for that reason.

A successful comparison proves that the revealed seed matches the earlier commitment. It does not yet reproduce the Dice roll.

Step 4: Rebuild the HMAC message

The worked implementation uses HMAC-SHA256. NIST FIPS 198-1 describes HMAC as message authentication built from a cryptographic hash function and a secret key.

For this example, the server seed is the HMAC key. The message combines the client seed, nonce and current-round value with colons.

server seed:  server-secret-2026
client seed:  player-seed-42
nonce:        7
current round: 0
message:      player-seed-42:7:0

The HMAC-SHA256 output is:

253f46ddd5445499cab126048ad43faf3a153f5b353814e056584ef0682a9d68

You can reproduce it independently:

printf '%s' 'player-seed-42:7:0' \
  | openssl dgst -sha256 -hmac 'server-secret-2026'

The key and message are not interchangeable. Reversing them returns a different digest. Removing a colon or using the wrong nonce also changes the result.

The nonce identifies the wager within a seed pair. A cursor or current-round value can extend the output for games that need several random events. A mismatch at this stage often comes from using the next seed pair, an incorrect nonce or the wrong cursor.

Click to zoom

Step 5: Convert the digest into a number

A digest is a sequence of bytes. The game needs a number it can map into a roll, tile, path or multiplier.

Shuffle’s documented conversion groups the HMAC output into sets of four bytes. The first four bytes from our digest are:

[37, 63, 70, 221]

They become a number from zero up to, but not including, one:

37/256 + 63/256² + 70/256³ + 221/256⁴
= 0.145496777492

This is the first generated float. If the game needs more values, it continues through the digest and may increment a cursor when the available bytes run out.

Do not assume every operator takes the first four bytes this way. Some systems use a larger integer, extract a fixed number of bits or reject values outside a range. Byte order also matters.

Step 6: Apply the game-event mapping

Shuffle’s Dice formula maps the float into a two-decimal result from 0.00 through 100.00:

floor(float × 10,001) / 100

Using our float:

floor(0.145496777492 × 10,001) / 100
= 14.55

The reproduced Dice result is therefore 14.55.

This is where a generic hash checker stops being useful. The event formula determines what the random number means to the player.

Dice maps a number into a roll. Mines maps several numbers into unique tile positions. Plinko maps a sequence into left and right steps. Limbo and crash-style games map a value through a multiplier curve. Our comparison of provably fair instant games explains those differences.

Use the mapping for the exact product and version. A correct HMAC paired with the wrong formula can return a convincing but irrelevant result.

Step 7: Check the win rule and payout

Reproducing 14.55 establishes the game event. It does not automatically establish whether the bet was settled correctly.

For Dice, record whether the bet was over or under. Check the selected threshold and how equality is handled. Then check the payout multiplier, stake and rounding rule.

Other games require different evidence. Mines needs the selected mine count, opened positions and cash-out point. Plinko needs its row and risk settings. Crash needs the crash point and cash-out evidence. A verified crash point may not prove when a manual request reached the server.

Treat event generation and settlement as separate checks. If the event matches but the payout does not, the problem is in the bet rule or settlement layer.

Diagnose a mismatch in order

Do not change several inputs until something matches. Test the process in stages. The first failed stage narrows the cause.

Commitment mismatch

Start with the commitment. If SHA-256 of the revealed server seed does not match the saved hash, stop. Confirm that both values belong to the same seed pair.

HMAC mismatch

Next, compare the HMAC. If it differs, check the server seed, client seed, nonce, cursor, separators and input order. Confirm the text encoding and remove unintended spaces or line breaks.

Mapping mismatch

If the HMAC matches but the displayed event does not, inspect the byte conversion and game mapping. Check byte order, rejection rules, precision and formula version.

Payout mismatch

If the event matches but the settlement does not, inspect the selected settings, win boundary, payout table and rounding.

Click to zoom

Save both the expected and observed values. Include the round ID and documentation when reporting a mismatch. “The verifier failed” is weak evidence. “The saved commitment matches, but the published byte mapping returns 14.55 while the bet history shows 14.62” identifies the failed layer.

Common mistakes that create false mismatches

The most common error is using the wrong nonce. Check whether numbering begins at zero and whether the displayed nonce belongs to the completed bet.

Another common error is copying values from the newly activated seed pair. The old server seed belongs with the old client seed and historical nonce.

Exact formatting also matters. A message such as player-seed-42:7:0 is not equivalent to player-seed-42-7-0. Uppercase characters, spaces and line endings can also change the digest.

Some games consume several numbers. Starting at the wrong cursor shifts every later event. A Plinko path can then diverge even if the seeds and nonce are correct.

Finally, verify the historical formula. Operators can update games. A current verifier needs version handling if older bets used different rules.

Use an independent verifier safely

An operator’s verification button is convenient. It can also repeat the same implementation error as the game if both use shared code.

Independent verification is stronger when the source is public and the calculation can run locally. Review the code or use a small script that performs only the disclosed steps. Compare its output with the operator’s tool.

Do not enter active secrets or account credentials into third-party calculators. Revealed historical seeds, client seeds and nonces are generally the relevant verification inputs. Check what a tool transmits before using it.

A verifier also needs readable documentation. A green “verified” badge does not show which inputs, encoding, formula or payout rules were checked.

What a successful verification proves

A complete match shows that the supplied inputs reproduce the recorded result under the published rules. It is useful evidence that the operator did not change the committed server seed after the bet.

Its scope is limited. It does not prove that withdrawals will be processed, the operator is solvent or the displayed licence is valid. It does not resolve every account dispute. It may not prove when a time-sensitive network request reached the server.

Verification also does not remove the house edge. A transparent formula can still return less than 100% to players. Fair result generation and favourable odds are separate questions.

For crash games, see our fairness comparison. It separates crash-point proof from cash-out timing and wider operator controls.

Verification does not make repeated betting safer

A correct result can still be a losing result. Checking it does not change the expected return or make a staking system profitable.

Instant games can process many wagers quickly. Track total money wagered, not only the deposit. Set time and spending limits before play. Stop rather than increasing stakes to recover losses.

The crash-game session plan applies these limits to stake size, cash-out targets and stop rules.

Use account limits, cool-offs or self-exclusion when needed. Our responsible gambling guide lists practical controls and support.

The useful question is not whether a page says “provably fair.” It is whether you can save the evidence, reproduce every stage and identify exactly where a mismatch occurs.