In crypto gambling, “provably fair” means the player can independently check whether the revealed round data matches the cryptographic commitment or hash shown by the casino. It is not a promise that the game is profitable, and it does not remove the house edge.
This Provably Fair Hash Verifier helps you recompute common seed and hash checks used by crypto casino games. It supports HMAC-SHA256, HMAC-SHA512, SHA-256, and SHA-512 modes, plus optional comparison against an expected hash from the game’s fairness panel.
Important: a matching hash proves that your entered inputs reproduce the expected hash. It does not automatically prove the final dice roll, crash point, card draw, or mine layout unless the game-specific result conversion is also verified.
Provably Fair Hash Verifier
Check SHA-256, SHA-512, HMAC-SHA256 and HMAC-SHA512 hashes from revealed game data.
-- -- How to Use the Verifier
- Open the game’s fairness panel. Look for server seed, client seed, nonce, round number, expected hash, or commitment hash.
- Select the verification mode. Most seed-based crypto casino games use HMAC-SHA256. Some systems use raw SHA-256 or SHA-512 hashing.
- Enter the revealed data. Use the exact seed values, order, separator, and nonce format shown by the casino.
- Paste the expected hash if available. The tool will show whether the computed hash matches.
- Check the game-specific result separately. A hash match is only the first verification step.
If you are verifying Aviator by Spribe, use the dedicated Aviator Provably Fair Verifier. If you want to understand the crash-game hash-to-multiplier model, see the Aviator Hash to Multiplier guide.
Verification Modes Explained
| Mode | Typical use | Input logic |
|---|---|---|
| HMAC-SHA256 | Many seed/nonce based crypto casino games. | Server seed as secret key; message built from client seed and nonce. |
| HMAC-SHA512 | Some games or platforms with SHA-512 HMAC logic. | Server seed as secret key; message built from selected input fields. |
| SHA-256 | Server-seed commitment checks and simple hash-chain checks. | Hash the exact input string. |
| SHA-512 | Completed-round hash checks in some crash-game systems. | Hash the exact combined round input string. |
What a Matching Hash Proves
A hash match means the inputs you entered reproduce the expected hash. That is useful, but it is not the whole fairness story.
| Claim | Can this verifier prove it? |
|---|---|
| The revealed server seed matches a pre-round SHA-256 commitment. | Yes, if you use SHA-256 mode and provide the expected commitment. |
| The server seed, client seed and nonce reproduce a displayed HMAC hash. | Yes, if the selected mode and message format match the platform. |
| The final game result was converted correctly from the hash. | Not by hash comparison alone. You also need the game-specific result formula. |
| The next round can be predicted. | No. |
| The game has no house edge. | No. Verification and RTP are separate issues. |
Server Seed, Client Seed and Nonce
Server Seed
The server seed is generated by the casino. Before the seed is revealed, the casino may show a hash commitment so the seed cannot be changed later without detection.
Client Seed
The client seed is generated by the player, browser, or account settings. Some platforms allow you to edit it manually.
Nonce
The nonce is usually a bet counter or round number. It prevents repeated seed pairs from producing the same result every time.
The exact message format varies by platform. Common formats include:
clientSeed:nonceclientSeed-nonceclientSeed:nonce:cursor- A fully custom string shown in the fairness panel.
Verification by Game Type
Dice and Limbo Games
Many dice-style games use HMAC-SHA256. The hash is then converted into a roll number or multiplier using platform-specific rules. This verifier can recompute the HMAC hash, but you still need the casino’s roll-conversion formula to verify the final number.
Crash Games
Crash games may use hash chains, HMAC hashes, SHA-256 commitments, SHA-512 round hashes, or platform-specific variations. The hash verification step checks consistency of the seed data. The crash-point calculation is a separate step.
Aviator by Spribe
Aviator has its own verification flow involving server seed, client seeds and a SHA-512 round hash. Use the Aviator Provably Fair Verifier for the full workflow. For the educational crash-point model, use the hash-to-multiplier guide.
Hash-Chain Games
Some games use a hash chain where each hash is derived from the previous hash. In that case, verification checks whether the chain links correctly. The exact process depends on the game’s published rules.
SHA-256 vs SHA-512 vs HMAC
SHA-256 and SHA-512 are hash functions. HMAC-SHA256 and HMAC-SHA512 are keyed message authentication codes built using those hash functions.
| Term | Output length | Common role |
|---|---|---|
| SHA-256 | 64 hexadecimal characters | Commitment hash or raw hash check. |
| SHA-512 | 128 hexadecimal characters | Longer raw hash used in some round-verification systems. |
| HMAC-SHA256 | 64 hexadecimal characters | Server seed as key; client seed and nonce as message. |
| HMAC-SHA512 | 128 hexadecimal characters | Keyed SHA-512 variant used by some implementations. |
Do not assume that a 64-character hash and a 128-character hash are interchangeable. The algorithm and input format must match the game’s fairness documentation.
Common Mistakes
- Using the hashed server seed instead of the revealed server seed. You need the original revealed seed for most calculations.
- Using the wrong separator.
client:nonceandclient-nonceproduce different hashes. - Forgetting nonce or cursor values. Some games need additional values beyond server and client seed.
- Comparing the wrong hash. Commitment hash, round hash and result hash may be different fields.
- Assuming a hash match verifies the final payout. The result conversion formula is a separate check.
Frequently Asked Questions
What is provably fair in crypto gambling?
It is a verification system that lets players check whether the revealed seed and round data match a prior hash or expected result hash. It helps detect manipulation after the fact, but it does not remove the house edge.
What does this verifier calculate?
It calculates SHA-256, SHA-512, HMAC-SHA256 or HMAC-SHA512 hashes from the inputs you provide, then optionally compares the result with an expected hash.
Does a matching hash prove the final result was correct?
Not by itself. A matching hash proves the entered inputs reproduce the expected hash. To verify the final game result, you also need the platform’s result-conversion formula.
Why do I need the revealed server seed?
The pre-round server seed is usually hidden behind a hash commitment. To verify the round, you need the original revealed seed, not only the hashed commitment.
Can this tool verify Aviator?
It can compute generic SHA-512 hashes, but Aviator has a specific verification flow. Use the dedicated Aviator verifier for clearer input handling and explanation.
Can provably fair systems predict future rounds?
No. They are designed for verification after the necessary data is revealed. They do not reveal hidden server seeds before future rounds.
Responsible gambling notice: verification can check whether revealed round data matches a cryptographic hash. It does not predict future results, remove the house edge or make gambling profitable.