Before the Bet Goes Down, the Hash Is Already Locked InHow provably fair games use SHA-256 and HMAC to commit to a result before you play — the exact math behind it, what it actually proves, and a working tool below to check a past round yourself
“Provably fair” is a specific cryptographic technique, not a marketing adjective, though it gets used as both. This page walks through the actual construction most crypto casinos use — a server seed, a client seed, and a nonce combined with SHA-256 and HMAC-SHA256 — exactly how a published hash locks in a result before you bet, and how the digest that comes out the other end turns into a dice roll or similar outcome. It also covers, honestly, what that math does and does not guarantee, since the two get blurred a lot in casual explainers. A working verifier tool near the bottom lets you recompute a real result yourself, in your own browser, using nothing but the browser’s built-in crypto functions. Last reviewed September 2026.
Jump to: The commitment · The formula · Turning a hash into an outcome · What it actually proves · Where you’ll see it · Seed pairs & nonces · Verify it yourself · Glossary · FAQ
A sealed envelope, opened after you’ve already bet
Before you place a single bet against a given “seed pair,” the platform generates a secret value called the server seed and shows you something derived from it: SHA-256(server seed), usually labeled as the hashed or active server seed. The raw server seed itself stays hidden until you (or the platform) rotate to a new one. This is a hash commitment — a cryptographic way of locking in a value without revealing it, the digital equivalent of writing a number down, sealing it in an envelope, and handing you the sealed envelope before the bet, then opening it afterward so you can check what was inside matches what was sealed.
Two separate properties make this work, and they’re often blurred together in casual explanations even though they’re doing different jobs. Hiding means that, given only the published hash, there’s no practical way to work backward and recover the actual server seed — that’s what stops anyone from predicting results in advance. Binding means that once the hash is published, it’s computationally infeasible for the platform to later find a different server seed that produces that same hash, so it can’t quietly swap in a more favorable seed after seeing how you bet. Binding — not hiding — is the property that actually stops the casino from cheating after the fact, and it’s the one worth understanding if you only remember one thing from this section.
The exact math behind a single result
Once betting starts, each individual result comes from combining three inputs — the secret server seed, your client seed, and a nonce that counts up by one with every bet — through HMAC-SHA256, a keyed variant of the same hash function used for the commitment step above. In the construction used by Stake’s engine and copied by most similar “Originals”-style crypto casinos, it works like this:
The client seed, the nonce, and a cursor (which starts at 0 and only matters for games needing more than 32 bytes of randomness per bet) get joined into one string: clientSeed:nonce:cursor.
That message gets hashed using HMAC-SHA256, with the still-secret raw server seed as the key. The output is a 64-character hex digest — 32 bytes of effectively unpredictable data, but fully reproducible by anyone who later has all three inputs.
The first four bytes of that digest get converted into a float between 0 and 1, using each byte as a digit in base 256: byte0/256 + byte1/256² + byte2/256³ + byte3/256⁴. One 32-byte digest holds eight of these four-byte chunks, which is why some games only need to increment the cursor for results that require more than one chunk’s worth of randomness.
Why HMAC instead of just hashing a concatenated string, which is how older, simpler bitcoin-dice-era sites used to do it? Using the server seed as the HMAC key — rather than folding it into the hashed text — relies on HMAC’s proven behavior as a pseudorandom function: the output is computationally indistinguishable from random as long as the key stays secret, and a single-bit change anywhere in the inputs produces a completely uncorrelated result. That’s a stronger, better-studied guarantee than plain concatenation offers, which is why HMAC-SHA256 became the standard construction industry-wide. Some older or smaller platforms may still use the simpler plain-SHA256 approach, so the exact construction is worth confirming per platform rather than assumed.
The same float means something different in every game
The HMAC math above produces the same kind of output — a float between 0 and 1 — no matter what game you’re playing. What happens next is game-specific, isn’t standardized across the industry, and is honestly the part most explainers skip over:
The float multiplies by 10,001 and gets floored, then divided by 100 — floor(float × 10001) / 100 — giving 10,001 equally likely two-decimal outcomes from 0.00 up to essentially 100.00. This is the formula the verifier tool below implements.
Typically an inverse-distribution formula built from the raw integer behind the float, weighted by the game’s built-in house edge, which is what makes very high multipliers exponentially rarer rather than evenly distributed. The exact constant is platform-specific.
A Fisher–Yates shuffle driven by successive four-byte chunks decides tile positions — which is why a full grid can use up several cursor increments’ worth of digest in a single round.
Generally a similar shuffle-driven index into a deck or wheel, following the same seed-and-hash logic underneath a different final mapping.
One small, honest technical note for anyone checking the math closely: mapping a 32-bit integer onto a smaller range (like 25 tiles) with a modulo operation introduces a theoretical bias on the order of one part in a few hundred million — statistically negligible, but worth acknowledging rather than glossing over.
What this math proves, and what it quietly doesn’t
Given that the cryptography and process work as described, provably fair genuinely proves two things: that the server seed behind a specific past bet was fixed and committed to before that bet was placed, and that the numeric result is deterministically reproducible by anyone who has all three inputs afterward. That’s a real, meaningful guarantee about input integrity — not a small thing.
The commitment-and-reveal scheme only certifies that the inputs weren’t tampered with. It says nothing about whether the game’s actual production code — the part that turns a digest into a dice roll, a tile position, or a multiplier — is doing so honestly and matching the advertised return. Unless that mapping logic is itself open-sourced and independently audited, a player is still trusting the operator’s word that the documented formula is what’s genuinely running live. This is the single biggest gap between what “provably fair” sounds like it guarantees and what the cryptography actually covers.
It’s also a different kind of check than RNG lab certification, not a replacement for it. Independent testing labs — the kind covered in more detail elsewhere on this site — run production game software through millions of simulated rounds and statistically validate the output distribution and disclosed return figure empirically. Provably fair is a cryptographic argument about whether specific inputs were altered after the fact; lab certification is an empirical audit of how the game actually behaves in practice. They answer genuinely different questions, even though affiliate content often treats them as interchangeable trust signals.
A few other things worth being upfront about: the scheme says nothing about an operator’s broader conduct — bet limits, withdrawal friction, account restrictions, or how disputes get handled — none of which the hash chain touches. And if a server seed were ever predictable or leaked before a session closes, every result under that active seed pair becomes knowable to whoever has it, even though the published commitment math itself remains technically unbroken; that’s an operational key-management risk, not a weakness in SHA-256 or HMAC.
A crypto-native feature, not a licensing requirement
Provably fair remains almost entirely a feature of crypto-native, offshore-licensed platforms — it isn’t something MGA- or UKGC-regulated operators use as their fairness mechanism, since those regimes require RNG certification from an accredited independent lab as a licensing condition instead, and don’t treat a player-facing hash scheme as a substitute. It’s the platform’s own “Originals” games — dice, limbo, mines, plinko, keno, and similar in-house titles — that use this construction, since the casino itself controls that code. Slots from third-party studios almost never work this way: the crypto casino is only distributing them, not authoring their RNG, so there’s no seed pair for a player to inspect, and their fairness rests on the studio’s own lab-certified RNG the same way it would at a licensed operator.
Worth flagging directly: “Stake.com” and “Stake.us” are commonly confused but are different things with different legal footing — Stake.com is a Curaçao-licensed real-money platform for international players, while Stake.us operates a sweepstakes-style social casino model aimed at U.S. players, sitting in a different regulatory category with treatment that varies by state. If a specific platform’s name comes up, it’s worth checking which version — and what its current licensing situation actually is — since offshore operator status is the kind of detail that can shift.
Why the nonce matters as much as the seeds
A server seed and client seed on their own would produce the exact same digest every time — bet one and bet fifty would come out identical if nothing else changed. The nonce, incrementing by exactly one with every bet placed against a given seed pair, is what guarantees each bet gets its own unique, non-repeating result while keeping the whole sequence fully reproducible afterward. Editing your client seed, or hitting “randomize,” typically starts a fresh nonce count rather than continuing the old one.
When you choose to rotate to a new seed pair, the platform reveals the raw server seed it had been using, generates a new one, and publishes that new one’s hash before you bet against it again. Verifying the pair you just finished means hashing the now-revealed server seed yourself and confirming it matches the hash you were shown before you started betting — that check, not the individual bet recomputation, is really the core proof step, and it’s worth doing before diving into any single round’s result.
One practical note if you ever try this by hand or with a tool: the nonce that matters is the one recorded against the specific historical bet you’re checking, not whatever the platform’s current nonce counter happens to show. Mixing those two up is reportedly the single most common reason a manual verification appears to “fail” when nothing was actually wrong.
Recompute a real result, right in this browser
This tool runs entirely on your device using your browser’s own built-in cryptography (the Web Crypto API) — nothing you type here gets sent anywhere. It does two things: checks a revealed server seed against a previously published hash, and recomputes a dice-style result from a server seed, client seed, and nonce, exactly the way the math above describes.
Paste the revealed (raw) server seed and the hash that was published before you played. A match confirms the seed wasn’t swapped after the fact.
Uses the standard dice formula: HMAC-SHA256(server seed, “client seed:nonce:cursor”), converted to a 0–100.00 roll. Use the nonce recorded for the specific bet you’re checking, not your current nonce counter.
This confirms the specific inputs behind a past bet weren’t altered after you placed it. It doesn’t verify the game’s overall payout design, RTP, or that the hash-to-outcome formula matches what’s actually running in production — see “What this math proves, and what it quietly doesn’t” above.
Terms behind the hash chain
Questions about the hash behind the result
No. Provably fair is a cryptographic guarantee that specific bet inputs weren’t altered after the fact. Lab certification is an empirical, statistical audit of how a game’s production code actually behaves across millions of simulated rounds. They check different things and aren’t really substitutes for each other.
Essentially never. Slots come from third-party studios running closed-source RNGs the hosting casino doesn’t control, so there’s no seed pair to expose. Provably fair applies to a platform’s own in-house “Originals” games — dice, mines, limbo, and similar titles.
Not automatically — the most common cause is using the wrong nonce (often the current counter instead of the one recorded for that specific historical bet) or a copy-paste error in one of the seed values. Worth double-checking inputs carefully before concluding anything.
The cryptography itself is hard to defeat, but the guarantee is narrow. If the actual game logic converting a hash into a result isn’t independently audited or open-sourced, a player is still trusting the operator’s word that the documented formula matches what’s running live. Provably fair covers seed integrity, not that broader trust gap.
Using the server seed as the HMAC key rather than folding it into a hashed string relies on HMAC’s proven behavior as a pseudorandom function, giving stronger, better-studied unpredictability guarantees than plain concatenation. It’s why HMAC-SHA256 became the modern standard over older, simpler approaches.
No, and mixing them up is a common but meaningful error. Stake.com is a Curaçao-licensed real-money platform for international players; Stake.us runs a separate sweepstakes-style social casino model for U.S. players, with different legal treatment that varies by state.
No. All the hashing runs locally in your own browser using its built-in Web Crypto API — nothing typed into the tool is transmitted or stored.
A hash lets the platform prove, after the fact, that it didn’t change the seed once it knew how you’d bet — because finding a different seed that produces the same published hash is computationally infeasible. Simply “hiding” a value without publishing a hash of it first wouldn’t offer that same after-the-fact check.
The specific construction described here (HMAC-SHA256 with the server seed as key) reflects the most common modern implementation, popularized industry-wide from around 2020 onward — some platforms, particularly older or smaller ones, may use a different or simpler variant. Always check a specific platform’s own published provably-fair documentation for its exact formula before relying on any calculation here for a real dispute.