How provably fair works: HMAC-SHA256 explained simply
Provably fair means you can re-run your own roll and prove the site did not cheat. Here is the seed-and-hash system behind it, without the cryptography degree.
Key takeaways
- The server commits to a secret seed by publishing its hash before you play.
- Your client seed makes it impossible for the server to precompute your result.
- HMAC-SHA256(server seed, client seed:nonce) produces the outcome number.
- After rotation the server seed is revealed so every past roll can be re-checked.
Provably fair is a promise with proof attached. Instead of asking you to trust that the random number generator is honest, the platform locks in its randomness before you play, in a way it cannot change afterwards, and hands you everything you need to re-run the calculation later.
The three ingredients
- Server seed — a long random secret the platform generates and keeps hidden while it is active.
- Client seed — a string that belongs to you. You can change it whenever you like.
- Nonce — a counter that increases by one with every roll, so no two rolls are identical.
Step one: the commitment
Before you place a single bet, the platform shows you the SHA-256 hash of the active server seed. A hash is a one-way fingerprint: from the seed you can compute the hash in microseconds, but from the hash you cannot recover the seed in a human lifetime. Publishing the hash is a commitment — it proves the seed already exists and pins down which seed it is, without revealing it.
Step two: your contribution
The server seed alone would let the platform precompute every future outcome. Your client seed prevents that. Because you choose it — and can change it at any moment — the platform cannot know in advance what the combined input will be, so it cannot pick a server seed that produces bad results for you specifically.
Step three: the roll
The outcome is produced with HMAC-SHA256. HMAC is a keyed hash: it takes a secret key and a message and produces a fixed-length fingerprint that nobody can forge without the key. Here the server seed is the key and your client seed plus the nonce is the message.
The resulting hexadecimal digest is sliced into chunks, converted to numbers, and normalised to a value between 0 and 1. That number is mapped onto the box's weighted prize list — or onto a crash multiplier, a mine layout, a Plinko path. Same inputs, same output, every time, on any machine in the world.
| Input | Who controls it | Public before the roll? |
|---|---|---|
| Server seed | Platform | No — only its hash |
| Client seed | You | Yes |
| Nonce | Automatic counter | Yes |
Step four: the reveal
When you rotate your seed pair — or when the platform rotates it on a schedule — the old server seed is revealed in full. Now you can hash it yourself and confirm it matches the fingerprint published before you played, then re-run HMAC-SHA256 for every nonce you used and confirm every single outcome. If one digit had been altered, the hash would not match and the fraud would be undeniable.
What provable fairness does not do
It proves the roll was honest. It does not make the odds good. A perfectly provable box can still have a punishing prize list, which is why odds transparency and fairness verification are two separate checks you should do together. Provable fairness guarantees the game was played by the published rules — the published rules are up to you to read.
Run the verifier against one of your own rolls and see the maths line up.
Open the verifier