What Is Provably Fair?
Provably fair is a cryptographic method that lets you verify a crypto casino bet's outcome was locked in before it was placed and could not be changed afterward. It combines a server seed, a client seed and a nonce through a hash function — you can recompute the same hash yourself and compare it to the published result. It proves the math wasn't rigged; it doesn't prove the casino is licensed, pays out reliably, or has fair terms.
What is provably fair gambling?
A cryptographic system letting players independently verify that each game outcome was fixed in advance and not altered by the casino after a bet was placed.
Traditional online casinos rely on a Random Number Generator (RNG) that's audited periodically by a third party like eCOGRA or iTech Labs — you have to trust that audit. Provably fair removes the need for third-party trust: the math is open, and you can check every single bet result yourself using free tools, without waiting for anyone's certification.
What are the server seed, client seed and nonce?
The server seed is the casino's secret input, the client seed is yours, and the nonce is a counter that increases with each bet — together they're hashed to produce the result.
- Server seed: A random string generated by the casino. Before you play, the casino shows you only its hash (a scrambled fingerprint) — not the seed itself, so it can't quietly swap it mid-session.
- Client seed: A string you provide (or the casino generates one you can change). Because you control it, the casino can't predict the final outcome ahead of time even though it holds the server seed.
- Nonce: A number that increments by one with every bet you place using the same seed pair, so identical seeds never produce identical results twice in a row.
How the pieces combine
The casino's software runs the server seed, your client seed, and the current nonce through a hash algorithm — commonly HMAC-SHA256. The hash output is converted into the game result (a dice roll, a card, a crash multiplier). Because hash functions are one-directional, nobody can work backward from the published hash to predict future results, but once the server seed is revealed, anyone can work forward and confirm the math.
Client seed vs server seed: what's the difference?
The server seed is generated and held by the casino and only revealed once it is retired; the client seed is yours, visible from the start, and changeable at any time.
The pair exists so that neither side can pick the outcome alone. The casino commits to its half in advance by publishing a hash, and you supply a half it cannot see coming. Chainlink's technical guide to provably fair randomness makes the point directly: the operator cannot pre-calculate a losing result from its own server seed, because it does not know what the client seed will be until you submit it.
| Server seed | Client seed | |
|---|---|---|
| Who creates it | The casino | You, or a default you can overwrite |
| Visible before play | Only as a hash | In full |
| Visible in full | After the seed is rotated | Always |
| Can you change it | Only by requesting a new one | Any time, as often as you like |
| What it prevents | You predicting results in advance | The casino pre-computing your results |
What is an “active server seed hash”?
The active server seed hash is the fingerprint of the server seed your bets are running on right now. Casinos display it while that seed is in use, and it is deliberately the only thing on show: it pins the seed down without telling you what the seed is. Nothing can be verified from the active hash by itself. It becomes useful the moment you rotate the seed, because the casino then publishes the raw seed and you can check that hashing it reproduces the fingerprint you saved. An operator that shows an active hash but never reveals the retired seed has handed you a commitment you can never cash in.
Which hash algorithm does provably fair use?
Most crypto casinos use HMAC-SHA256: the SHA-256 hash function in a keyed construction, with the server seed as the key and your client seed and nonce as the message.
Both halves are public standards rather than house inventions. SHA-256 is specified in NIST's Secure Hash Standard, FIPS 180-4, and the keyed HMAC wrapper around it is defined in RFC 2104. That is what makes independent checking possible: because the algorithms are standardised, any general-purpose HMAC calculator returns the same value as the casino's server, so you never have to verify a casino using only a tool that casino wrote.
The most widely copied layout is the one Stake sets out in its published implementation notes, where the server seed is the HMAC key and the message is the client seed, the nonce and a cursor joined by colons. A single HMAC-SHA256 call returns 32 bytes, which is enough randomness for several outcomes; when a round needs more than that, the cursor increments and yields a fresh 32 bytes without touching the seeds or the nonce. Crash-style games sometimes use SHA-512 or a pre-generated hash chain instead, so read the operator's own fairness page rather than assuming the pattern.
Converting those bytes into a dice roll or a crash multiplier is a separate step, which we walk through bet by bet in reading a provably-fair seed.
Checklist: is this page really provably fair?
A working implementation shows all five of the following. A fairness badge that shows fewer is not something you can actually check.
- An active server seed hash displayed before you bet, not produced afterwards.
- An editable client seed you can set to a string of your own choosing.
- A visible nonce or bet ID attached to every individual bet in your history.
- A named algorithm — “HMAC-SHA256”, not “our proprietary fairness engine”.
- A rotation control that reveals the retired server seed in full, so you can re-hash it and match the fingerprint you saved.
Break any one of those links and the chain stops holding: an unrevealed seed cannot be checked, an unnamed algorithm cannot be reproduced, and a hidden nonce leaves you unable to say which bet you are verifying.
How do I actually verify a provably fair bet?
After the casino reveals the unhashed server seed, run it plus your client seed and nonce through the stated hash algorithm yourself and compare the output to the published result.
Note the seed hash before you play
Before placing bets, the casino should display a hash of the current server seed — save it or screenshot it.
Play your session as normal
Every bet uses the same server seed and client seed, with the nonce increasing by one each time.
Rotate the seed to reveal it
When you change your client seed or request a new server seed, the casino reveals the previous (now-retired) server seed in full.
Confirm the hash matches
Run the revealed server seed through the same hash function the casino uses (SHA-256) and check it matches the hash shown in step 1 — this proves the seed wasn't swapped.
Recompute the bet result
Using a free HMAC-SHA256 calculator (many are available online), feed in the revealed server seed, your client seed, and each bet's nonce, and confirm the output matches the game result you were shown.
| Step | What you check | What it proves |
|---|---|---|
| Before playing | Casino-published server seed hash | Server seed exists and is fixed |
| During play | Client seed & nonce for each bet | Your inputs are recorded correctly |
| After seed rotation | Revealed (unhashed) server seed | Casino didn't change the seed mid-session |
| Independent recompute | Hash of seed + client seed + nonce | Each bet's result wasn't altered after the fact |
Provably fair verifies the game math only. It says nothing about whether a casino holds a valid gambling licence, pays out withdrawals reliably, or has fair bonus terms — those need separate checks, which is exactly what we cover in our review methodology.
It is also no substitute for the statistical testing a licensed operator has to pass. Under the UK Gambling Commission's remote technical standards, requirement RTS 7A obliges licensees to demonstrate that outcomes are “acceptably random” — uniformly distributed over the output range, computationally infeasible to predict, and not reproducing the same output stream — and rules out adaptive, compensated games outright, while RTS 7D stops an operator changing payouts or outcome probabilities while a game is live. Provably fair checks one bet at a time; certification checks the distribution across millions of them. We set the two models side by side in provably fair vs certified RNG.
Does provably fair guarantee a casino is trustworthy?
No. It only proves individual game outcomes weren't tampered with — it says nothing about licensing, withdrawal reliability, or terms, which need separate checks.
Treat provably fair as one input among several. Combine it with the licensing and terms checks described in our methodology page, and with basics like reading a glossary of terms such as RTP and house edge before you judge a casino's overall trustworthiness. For a ranked comparison of operators that publish working provably-fair tools, see our best crypto casinos page. It is also worth trying the mechanic hands-on: some operators build their games in-house rather than licensing them, such as the Tokyo-based Betkyo, whose provably-fair "originals" can be sampled in free demo mode with no account before any deposit.