A hash commitment is the cryptographic backbone of provably fair gaming. It works because a casino can publicly commit to a secret value before a round starts, then reveal that value after the round ends. If you can recompute the same hash from the revealed value, you know the casino did not change the outcome after seeing your bet. This is not a trust-us claim. It is a mathematical property you can verify with a few lines of code or a reputable provable fairness verifier.
At the core of every fair round on sites that use this method is a three-part fingerprint: the server seed hash, the client seed, and a nonce (or round number). Understanding how these three elements interact is the difference between blindly trusting a payout table and independently checking that the round you played was generated in a way nobody could have manipulated.
What Is a Hash Commitment?
A hash commitment is a two-phase protocol. In the commitment phase, the casino generates a random string (the server seed) and publishes only its hash—typically SHA-256. Hashing is a one-way function: given the hash, you cannot recover the original seed, but given the seed, you can quickly verify it matches the hash. Until the reveal phase, the casino cannot change the seed without producing a different hash, and players cannot learn the seed in advance.
In the reveal phase, after the round is finished, the casino publishes the original server seed. You can then hash it and compare it to the committed hash. If they match, the casino is bound to the same secret it used before the round. This is the essence of the hash commitment: a promise that can be checked after the fact, but not altered in between.
The Three-Part Fingerprint
Each round is uniquely identified by three inputs combined in a deterministic way. The exact concatenation order or algorithm may vary by site, but the principles are consistent across implementations. The three parts are:
- Server seed hash – the commitment. It anchors the server seed before the round.
- Client seed – chosen by the player (or generated on their behalf) and known to both parties before the round.
- Nonce – an incrementing counter or round identifier that ensures each round is distinct.
Client Seed
The client seed is the part a player controls or at least influences. In a fair setup, the casino should allow you to set your own client seed before you start playing. Combined with the nonce, it prevents the casino from reusing the same server seed to produce identical outcomes across multiple rounds. Even if the server seed is fixed for a period (often 10,000 rounds or 24 hours), each different client seed and nonce yields a completely different round result.
If you do not set your own client seed, the casino will generate one for you. A skeptical player should treat an unchangeable, server-generated client seed as a red flag. The entire point of a client seed is that it is a second source of entropy you can independently verify after the round.
Server Seed
The server seed is the secret held by the casino. Before a round, only its hash is public. After the round, the seed itself is published. The combination of pre-commitment and post-reveal is what makes the system tamper-evident. If the casino wanted to influence the outcome, it would need to choose a server seed that produces a desirable result before committing to its hash—which is computationally infeasible for a good hash function. Once committed, it is equally infeasible to find a different seed with the same hash.
Nonce or Round Number
The nonce is a simple integer that increments with each wager. It exists to prevent the same inputs from generating the same result. If you played multiple rounds with the same server seed and client seed but no nonce, every round would be identical. The nonce is publicly visible in round history, so you can confirm that the round you are checking is the one you actually played.
Some sites use a per-bet nonce; others use a “round ID” that incorporates server and client seeds. Either way, the fingerprint is the ordered set of these three values. The exact combination method is usually explained in the site’s fairness documentation.
Why Commitment Precedes Reveal
The order of operations matters. If the casino published the server seed before the round, it could not adjust the outcome afterward, but a player could use that knowledge to place bets only when the result favors them. If the casino published nothing before the round, it could choose any server seed after seeing the bet and therefore control the result. Hash commitment solves this by locking the server seed before the round while keeping it secret. This is a standard cryptographic technique known as commit-and-reveal.
When you inspect a round, you should always check the timestamp or block height of the commitment. On chain-based implementations, the hash may be stored in a transaction on a public ledger, which gives you an independent timestamp. For conventional centralised sites, the best you can do is check that the hash was published before the round result—usually visible in the round detail view. A fair system will display this information in a way you can audit.
Verifying a Round: Step by Step
Verification is a deterministic process. You need the three inputs and the algorithm specification. Here is a generic procedure that applies to most provably fair systems:
- Copy the revealed server seed from the round history after it is published.
- Compute SHA-256 of that seed and compare it to the server seed hash shown before the round. If they do not match, the casino revealed the wrong seed.
- Combine the server seed, client seed, and nonce according to the casino’s documented format. This is often a concatenation such as
serverSeed:clientSeed:nonce. - Hash the combined string (typically with HMAC-SHA256 or a second SHA-256 pass) to produce a 64-character hex digest.
- Convert the first several hex characters to a decimal number and map it to the game’s outcome range (for example, a 0–99 number for a crash multiplier or dice roll).
This logic can be executed in any web browser using a simple script. If you prefer not to code, many independent verification tools accept the three inputs and output the result. The important point is that you do not need to trust the casino’s own “result” display. You can reproduce it from raw inputs.
What You Can Check Independently
There are layers of verification, each with different strength:
| Check | What it proves | How to do it |
|---|---|---|
| Hash match | The revealed server seed is the one committed before the round. | Hash the revealed seed and compare to the pre-round hash. |
| Result match | The displayed round result is derived from the three inputs. | Run the documented algorithm with the revealed seed, client seed, and nonce. |
| Ledger timestamp | The commitment actually existed before the round outcome was known. | Check the commitment on a public fairness ledger or blockchain timestamp. |
| Seed rotation | The casino does not reuse seeds beyond the stated period. | Verify that a new server seed hash accompanies each seed cycle described in the fairness guide. |
The third check is the hardest to fake. If a site posts its server seed hashes to a public ledger before each round or seed cycle, it creates a tamper-evident record that cannot be silently rewritten. Without such a ledger, you are relying on the casino’s own website to show you the “before” hash, which is weaker but still meaningful if the round history is immutable and stored on-chain or in a signed audit log.
Limitations and Edge Cases
Hash commitment is not a complete solution to online gambling fairness. It proves that the casino did not change the seed after the round, but it does not prove that the casino picked an honestly random seed in the first place. A casino could, in theory, generate thousands of server seeds and commit to a hash of only the one that produces a low payout pattern—though this is computationally impractical with a 256-bit hash and would be detectable if the reveal phase exposes the seed for audit.
Another limitation is the algorithm mapping. If the mapping from hash to outcome is obscure or undocumented, you cannot verify it. Always read the site’s fairness documentation carefully. If it glosses over the conversion step, ask the casino for the exact source code. Reputable operators publish theirs. Use casino reviews that inspect those details rather than taking a website’s badge at face value.
Finally, remember that provable fairness does not change the house edge. A verifiable round can still have a 5% house advantage. The purpose of hash commitment is transparency, not profitability. You still need a solid bankroll management plan to avoid losing more than you can afford.
FAQ
What happens if the revealed server seed does not match the pre-round hash?
That is a definitive failure of the commitment scheme. If the hash of the revealed seed differs from the hash shown before the round, the casino either published the wrong seed or changed it after the fact. Stop playing immediately and preserve a screenshot of both values. Contact support and, if necessary, the site’s licensing authority. This is the one case where you do not need to trust any tool—SHA-256 is public and deterministic.
Can I set my own client seed on every round?
Most provably fair games allow you to change the client seed, but changing it on every round is often unnecessary. The nonce already makes each round unique given the same client and server seed. A common practice is to set a new client seed at the start of each server seed cycle. Some sites let you change it per round, which is fine as long as the client seed value is included in the round’s fingerprint. Check the round details to confirm the client seed shown matches the one you set before the round.
Do I need to be a programmer to verify hash commitments?
No. Any standard verification tool or spreadsheet script can perform the required SHA-256 and HMAC operations. Many sites include a built-in verifier, but you should prefer an independent tool you control. The mathematics is simple enough to reproduce with a few lines of Python or JavaScript. If the site’s documentation does not give you enough detail to recreate the calculation, treat that as a warning sign.







