Provably fair verifier

Not sure which to choose? See what we recommend for each type of player.

What is provably fair?

Provably fair is a cryptographic verification system used by crypto casinos to prove that game outcomes are genuinely random and have not been manipulated. Unlike traditional online casinos where you must trust the operator, provably fair systems let you mathematically verify every single bet you place. If you are new to the concept, our guide on how provably fair gambling works breaks down the math step by step.

The system relies on three key components: a server seed generated by the casino, a client seed that you can set yourself, and a nonce that increments with each bet. These three values are combined with a keyed hash to produce a deterministic result: HMAC-SHA256 at Stake, Shuffle and BC.Game, and other functions at some operators (see why a result does not reproduce). Because the server seed is committed (hashed) before the round begins, the casino cannot change it after seeing your bet. And because you control the client seed, the casino cannot predict the final outcome.

This approach shifts the trust model from blind faith to mathematical proof. After each round, you can take the revealed server seed, combine it with your client seed and nonce, and independently verify that the game result matches what the casino displayed. If the results match, the game was provably fair. If they do not, you have cryptographic evidence of manipulation.

How does provably fair verification work?

The verification process follows a straightforward cryptographic protocol that any player can independently execute:

1. Before the round: The casino generates a random server seed and shows you its SHA-256 hash (the "hashed server seed"). This commits the casino to a specific seed without revealing it. You can also set your own client seed at any time.
2. During the round: The casino combines the server seed, your client seed, and the current nonce using HMAC-SHA256 (the function Stake, Shuffle and BC.Game document) to produce a hash. This hash is then converted into a game result using a game-specific algorithm (crash multiplier, dice roll, mine positions, etc.).
3. After the round: The nonce increments by one. When you rotate your server seed, the previous unhashed server seed is revealed. You can now verify every bet made with that seed pair.
4. Verification: Take the unhashed server seed, your client seed, and the nonce for any specific bet. Run them through the same HMAC-SHA256 function and game algorithm. If your calculated result matches the casino's displayed result, the outcome was fair.

The HMAC-SHA256 function is a one-way cryptographic hash. Given the same inputs, it always produces the same output. But it is computationally impossible to reverse-engineer the inputs from the output or to find different inputs that produce the same hash. This mathematical property is what makes the system tamper-proof.

What the commitment check proves, and what it does not

The first line of every result on this page is the commitment check, so it pays to be exact about its reach. A SHA-256 hash works as a fingerprint of the server seed. Shuffle's help centre names the two properties that matter: it is "computationally impossible for a user to find the original unhashed server seed from the hash", and it is "computationally impossible to find two same unhashed input that give the same hashed output". The first stops a player from working out results early. The second stops an operator from keeping two seeds in reserve and revealing whichever one suits it.

What a MATCH proves. The seed revealed to you after rotation is the seed the operator fixed before your first bet on that seed pair. It was not picked after seeing your stakes, your client seed or your results.

What a MATCH does not prove, taken alone:

• That the displayed result came from that seed. A seed can be genuine while the roll shown to you is not the one it produces. Closing that gap is the second step, recomputing the outcome, and it is only possible where the operator publishes the formula. For Stake, Shuffle and BC.Game this tool does it; elsewhere the operator's own verifier has to.
• That the hash reached you in time. The check compares two strings and cannot know when you were given the first one. Duel's fairness articles list the warning signs in plain terms: "if your hashed server seed wasn't shown before playing" and "if your hashed server seed was shown to you only after committing to a client seed". Copy the hash before you bet, not out of the bet history afterwards.
• That the client seed did its job. If you keep the default client seed you are relying on it having been generated in your browser as described. Stake's implementation page says so itself: "we highly recommend that you choose your own, so that your influence is included in the randomness."
• Anything about the odds. Shuffle puts it in one sentence: "Provably fair verifies the integrity of game results, rather than how much a game pays back over time." The 0.99 in Stake's Limbo formula is part of what you verify; the tool confirms the house edge was applied as published, not that there is none.
• Anything about games outside the scheme. Stake's help-centre article is titled "Provable Fairness for Stake Original Games", and the title is the scope. Slots and live tables from outside studios are not generated from the operator's seed pair, and where a studio runs a scheme of its own it is the studio's to document. Rainbet's help centre says of its suppliers: "Rainbet has no control over these third-party systems".
• Anything about getting paid. A fair round and a completed withdrawal are separate questions. The second belongs to the operator's terms, which our reviews cover.

Crash-style games commit in a different way, because every player in the round shares one result and there is no personal server seed. The operator generates a long list of game hashes in advance and plays it backwards. In Shuffle's words: "The seed for each game is the result of hashing the seed of the subsequent game." The commitment is therefore the chain itself: hashing the game hash of the round you played must give the game hash of the round before it. In crash mode the tool prints that link as its first line, and you compare it with the previous round in the casino's history.

Sources: Shuffle help centre, commitment schemes (6 May 2024), overview and game events; Duel help centre, Dice PF (16 February 2026); Stake implementation page (read 1 November 2026) and help-centre article Provable Fairness for Stake Original Games; Rainbet help centre, Provably Fair (27 May 2026). Help-centre articles checked 11 November 2026.

How seed rotation reveals the server seed

The unhashed server seed is the one input you cannot be given while it is in use, because anyone holding it could compute every coming result. Operators therefore release it only when it is retired. Stake's implementation page states the rule: "To reveal the server seed from its hashed version, the seed must be rotated by the player, which triggers the replacement with a newly generated one."

Shuffle's help centre shows the same mechanism as a sequence. It begins "Step 1: Open the bet modal and click on rotate pair", continues with entering the next client seed, and ends with the bet you wanted to check, where "the server seed has been unhashed and revealed to you". It attaches a practical warning: "Remember to complete any existing games before changing." Rainbet's help centre sets the same condition: "seeds cannot be rotated while a game is active".

Four things follow for anyone filling in the form above:

1. Rotation is the moment of proof. Until you rotate, the Server Seed field cannot be filled in. The hashed seed alone verifies nothing; it only becomes evidence once the seed behind it is revealed and hashes to the same value.
2. One rotation opens every bet on the pair. All bets made on that server seed and client seed become checkable at once, each under its own nonce. Rainbet's overview describes rotation as revealing the "unhashed server seed on all past bets".
3. The nonce restarts with the new pair. Shuffle: "Nonce is originally set to 0 because no game is played. It will increase with every gameplay." Rainbet's overview also counts "starting at 0", Thrill's commitment article gives "starting at 1 for rotated seeds", and Roobet's fairness page lists "Your Nonce gets reset" among the effects of revealing a seed. The nonce you type must be the one shown on the bet itself, not a count of the bets you remember placing.
4. The old pair stays fixed. Shuffle notes that after rotation "The Client Seed and Nonce for the bet does not change." Look the three values up on the bet, since your account's active client seed is by then the new one.

A workable routine: copy the hashed server seed before a session, set your own client seed, play, rotate when you stop, then paste the revealed seed and the saved hash into the tool. If the first line reads MATCH and a few recomputed bets agree with your history, that session's seed pair is accounted for.

Sources: Stake implementation page (read 1 November 2026); Shuffle help centre, how to verify bets and commitment schemes; Rainbet help-centre article and provably fair overview (overview read 1 November 2026); Thrill help centre, commitment schemes; Roobet fairness page (read 10 November 2026). Help-centre articles checked 11 November 2026.

Supported casinos & games

The tool only reproduces a game when the operator publishes a specification or open-source verifier that the code matches (sources in the table, as of 22 Oct 2026 unless a row says otherwise). Everything else gets the one check that works wherever the operator commits with SHA-256: SHA-256(revealed server seed) must equal the hashed seed the casino showed you before your bets. Two documented exceptions are Cloudbet, which commits with SHA3-256, and Thrill, which shows a SHA-512 hash; for those the commitment has to be checked in the operator's own tool. See our list of the top crypto casinos ranked by deposit volume or the best provably fair casinos.

Why these three schemes, and what each one publishes

The casino menu has three full presets because three operators publish enough for outside code to follow byte for byte: a named hash function, the exact message that goes into it, the rule for turning bytes into numbers, and a conversion for each game. Each one publishes it in a different form.

Stake publishes a specification. Its implementation page (read 1 November 2026) opens: "For each verifiable bet, a client seed, a server seed, a nonce and a cursor are used as the input parameters for the random number generation function." The function is HMAC-SHA256 keyed with the server seed, and the message is the client seed, the nonce and a round counter joined by colons, clientSeed:nonce:round. The page then fixes the byte rule: "We use 4 bytes of data to generate a single game result", which gives eight results per 32-byte hash, and the round counter rises by one each time a game needs more. That is why Mines (up to 24 results) and Keno (10) pull several hashes for a single bet while Dice and Limbo pull one. A second page, game events, gives the conversion for each game, and the tool's Stake preset follows those conversions line by line.

Shuffle publishes help-centre articles with worked examples. The commitment article defines the three inputs and says of the server seed that it "is generated by your system as a random 64-character hex string". The implementation article prints the byte generator in code, "using the cryptographic HMAC_SHA256 function" over the same colon-joined message as Stake, and walks one hash through to a dice roll of 64.05. The game-events article, which had sections for 18 games on 11 November 2026, prints results for a fixed test input (client seed abc, server seed def, nonce 1). Printed examples are what make a third-party tool testable: if this page returns Shuffle's own numbers for Shuffle's own inputs, the Shuffle preset is doing what Shuffle does. Two conversions differ from Stake's even though the byte stream is identical: Limbo uses a constant of 2²⁴ where Stake uses 10⁸, and Keno and Mines place their picks with a skip loop that the article prints in full. Selecting the right casino matters for that reason, even between two operators that share a hash function.

BC.Game publishes verifier pages, one per game. Classic Dice, Limbo and Mines each show the same two formula lines, sha256(server_seed) for the commitment and "hmac_sha256(client_seed:nonce, server_seed)" for the result. Plinko's page shows "hmac_sha512(client_seed:nonce, server_seed)" instead. Two things separate this from the Stake family: the message has no round counter, and Plinko needs a different hash function, so a Stake-preset calculation of a BC.Game bet returns a wrong but plausible-looking number. The Crash verifier describes a salted hash chain and records three salt changes: "We made the decision to update Crash using a salted hash", each tied to a bet number and a public announcement thread. The tool's BC.Game preset covers Classic Dice, Mines, Plinko and Crash; BC.Game Limbo is not implemented here, so use BC.Game's own Limbo page for it.

Sources: Stake implementation and game-events pages (read 1 November 2026); Shuffle help centre, commitment schemes, implementation (7 May 2024) and game events; BC.Game public verifier pages for Classic Dice, Limbo, Mines, Plinko and Crash. Shuffle and BC.Game pages checked 11 November 2026.

Per-casino seed checkers, pre-set with the right scheme and seed-finding steps: Stake Seed Checker · Shuffle Seed Checker · Roobet Seed Checker (commitment check only).

Accuracy: the code on this page reproduces every worked example in Shuffle’s help article (dice 43.05, limbo 2.29x, roulette 15, the keno draw and the crash chain link for clientSeed “abc”, serverSeed “def”, nonce 1); matches Stake’s published byte generator on 500 random seed sets; matches Stake’s limbo formula on 200,000 rounds (never below 1.00x); and matches BC.Game’s open-source verifier code on 300 random seeds per game. Stake has published no worked crash example, so Stake crash follows the code in its seeding post only. Slots and live-dealer tables use studio RNG or live video and are not verifiable this way.

Why a result does not reproduce

A mismatch on this page is far more often a scheme difference or an input slip than evidence of a rigged round. Work through the ordinary causes first, then the operator-specific ones.

Input slips to rule out

• The seed is still active. Only a revealed server seed can be checked. If the casino still shows the seed as a hash, rotate first.
• The nonce is off by one. Operators do not agree on where the count starts (0 at Shuffle and Rainbet, 1 after a rotation at Thrill), so read the nonce from the bet, not from memory.
• The game settings differ. Mines depends on the mine count and Plinko on the number of rows; a correct seed with the wrong setting gives a different board or path.
• The wrong preset is selected. Stake and Shuffle share a byte stream but convert Limbo, Keno and Mines differently, and BC.Game uses a different message format altogether.
• An older BC.Game Crash round. BC.Game's Crash page lists salt changes after bets #2561902, #5282960 and #9614371. The tool pre-fills the current salt, so an earlier round needs the salt from the matching announcement.
• Stray characters. A space or line break copied with a seed changes the hash completely. The tool trims the ends of each field, but not characters in the middle.

Operator schemes this tool does not follow

The operators below document their fairness systems, some in detail, but in forms that differ from the three presets. The table gives what each one's own documentation specifies and what that means if you paste its values into this page.

The pattern across the table is that the words provably fair do not fix a hash function, a message format or a number conversion. Most of the operators above would fail a naive Stake-style recomputation while running a scheme that is, by its own documentation, verifiable. A mismatch from a general-purpose tool is therefore a reason to open the operator's own verifier, and only a mismatch there, on a seed whose commitment you saved in advance, is evidence worth raising with the operator or its licensing body. For a casino-by-casino comparison of these schemes, including licences, see provably fair casinos.

Sources: Roobet fairness page (read 10 November 2026); Duel help centre, Dice PF, Mines PF and Crash PF (16 February 2026); gamdom.com/help/fair; Cloudbet provably fair page; Thrill help centre, introduction and commitment schemes; Rainbet provably fair overview (read 1 November 2026) and help-centre article; BC.Game Crash verifier; bitsler.com. Checked 11 November 2026 unless a date is given. Explanations on this page last updated 11 November 2026.

Verify a specific game

Prefer a page pre-set to one game, with that game’s exact formula and a worked, reproducible example? Use a dedicated verifier:

• Crash Provably Fair Verifier — recompute any crash multiplier from your seeds.
• Dice Provably Fair Verifier — check any 0.00–100.00 dice roll.
• Limbo Provably Fair Verifier — recompute any limbo multiplier.
• Mines Provably Fair Verifier — reveal the exact mine layout.
• Plinko Provably Fair Verifier — trace the full left/right path.
• Keno Provably Fair Verifier — recompute all 10 drawn numbers.
• Roulette Provably Fair Verifier — check the winning pocket (European 0–36).

How this verifier works & why you can trust it

This is a static page. There is no account, no upload, and no back end. Everything below happens in your own browser, and you can confirm all of it by opening your browser’s developer tools or simply reading the page source.

• It runs the same open-source algorithm the casinos publish. The hashing is your browser’s built-in Web Crypto crypto.subtle HMAC-SHA256 — the same primitive the casinos document (HMAC-SHA256, or HMAC-SHA512 for BC.Game Plinko), plus SHA-256 for the seed commitment. The per-game conversions follow each operator’s own published spec or open-source verifier, listed in the table above, and match them.
• Nothing is sent to a server. Your server seed, client seed, and nonce never leave the page. No network request is made when you click Verify (check the Network tab) and we store nothing.
• It is deterministic, so you can cross-check it. The same inputs always produce the same output. Run the same seeds through your casino’s own verifier, or any other independent tool, and you should get an identical hash and result. If the revealed seed matches its hash and two independent tools agree on the result, the round was fair.
• We do not ask you to trust our numbers. Every result shows the commitment check, the full HMAC hash and a step-by-step breakdown of how the outcome was derived, so you can follow the maths yourself rather than taking it on faith.

What this tool does not do: it cannot predict future results (the server seed is only revealed after you rotate it), it cannot check a commitment made with a hash other than SHA-256, it does not test or rate a casino’s honesty for you, and it makes no claim about how many rounds have ever been checked. It is simply a transparent calculator for the published provably-fair maths.

Why should you verify your results?

Verification is the entire point of provably fair gambling. Without independent verification, provably fair is just a marketing buzzword. Here is why every player should verify at least some of their results:

Trust but verify. Even reputable casinos could theoretically be compromised by rogue employees, software bugs, or security breaches. Provably fair verification is your insurance policy. By checking results yourself, you confirm the system is working as intended.

Detect anomalies early. If a casino were to tamper with results, verification would catch it immediately. The HMAC-SHA256 hash would not match. While no major crypto casino has been caught cheating through provably fair manipulation, regular verification keeps the industry honest.

Understand the math. When you verify results, you gain a deeper understanding of how casino games work mathematically. You can see the house edge built into the algorithm (for example, the 0.99 factor that gives Stake’s Crash and Limbo their 1% edge) and make more informed decisions about your play.

Build confidence. Many players experience losing streaks and wonder if the games are rigged. Verification eliminates this doubt entirely. When you can prove mathematically that every result was fair, you can focus on strategy and bankroll management instead of worrying about manipulation.

Provably fair calculator

People search for this tool under several names — provably fair verifier, provably fair checker, fairness calculator, seed checker, or hash calculator. They all describe the same thing: a calculator that takes your server seed, client seed, and nonce and works out the game outcome they produce. The tool at the top of this page is exactly that.

To use it as a calculator, paste your revealed (unhashed) server seed, the hashed seed you were shown before betting, your client seed, and the nonce of the bet you want to check, pick the casino and game, and press Verify. It first checks that the seed matches its hash, then recomputes the HMAC and converts it into the outcome the casino should have shown — a dice roll, limbo multiplier, roulette pocket, mine layout, plinko path or keno draw. Crash rounds come from a hash chain instead of your seeds, so for crash you paste the round’s game hash. Because the calculation is deterministic, the number you get here should match your casino’s result and any other independent calculator exactly. If it does, the bet was fair; if it does not, double-check that you used the revealed server seed and the correct nonce, casino, mine count or row count.

Is there a provably fair predictor?

No — a provably fair predictor is not possible, and any tool claiming to be one is a scam. The entire point of the provably fair design is that outcomes cannot be known in advance. The casino commits to a server seed by publishing only its hash before you bet, and the unhashed server seed is revealed only after you rotate it. Without that unhashed seed, the HMAC-SHA256 output is computationally impossible to predict, so there is no way to know a crash point, dice roll, or mine layout ahead of time.

This verifier is strictly a post-bet checker: it confirms that a result which has already happened was generated honestly. It can never tell you what the next round will be. Be very wary of any "predictor", "hack", "signal", or paid bot that promises future results — at best it is guessing, and at worst it is designed to take your money. We explain the maths behind why prediction is impossible on our dedicated page: Is there a provably fair predictor?

How to find your seeds

Each casino stores your seed information in a slightly different location. Here is how to find your seeds on the most popular platforms:

1. Stake: Click your username in the top-right corner, go to Settings, then select the Fairness tab. You will see your active server seed hash, client seed, and total bets (nonce). Click "Rotate" to reveal the previous server seed for verification. You can also change your client seed at any time.
2. Roobet: Click your avatar in the top-right corner, then select Fairness from the dropdown. Your current hashed server seed, client seed, and nonce are displayed. To reveal the unhashed server seed, click "Change Seeds" which will rotate to a new seed pair and reveal the old one.
3. BC.Game: Navigate to your profile icon, then select Provably Fair. BC.Game shows your active and previous seed pairs with the nonce counter. Click "Rotate Seed Pair" to generate new seeds and reveal the previous server seed for verification. You can also view bet-level fairness data from your bet history.

Menu names change with site redesigns, so treat the paths above as a guide and look for the word the operator's own documentation uses. Stake's implementation page says the client seed is changed "via the fairness modal". Shuffle's help centre starts from the bet itself: "Open the bet modal and click on rotate pair". Rainbet's overview points to "the Fair Play tab at the top of any of our Originals games". On each of them the bet's own detail view is the reliable place to read the client seed and nonce that applied to that bet.

Remember: the server seed is only revealed after you rotate it. This is by design — if you could see the server seed before betting, you could calculate the outcome in advance. The hashed version shown during active play proves the casino committed to a specific seed without revealing it.