StakeStats
10SC Free

Verify Any Provably Fair Dice Roll in 4 Steps for Players

Learn the exact math to reproduce a provably fair dice roll. Follow a four step verification checklist, see a 0–100 example, and try the Stakestats tools.

By Seal · 2026-10-04

Verify Any Provably Fair Dice Roll in 4 Steps for Players

Verify Any Provably Fair Dice Roll in 4 Steps for Players

Player checking a provably fair dice roll

Provably fair dice use a cryptographic commitment, a hashed server seed, plus your own client seed and a nonce, so you can verify after the fact that a roll was not altered. That verification depends on three variables: the server seed, the client seed, and the nonce. It confirms the integrity of the roll, not that the payout math or house edge favors you.

TL;DR:

  • Verifying a provably fair dice roll requires reproducing the exact HMAC-SHA256 calculation with the revealed seed, client seed, and nonce; mismatches should be documented.
  • Most platforms generate a public hash of the server seed before betting and reveal the unhashed seed afterward to prevent post-hoc manipulation.
  • The conversion process from hash output to a dice result involves slice selection, hexadecimal-to-decimal conversion, and modulo adjustment, which differ across sites.
  • The system confirms roll integrity only, not whether the house edge or payout structure favors the operator or player.
  • Using third-party tools simplifies session verification, seed integrity checks, and analysis of patterns against published RTP figures over multiple rounds.

Table of Contents

How provably fair dice work: seeds, nonce, and hashing

The system starts with a commitment. Before you bet, the site generates a server seed and shows you only its hash, the scrambled output that cannot be reversed to reveal the original value. Because the hash is published first, the operator cannot change the seed after seeing your bet and still produce the same hash. That one step is what separates provably fair dice from a closed-box random number generator.

Your client seed adds a second variable the operator cannot predict or control, and the nonce, a counter that increments with every bet, stops anyone from precomputing a sequence of favorable outcomes in advance. Combine all three and no single party, not the house, not the player, can quietly steer a result.

Three inputs flowing through a hash to a dice result

Most platforms generate the commitment using HMAC-SHA256, a keyed version of SHA-256. The National Institute of Standards and Technology lists SHA-2, the family that includes SHA-256, as the minimum secure hash standard for new applications, which is why it shows up across provably fair systems rather than older, weaker algorithms.

The output is a long hexadecimal string. Sites convert that string into a usable number by:

  • Taking a defined slice of the hex output or the full value
  • Converting that slice from hexadecimal to a decimal integer
  • Scaling or applying modulo arithmetic to fit the game's range, commonly 0 to 100 for dice

The math is fixed and repeatable. Anyone with the same three inputs and the same hashing method gets the same number every time.

Step-by-step verification: reproduce a dice roll and check integrity

Verifying a roll is mostly a matter of collecting the right values and running the same math the site ran.

  1. Collect the unhashed server seed, revealed after the round closes, along with your client seed, the nonce used for that specific bet, and the result the site displayed.
  2. Run HMAC-SHA256 using the server seed as the key and the client seed combined with the nonce as the message, or follow the exact method documented on the site's verification page, since some platforms vary the input order.
  3. Convert the resulting hex output to an integer and scale it to the game's range, typically 0 to 100 for dice.
  4. Compare your calculated number against the result the site displayed for that round.

A match confirms the roll was not altered after you placed your bet. A mismatch does not automatically mean foul play, since a copied value or wrong algorithm step causes most failures, but it is worth documenting.

Pro Tip: Screenshot the hashed seed before you play and the revealed seed afterward, with timestamps, so you have a complete record if a mismatch ever needs reporting.

Worked example: converting a hash to a 0–100 dice number

Say the HMAC-SHA256 process on a given server seed, client seed, and nonce returns a hex string. The conversion generally runs like this:

  • The algorithm outputs a full hex string of a length typical for HMAC-SHA256
  • The verifier takes a defined substring and converts it to a decimal integer according to the platform's documented method
  • That integer is divided or run through a modulo operation to compress it into the game's range
  • The final number maps to the displayed dice result within the game's defined numerical range

If the hex substring starts with leading zeros, the resulting integer is still read as a valid number, just a smaller one, so don't assume a short result means an error. Sites differ on which substring they use and how they scale it, so always check the platform's own documented method rather than assuming a universal formula.

Provably fair vs traditional RNG and relevant standards

Traditional random number generators sit inside a closed system. Independent labs audit the code and run statistical tests before certifying the generator, and players never see the raw mechanism, only the result. Provably fair flips that model: the commitment is public, and verification happens on the player's side, round by round, rather than through a one-time lab certification.

Independent labs typically run tests like chi-squared analysis to confirm a RNG's output distribution matches expected randomness at a defined confidence level, the same statistical logic that underlies both audited RNGs and provably fair verification.

  • NIST sets SHA-2, including SHA-256, as the baseline secure hash for new cryptographic applications, which grounds the hashing choice behind most provably fair commitments.
  • GLI-19 standards call for independent test labs to review randomness algorithms and apply statistical testing to confirm the intended distribution at high confidence.
  • Nevada's gaming regulator requires RNGs to avoid static seeds, maintain sufficient cycling, use separate generators per game, and log results for chi-squared testing and auditability.

Both models aim at the same goal, a result nobody can secretly rig, but provably fair lets you check the math yourself instead of trusting a certificate you never see.

Limitations and common misconceptions: what provably fair does not prove

Verifying a hash confirms the roll itself was not changed after you bet. It says nothing about whether the payout table, the house edge, or the advertised return to player actually favor you. Those numbers live entirely on the operator's side of the system.

Several things provably fair checks never touch:

  • The size of the house edge built into the payout structure
  • Bonus wagering math, which can quietly shift effective RTP
  • How the operator maps verified numbers to specific payout tiers

Cross-check a game's published RTP and payout table against your own session data rather than assuming a clean hash means a clean deal. Watch for red flags: no pre-commitment hash shown before betting, a nonce that skips or resets unexpectedly, or a site that never documents its hex-to-number conversion method.

Pro Tip: Treat provably fair verification and RTP verification as two separate checks. Passing one tells you nothing about the other.

Practical tools and verification checklist

A workable routine looks like this: confirm the hashed seed appears before you bet, reveal and record the seed after the round, verify a sample of rolls rather than every single one, and track your session results against the published RTP over time.

Stakestats builds tools around exactly that workflow. The Provably fair explanation tool walks through seed verification for Stake Engine games, the Stake Originals Analyzer breaks down session history and game mechanics, and a bankroll analyzer helps track variance across a session.

  • Seed and nonce verification confirm roll integrity on a given bet
  • Session calculators and analyzers surface patterns across many rounds
  • Max win and bet replay lookups let players review past results
Measures provided by third-party tools Operator responsibilities
Seed and hash verification Pre-commitment hash before each bet
Session RTP and hit rate tracking Published RTP and payout tables
Max win and bet replay lookup Documented hex-to-number conversion method

Use any third-party analytics tool with the same seed and account data you would give a site's own verifier, nothing more, and avoid pasting credentials anywhere outside the platform you are actually playing on.

Author perspective: practical stance on provably fair dice

Provably fair is a real improvement over trusting a black box, but it answers a narrower question than most players assume. I'd rather see a reader verify a handful of rolls per session and spend the rest of their attention on RTP and payout tables, where the actual edge lives. Operators that publish their conversion method alongside the hash make that whole habit much easier to build.

— Ian

Stakestats: use our provably fair verification tools and session analyzers

Checking a hash by hand works for one roll. It gets tedious fast across a real session. This is the gap Stakestats is built to close. The platform pulls seed verification, real-time RTP, and session stats together for Stake Engine games, so you're not reconstructing hex math every time you want to know whether a session behaved the way the published numbers say it should.

Stakestats

  • The Stake Originals Analyzer reads session and game mechanics data so you can compare actual play against expected patterns.
  • The provably fair explanation tool reproduces the seed verification steps without a manual hash calculator.
  • A bankroll analyzer tracks variance and volatility alongside your verified results.

Stakestats measures seed integrity, session statistics, and historical results. RTP figures, payout tables, and bonus terms still come from the operator, and we point you to published numbers rather than guessing at them. Start with the provably fair verification tools to check your next session against both the math and the published odds.

FAQ

What casino game is the least rigged?

No universal ranking exists, since "rigged" depends on house edge, payout structure, and whether the RNG or provably fair system is independently reviewed. Games with published RTP and a verifiable provably fair commitment give you the clearest way to confirm the result wasn't altered after your bet.

Are dice considered fair in provably fair systems?

Dice results are fair in the sense that the outcome can be mathematically verified against a pre-committed server seed, client seed, and nonce. That verification confirms the roll wasn't changed, but it says nothing about the house edge built into the payout table.

What does fair mean in probability?

In probability, a fair process means every outcome has its stated, unbiased chance of occurring, with no hidden skew toward one result. Provably fair systems target this by letting players recompute the hash and confirm the outcome matched a value fixed before the bet was placed.

Which casino game has the worst odds of winning?

Odds vary widely by specific game and payout structure, and no single game holds a fixed universal rank for worst odds. Checking a game's published RTP and payout table is a more reliable way to judge the odds than relying on general reputation.

How do I know if a provably fair hash has been tampered with?

Reproduce the HMAC-SHA256 calculation yourself using the revealed server seed, your client seed, and the nonce, then compare the scaled result to what the site displayed. A match confirms the seed wasn't altered after you placed your bet, while a mismatch is worth documenting with screenshots and timestamps.

Sources

For deeper reading on the cryptography and standards behind provably fair systems, see the sources below.