Verify a bet yourself
Paste the seeds the operator gave you and recompute the outcome here. Every intermediate value the operator’s own documentation names is printed, so you can check the working rather than trade one verdict for another.
HMAC-SHA256 scheme32 checks against published vectors passruns in your browsernothing transmitteddata collected 2026-09-22
The arithmetic happens in your browser, on your own machine. Nothing you type is sent to CryptoGuardz or to anybody else, there is no request behind the button, and the page works with the network disconnected. That is not a courtesy. A server seed you have not yet rotated is a live secret: anyone holding it can predict your next bets, so pasting one into a remote form hands away the thing the scheme exists to protect. It is also the reason this page says where it runs at all, which is a sentence 7 of the 9 operators that offer a verifier have never written.
What a match proves
A match proves two separate things, and it is worth keeping them apart. If the hash you were shown before playing equals SHA-256 of the server seed you were given afterwards, the operator did not swap the seed once it saw how you were betting. If the outcome recomputes from those seeds, the operator applied the algorithm it documents. Together they close the one attack this scheme was designed to close: choosing the result after seeing the bet.
What a match does not prove
It says nothing about the house edge, the paytable, or whether the game was worth playing. A dice game can be perfectly verifiable and still take eleven percent of every wager. It says nothing about the games outside the scheme, which at every operator we read includes all the third-party slots and all the live dealer tables. And it says nothing at all about whether you will be paid: an operator can run flawless provably fair originals and still close your account and keep the balance. What the contract lets them do is a different document and a different question.
What a mismatch proves
Less than people expect, and this is the part a verifier that only prints a red cross gets wrong. A mismatch has four common causes and only the last is misconduct.
- Wrong scheme. This tool implements HMAC-SHA256 keyed with the server seed over the message clientSeed:nonce:round, where round is the cursor divided by 32 and rounded down, which is the scheme Stake published and which several operators’ in-house originals now follow. BC.GAME Classic Dice is plain SHA-256 over a colon-joined string with no HMAC. BC.GAME Crash and Gamdom run reverse hash chains with no client seed at all. Thunderpick hashes a salt against the winning number. Cloudbet is on SHA-3. None of those will reproduce here, and none of them is dishonest for that.
- Wrong conversion. Even among the HMAC-SHA256 operators the last step differs. Stake’s limbo divides 1e8 by float times 1e8; Shuffle’s divides by MAX_VALUE times float plus one. The same seeds give different multipliers at the two sites, legitimately.
- Wrong inputs. A nonce off by one, a client seed changed since the bet, or a server seed from a different rotation will all fail. So will verifying a bet placed under a seed pair that has not been rotated yet, because the unhashed server seed you need does not exist for you to enter.
- The operator did not do what it documents. This is the finding worth escalating, and it is only available once the three above are ruled out.
So a mismatch is a question, not a verdict. Check which scheme the operator documents before concluding anything: the implementations register records that for all 14, with the documentation URL and the date we read it.
How to get the seeds
Before you play, the operator shows a hashed server seed. That hash is the commitment, and it is the number to write down, because it is worthless to you afterwards if you did not keep it. You play under it with a client seed you chose, and each bet increments a nonce. When you rotate the seed pair the operator reveals the unhashed original, and only then can the bets made under it be checked. 8 of 14 operators state that the hashed seed is published before play. 6 of 14 state that the old seed is revealed afterwards. If your operator does neither, there is nothing here for you to verify, and that is the finding.
Why this implementation can be trusted more than most
A verifier nobody has tested is worse than no verifier, because it lends the operator’s number a confirmation it has not earned. The arithmetic here lives in one module that is run both by this page and by a test script that asserts it against vectors published by other people, 32 checks in all, and the build fails if any of them stops passing. The scheme, the vectors and the conversions are the ones the operators publish, cited on the implementations register. If you would rather not trust this page either, that is the correct instinct: Sportsbet.io and Gamdom publish verifiers you can run without us.