How a dice roll becomes mathematically verifiable
Provably fair is described so often and explained so rarely that most players who rely on it could not say what it proves. The mechanism is not complicated, and knowing it tells you exactly where the guarantee ends.
The commitment
The whole system rests on one idea from cryptography: you can prove you decided something in advance without revealing what you decided.
Before you bet, the casino generates a secret server seed. It does not show you the seed. It shows you a hash of it, which is a fixed-length fingerprint produced by a one-way function. You cannot work backwards from the hash to the seed. But once the seed is revealed later, you can hash it yourself and confirm it matches what you were shown.
That is the commitment. The casino is locked into a value before it knows what you will bet.
The inputs
| Input | Who controls it | Purpose |
|---|---|---|
| Server seed | Casino | Secret until revealed, committed via its hash |
| Client seed | Player | Stops the casino choosing an outcome it likes |
| Nonce | Increments | Makes each round unique without new seeds |
The client seed is the part players skip and the part that makes the system work. If the casino supplied both seeds it could grind through candidate server seeds until it found one producing bad outcomes, then commit to that. Your seed makes precomputation useless, because it does not know your input when it commits.
Turning seeds into a number
The seeds and nonce are combined using HMAC-SHA256, a keyed hash function. It produces a long hexadecimal string that behaves like a random number but is completely deterministic: same inputs, same output, every time, on any machine.
The game then maps that string to a result. For a dice roll, take characters from the front of the hash, convert to an integer, divide into the range. The mapping is published, so you can reproduce it.
Determinism is the point. You can rerun the calculation yourself weeks later and get the same number. If it differs from what the game showed, something is wrong, and that is provable rather than arguable.
Verifying a round
Rotate your seed pair, which reveals the old server seed. Take the revealed seed, your client seed and the nonce, and run them through HMAC-SHA256 using any of the public verifiers or a few lines of code. Hash the server seed on its own and compare it with the commitment you were shown before betting.
Two matches mean two things: the server seed is the one that was committed, and the result follows from it. Operators that publish the exact method rather than describing it loosely make this straightforward, which is a distinction worth noticing. Stake documents its HMAC-SHA256 implementation in full, method included, which is why the provably fair section of our Stake review could be checked rather than taken on trust.
The boundary
The proof covers one question: did the casino alter the outcome after seeing your bet. It says nothing about the house edge, which can be whatever the operator sets and is usually visible only in the paytable. It says nothing about whether you will be paid. And it says nothing about the operator's licence or solvency.
A provably fair game with a 12 percent edge is honest and terrible. Both things are true at once, and the cryptography only speaks to the first.
Verify once, early
The feature is close to worthless if nobody uses it, and almost nobody does. Verify a single round in your first session. It takes two minutes, it confirms the tools work rather than merely existing, and it tells you whether you can set and rotate your own client seed. A site that controls both seeds has kept the label and removed the substance.
