What "provably fair" actually proves (and what it does not)
A plain-English breakdown of commit–reveal fairness in online games: what the server seed hash guarantees, where the guarantee stops, and the three checks worth doing.
"Provably fair" is printed on almost every crypto game lobby, usually next to a padlock icon. The phrase is not marketing fluff, but it is narrower than most players assume. It describes one specific property: after you bet, the operator cannot change the result without getting caught. It does not say the game has good odds, that the site will pay you, or that the operator is honest about anything else.
This guide explains the mechanism, then draws a clear line around what it covers.
The problem it solves
In a traditional online casino the result is produced on a server you cannot see. You trust a random number generator, ideally certified by a testing lab, and you trust that nobody tampers with it. If a result looked suspicious, you had no way to check.
Provably fair systems replace part of that trust with arithmetic. They borrow an old idea from cryptography called a commitment scheme: you lock a value in a box, show everyone the locked box, and open it later. Nobody can see inside early, and you cannot swap the contents without everyone noticing.
The three ingredients
Almost every modern implementation uses the same three inputs:
| Input | Who chooses it | When you see it |
|---|---|---|
| Server seed | The operator, at random | Only its hash before the bet; the seed itself after you rotate it |
| Client seed | You (or your browser, by default) | Always; you can change it |
| Nonce | Nobody; it is a counter | Always; it goes up by one per bet |
The operator publishes the SHA-256 hash of the server seed before you play. SHA-256, specified in NIST FIPS 180-4, is a one-way function: easy to compute from the seed, practically impossible to reverse, and any change to the seed produces a completely different hash. That published hash is the locked box.
Each result is then computed from all three inputs, typically with HMAC-SHA256 (RFC 2104) keyed with the server seed over a message such as clientSeed:nonce. The first few bytes of that output are turned into a number between 0 and 1, and the game maps that number to a dice roll, a card or a crash point.
What the scheme guarantees
Once the hash is public, three things follow:
- The operator cannot pick the result after seeing your bet. The server seed is fixed by the hash. If they swapped it, the revealed seed would not hash to the value you saw.
- The operator cannot predict your client seed. If you set your own client seed after the hash is published, the operator committed to a server seed without knowing what you would combine it with.
- Every round is reproducible. With the revealed server seed, your client seed and the nonce, anyone can recompute the result with a standard library in any language.
Those properties are strong. They turn "trust us" into "check us" for the narrow question of whether a particular result was fixed in advance.
What it does not guarantee
Here is where the marketing outruns the maths.
It says nothing about the odds. A game can be perfectly provably fair and still have a 10% house edge. The edge lives in the payout formula, not in the randomness. A dice game that pays 1.80× on a 50% chance is "provably fair" and a poor bet. Always read the game's published return to player (RTP).
It does not prove the operator pays. Fairness covers how results are generated. Withdrawals are a separate trust question that you answer with on-chain evidence, terms and track record.
It does not cover shared-seed games completely. In a multiplayer crash game every player sees the same round, so your client seed cannot be used. Operators solve this with a pre-generated hash chain. That proves rounds were not changed after the chain was published, but if the house picked the chain, it does not by itself prove the house did not choose favourable values when creating it. Good operators say this openly. We cover it in detail in our crash hash-chain guide.
It does not stop selective behaviour around the edges. If the client seed is set by the server and never changed, the commitment still holds, but you lose guarantee number two. Change your client seed yourself, especially before a long session.
It does not certify the software. The scheme proves outputs match inputs under the published formula. It does not prove the formula on the rules page is the one the server actually runs, until you recompute a round yourself and get the same answer.
The three checks worth doing
You do not need to verify every bet. A few spot checks catch the failure modes that matter:
- Set your own client seed before playing. Any string works; something random like
k9-walrus-2048is fine. - After a session, rotate the seed so the operator reveals the old server seed. Hash it with SHA-256 and compare it to the hash you were shown at the start. It must match exactly.
- Recompute one or two rounds with an independent tool. Our browser verifier runs locally, or follow the code in How to verify a dice roll step by step.
If any of those fail, stop playing and keep screenshots. A mismatch is not a rounding issue; it means the published commitment does not match the result.
What good disclosure looks like
The strongest fairness pages share a few traits:
- They publish the exact message format for each game, including any game tags, so you can reproduce results without guessing.
- They provide test vectors: sample seeds with known outputs so you can test your own checker.
- They state the RTP and house edge per game, and record the edge used for each bet.
- They are honest about limits, such as what a crash hash chain can and cannot prove.
If a site offers only a padlock icon and the word "fair", treat the claim as unverified.
A worked example of the guarantee
Suppose you sit down for a session and the fairness panel shows a server seed hash beginning 8f36c994…. You set your client seed to test-client-0 and place a bet with nonce 1. The game reports a dice roll of about 6.58.
Later you rotate seeds and the panel reveals the server seed. You hash it and get exactly 8f36c994…, the value you saw before you started. Then you compute HMAC-SHA256 with that seed over test-client-0:1 and convert the first four bytes: 6.5766…
What have you proven? That the result was determined by a seed fixed before you bet, combined with a client seed you chose. What have you not proven? That 97% is a good return, that your next withdrawal will arrive, or that the operator treats every account identically. Those need other evidence: the published RTP table, your own withdrawal test, and, where offered, the edge recorded with each bet in your history.
FAQ
Does provably fair mean I have a 50/50 chance?
No. It means the result was fixed before you bet and can be checked afterwards. Your chance of winning depends on the game and its payout table, which includes the house edge.
Can an operator cheat a provably fair game?
They cannot change a committed result without the revealed seed failing to match its hash. They can still offer poor odds, delay withdrawals or run a formula different from the published one, which is why recomputing a round yourself matters.
Why do I have to change seeds to verify?
The server seed must stay secret while it is in use; otherwise you could compute future results. Rotating ends its use, so the operator can reveal it safely.
Is SHA-256 secure enough for this?
Yes. No practical method exists to find a seed from its SHA-256 hash or to find two seeds with the same hash. The weak points in real systems are disclosure and implementation, not the hash function.