WHAT IS HASH VERIFICATION?
Hash verification is the process of recomputing a game round's SHA-256 hash from the revealed seeds and comparing it with the hash the casino published before the round was played. A match proves the result was fixed before you bet; a mismatch means the seed was swapped and nothing in that session can be trusted.
The six steps of checking a round
- Step 1 — copy the hashed server seed shown in the fairness panel before you place any bets.
- Step 2 — play your session.
- Step 3 — rotate seeds so the casino reveals the plain server seed it was using.
- Step 4 — run SHA-256 over the revealed seed and confirm it equals the hash from step 1. This is the commitment check.
- Step 5 — recompute each result with HMAC-SHA256(server seed, client seed:nonce) and the game's byte-to-outcome formula.
- Step 6 — compare the recomputed outcomes with your bet history line by line.
Steps 4 and 6 are the two places a dishonest operator would be caught: a swapped seed fails step 4, and an altered individual result fails step 6.
Game hashes, round hashes and independent tools
Casinos present this under "fairness", "verify", "provably fair" or "game hash", and each bet's detail page carries a "verify" link that pre-fills a calculator. The round identifier in crash and similar games is called the "game hash" or "round hash"; in dice, mines, plinko and limbo it is the trio of server seed, client seed and nonce. Independent tools exist so you are not relying on the casino's own calculator: the provably fair verifier covers the common originals, the crash verifier walks a hash chain, and the dice verifier and step-by-step verification guide show the byte conversion for each game.
What a passed or failed check actually tells you
Verification proves integrity, not generosity. A round that verifies at a 4% house edge is exactly as costly as one that was never checked; the hash shows the casino did not move the result, nothing more. It is also binary: a single failed commitment check (step four) invalidates every bet under that server seed, and that is grounds to withdraw and report, not to keep playing. In practice almost all failures are user error, a copied hash from the wrong seed pair or a nonce off by one, so re-check inputs before concluding fraud. Verify a sample of 5 to 10 bets per rotation rather than every bet; one mismatch in the sample is enough to indicate a problem, and a clean sample across the commitment check is strong evidence the session was honest. The provably fair entry covers the overall scheme.
Hash Verification FAQ
How do I verify a casino hash?
Copy the hashed server seed before betting, rotate seeds afterwards to reveal the plain seed, SHA-256 the revealed seed and confirm it equals the hash you copied, then recompute individual results with HMAC-SHA256 of server seed, client seed and nonce and compare them with your bet history.
What is a game hash in crash?
It is the round's identifier in a hash chain: each game's hash is the SHA-256 of the following game's hash, and the crash multiplier is derived from an HMAC of that hash with a public salt. Revealing one hash lets you verify every earlier round.
What if the hash doesn't match?
First re-check your inputs, because a wrong seed pair or an off-by-one nonce is the usual cause. If the revealed seed still does not hash to the published commitment, the casino changed its seed mid-session; stop playing, withdraw and report it.
Can a hash be faked?
Not after the fact. SHA-256 is a one-way function, so the casino cannot find a different seed that produces the same published hash. The only attack is never revealing the seed, which is why verification requires a seed rotation.