Paste Your Round Data Into the Checker
Start with the server seed commitment, then reproduce the completed game result with the same inputs the platform used for that round.
Saved before play; proves the casino committed to a hidden server seed.
Shown after seed rotation; hash it and compare it with the original commitment.
Player-side input combined with the server seed to generate the round result.
The round counter for the exact bet you want to verify.
Dice, Crash, Mines or another supported conversion method.
Use the Provably Fair Checker
Select the platform mode first. Different casinos can use the same cryptographic building blocks but encode seeds, messages and result conversions differently. A Dice formula for one platform may not match another platform even if both use HMAC-SHA256.
Provably Fair Checker
Check server seed commitments, generate HMAC-SHA256 hashes, reproduce Dice rolls, estimate Crash points and rebuild Mines layouts where the selected algorithm mode matches the casino implementation.
This checker is designed for the cryptographic part of casino result verification. Use it to test server seed commitments, generate HMAC-SHA256 outputs, reproduce Dice rolls, check Crash points and reconstruct Mines layouts where the platform algorithm is supported.
The calculations should run locally in your browser. You should still avoid pasting active unrevealed server seeds, account passwords, wallet recovery phrases or sensitive login data into any online tool. Provably fair verification needs bet-level game inputs, not wallet or account credentials.
What This Checker Is For
The checker is useful when you have a completed round and want to test whether the result matches the casino’s disclosed fairness data. It is not a predictor, RTP calculator or casino-safety score. Treat it as a round-level verification tool.
| Use case | Can this checker help? | What it needs |
|---|---|---|
| Check whether a revealed server seed matches the pre-bet hash | Yes | Saved server seed hash and revealed server seed |
| Reproduce a completed Dice, Crash or Mines result | Yes, if the algorithm mode is supported | Server seed, client seed, nonce and game-specific settings |
| Predict the next casino result | No | Future server seeds are hidden in a proper provably fair system |
| Confirm whether a game has 100% RTP | No | RTP requires a separate payout-table or multiplier audit |
| Prove the casino is safe for withdrawals | No | Withdrawal safety is a platform-risk issue, not a seed-verification issue |
What You Need Before Checking a Round
| Input | What It Means | Where to Find It |
|---|---|---|
| Server seed hash | The pre-bet commitment published before the server seed is revealed. | Fairness panel, seed settings or bet history before seed rotation. |
| Revealed server seed | The secret seed disclosed after rotation or after the bet cycle ends. | Seed history, fairness page or completed bet details. |
| Client seed | A player-side seed, sometimes editable before play. | Fairness settings or bet details. |
| Nonce | The round counter used with the current seed pair. | Bet history or verification panel. |
| Game mode | The result conversion method: Dice, Crash, Mines or another game. | Choose the matching tool mode for the game you played. |
| Extra game input | Some games use extra values, such as mine count, Plinko rows, risk level or crash settings. | Platform verifier, bet details or game rules. |
The most common verification mistake is using the right seed values with the wrong algorithm mode. Always match the platform and game type before interpreting the result.
Fast Verification Workflow
Before playing, screenshot or copy the server seed hash shown by the casino.
Keep the game type, bet ID, client seed, nonce and visible game settings.
Rotate or reveal the server seed after the completed betting cycle.
Hash the revealed server seed and compare it with the saved pre-bet hash.
Use the matching game mode to reproduce the round output from seed data.
Step 1: Check the Server Seed Commitment
The commitment check is the first step. Before the bet, the casino should show a hash of the server seed. After the seed is revealed, you hash the revealed server seed and compare it with the original hash.
If the computed hash matches the pre-bet hash, the casino could not have changed that server seed after seeing your bet without breaking the commitment. If it does not match, the seed pair should be treated as invalid.
| Result | Meaning | What to Do |
|---|---|---|
| Hash matches | The revealed server seed matches the earlier commitment. | Continue to the game-specific result check. |
| Hash does not match | The revealed seed does not match the commitment you saved. | Recheck copy/paste first; if still different, preserve evidence. |
| No pre-bet hash saved | You cannot prove the seed was committed before the round. | Rotate seeds and save the next commitment before betting. |
Step 2: Generate the HMAC-SHA256 Output
After the server seed commitment is confirmed, the checker combines the revealed server seed with the client seed and nonce. Many crypto casino games use HMAC-SHA256 or a related HMAC construction. The raw HMAC digest is then converted into a game result.
| Part | Common role | Why mismatches happen |
|---|---|---|
| HMAC key | Usually the server seed | Some platforms treat the server seed as text; others decode it as hex bytes. |
| HMAC message | Usually client seed plus nonce | Message order, separators, cursor values and nonce indexing can differ. |
| Digest | The raw hexadecimal HMAC output | The digest may match while the final game conversion still differs. |
| Conversion formula | Maps the digest into a roll, multiplier, board or card order | Each game type has its own conversion and rounding rules. |
Step 3: Reproduce the Game Result
Once the cryptographic output is generated, the next step is game-specific. The checker converts the output into the same kind of result the casino displayed.
Dice Result
For Dice, the HMAC output is converted into a roll number. The reproduced roll should match the result shown in the bet history. If the roll matches, the result was generated consistently with the disclosed inputs.
Crash Point
For Crash, the checker converts the supported input format into a bust multiplier. Crash algorithms are more implementation-sensitive than Dice because platforms can use different edge mechanics, randomness sources and rounding rules. Use the platform-specific mode where available.
Mines Layout
For Mines, the checker reconstructs hidden mine positions from the seed data and mine count. The resulting board should match the completed round. This verifies board generation, not whether the cashout multiplier was priced fairly.
What This Tool Can Verify
- Server seed commitment: whether the revealed server seed matches the hash shown before play.
- Outcome reproduction: whether a completed result can be reproduced from the published inputs.
- Game-specific conversion: whether Dice, Crash or Mines outputs match the selected algorithm mode.
- Copy/paste errors: whether a mismatch is caused by a wrong nonce, wrong seed, missing separator or wrong platform mode.
- Round integrity: whether the tested result is consistent with the disclosed randomness process.
What This Tool Cannot Prove
- It cannot prove RTP. A game can be provably fair and still have a 1%, 3% or larger house edge.
- It cannot prove withdrawal safety. Verification of a game round does not guarantee that the platform will process withdrawals smoothly.
- It cannot prove strong regulation. A cryptographic result check is not a substitute for licensing and dispute resolution.
- It cannot verify future rounds. It only checks completed rounds after the relevant seed data is available.
- It cannot validate every casino algorithm. The platform mode must match the casino’s actual implementation.
Server Seed Checker vs Provably Fair Checker
A server seed checker is only one part of the process. It confirms whether the revealed server seed produces the hash that was shown before the bet. A full provably fair checker goes further: it uses the seed pair and nonce to reproduce the actual game output.
| Check | Purpose | Typical output |
|---|---|---|
| Server seed hash check | Tests the commitment | Match or mismatch |
| HMAC-SHA256 check | Generates the raw deterministic output | Hexadecimal digest |
| Game-result check | Maps the digest to the displayed result | Dice roll, crash point, mine layout or another result |
| RTP check | Audits payout fairness | Expected return, house edge or fair multiplier |
Provably Fair vs RTP
Provably fair and RTP are separate checks. This is the most important concept on the page.
| Question | Provably Fair Check | RTP / Paytable Check |
|---|---|---|
| Was the result changed after the bet? | Yes, this is what PF is designed to test. | No. |
| Does the server seed match its prior hash? | Yes. | No. |
| Was the payout table fair? | No. | Yes, if the multiplier table or formula is audited. |
| Does the game have a house edge? | No. | Yes, if the return model is known. |
| Will the casino pay withdrawals? | No. | No. |
Example: a 99% RTP Dice game can be perfectly provably fair. The roll can be honest, while the multiplier still includes a 1% operator edge. To check both parts, verify the roll and compare the displayed multiplier with the fair formula.
Platform Algorithm Differences
Do not assume that every casino uses the same seed encoding or result conversion. Small implementation differences can produce completely different outputs from the same visible inputs.
| Area | Why It Matters | Common Failure Mode |
|---|---|---|
| Server seed encoding | Some algorithms treat the seed as text; others decode it as hex bytes. | The HMAC output does not match even when the seed looks correct. |
| Message format | Client seed, nonce and cursor may be joined in different orders. | A missing colon, wrong order or wrong cursor changes the result. |
| Dice conversion | Platforms can use modulo, floating-point chunks or rejection sampling. | The roll is close but not identical to the displayed result. |
| Crash formula | Crash games differ in instant-bust handling, edge factor and rounding. | The reproduced multiplier differs by one rounding step or by the house-edge factor. |
| Mines shuffle | Different Fisher-Yates implementations and byte cursors can produce different boards. | The same seed data generates a different mine layout. |
How to Interpret Mismatches
A mismatch does not always prove manipulation. Most failed checks come from input or mode errors. Work through the basics before drawing conclusions.
- Check whitespace: remove accidental spaces before or after seeds.
- Check the nonce: one wrong round number produces a different result.
- Check platform mode: Duel, Stake and generic algorithms may encode the same fields differently.
- Check seed state: unrevealed server seeds cannot be verified yet.
- Check game mode: Dice, Crash and Mines use different conversion logic.
- Check rounding: the casino may display fewer decimals than the raw calculation.
If the inputs are correct, the algorithm mode is correct and the result still does not match, save screenshots of the bet details, seeds, verifier output and casino result before contacting support.
When to Use Each Mode
| Mode | Use It For | Main Output |
|---|---|---|
| Server Seed Commitment | Checking whether the revealed server seed matches the pre-bet hash. | Computed SHA-256 hash and match/mismatch status. |
| HMAC-SHA256 Generator | Inspecting the raw HMAC output before game conversion. | Hexadecimal HMAC digest. |
| Dice Result | Reproducing a Dice roll from seed data and nonce. | Roll number or result value. |
| Crash Point | Reproducing a Crash bust point where the selected platform mode is supported. | Crash multiplier. |
| Mines Layout | Reconstructing hidden mine positions for a completed Mines round. | Mine positions or board layout. |
Related Guides and Game Audits
Use the full provably fair verification guide if you want the step-by-step explanation behind server seed hash, client seed and nonce checks. For payout math, use the Mines calculator or compare the game’s multiplier table separately. If a third-party tool claims it can predict future rounds, read the warning guide on provably fair predictor scams.
- Duel Dice audit — multiplier formula and roll verification
- Duel Crash audit — crash-point math and auto-cashout model
- Duel Mines audit — board reconstruction and multiplier formula
- Duel Plinko audit — binomial lane probabilities
- Duel Keno audit — hypergeometric draw probabilities
Frequently Asked Questions
What is a provably fair checker?
It is a tool that uses a casino’s disclosed seed data and algorithm to reproduce a completed game result. If the reproduced result matches the bet history, the round is consistent with the published fairness method.
Can this checker prove a casino is legitimate?
No. It can help verify individual outcomes. Legitimacy also depends on licensing, withdrawals, support, terms, responsible gambling controls and account-risk practices.
Can I verify a bet before the server seed is revealed?
You can save the server seed hash before play, but you cannot fully verify the round until the actual server seed is revealed. The pre-bet hash is only the commitment.
Why does my result not match?
The most common reasons are wrong nonce, wrong client seed, extra whitespace, wrong platform mode, unrevealed seed, or a game-specific conversion difference. Recheck inputs before assuming a fairness problem.
Does provably fair mean 100% RTP?
No. A game can be provably fair and still have a house edge. To check RTP, you need the payout formula, multiplier table or return model in addition to the seed verification.
Is it safe to paste my server seed?
Only paste revealed server seeds from completed bet cycles. Never paste wallet seed phrases, private keys, passwords, two-factor codes or unrevealed active server seeds.
What should I save before playing?
Save the server seed hash, client seed, nonce or bet ID, game type and any visible fairness settings. Without the pre-bet hash, you cannot prove that the later revealed seed was committed before the round.
Bottom Line
This provably fair checker is useful for one specific job: testing whether completed casino outcomes match the published seed-based algorithm. It is strongest when you have the full input set, the correct platform mode and a completed round with revealed seed data.
The correct interpretation is narrow but important. A matching result supports outcome integrity. It does not prove RTP, withdrawal safety or regulatory quality. For a full audit, combine provably fair verification with payout-table math, platform-risk review and small withdrawal tests before trusting meaningful balances.
