Provably fair
How to verify a round yourself, and what that verification does not prove.
The short answer
Provably fair is a cryptographic method that lets a player demonstrate a casino did not change the outcome of a bet after it was placed. The casino publishes a hashed server seed before play, combines it with a client seed and a counter through HMAC-SHA256, then reveals the seed so results can be reproduced.
Provably fair gets used as a trust badge, but underneath it is a checkable mechanism, not a marketing claim. A player can reproduce the result of a bet from values that were fixed before the bet was placed. That reproducibility is what separates a provably fair game from a game that simply asks you to believe the casino.
The method relies on a simple property of cryptographic hashing: the casino can commit to a secret seed by publishing its hash, but cannot later change the seed without the hash no longer matching. The player contributes a client seed, and every bet is generated from that pair plus a counter.
This page explains what the phrase actually covers, how the check works, where a real implementation differs from a label, and which parts of a casino's behaviour the method does not touch. The honest version of provably fair is narrower than the way the term is usually advertised.
What provably fair actually means
Provably fair means the outcome of each covered bet is determined by inputs that were committed to before you placed the bet. The casino does not simply claim it played fair; it publishes the hash of a server seed in advance and later reveals the seed so you can repeat the calculation.
The player supplies or accepts a client seed. Each round combines the server seed, the client seed and a nonce that increments by one every bet, usually through HMAC-SHA256. The resulting bytes are converted into the game's outcome. Because the same inputs always produce the same output, the result can be checked.
That is a property of the game round, not a promise about the odds. A game can be provably fair and still carry a high house edge, because fairness of process and generosity of payout are different measurements that are often blurred.
How it works underneath
Before a seed pair is used, the casino generates a server seed and publishes only its hash, normally SHA-256. The player picks a client seed or accepts the one the interface suggests. Those two values, together with a nonce that increases by one for each bet, are the complete set of inputs for the round.
The round result is produced by feeding those inputs through HMAC-SHA256. The output bytes are mapped onto the game, for example a crash multiplier, a dice roll or a card. No later input can alter that mapping, because the only secret was the server seed behind the published hash.
When the player rotates the seed pair, the casino reveals the original server seed. At that point two checks must hold. Hashing the revealed seed must reproduce the hash published before the first bet, and re-running the HMAC with that seed, the client seed and each nonce must reproduce every result from that seed's round history.
Telling a real implementation from a claim
A real implementation puts the seed controls inside the game interface, usually behind a fairness or settings icon. You should see the current server seed hash, the client seed, the nonce counter for the next bet, and a control to rotate the pair. If those controls are missing, the site is not giving you the information needed to check anything.
The rotation step matters because that is when the previous server seed is revealed. Before a rotation there is no revealed seed to verify against. A site that shows a fairness logo but never exposes a previous seed is describing the idea, not providing the mechanism.
A good implementation also works with independent verifiers, including open-source ones the casino does not host or control. The check is strongest when you can reproduce the outcome in a tool that has no connection to the operator. A self-hosted verification widget alone is weaker because it runs on the site you are checking.
What checking it yourself proves and what it does not
When the check passes, you have proved two things. The outcome of that bet was already fixed by a seed pair the casino committed to before the bet was placed, and the result you saw in your history matches that seed pair. That is a real property and it rules out changing the result after the bet.
What it does not prove is equally specific. It says nothing about the house edge, because a game can be provably fair and still return far less than a competitor's game. Fairness of process is not generosity of payout, yet the two are frequently argued as if they were the same thing.
A single verified round proves that round and nothing else. Establishing that the distribution is honest over time takes a large number of checked rounds, and almost nobody checks more than one. A verified round also does not prove the casino is solvent, licensed, or willing to pay a withdrawal. Those are separate questions with separate answers.
What provably fair does not protect you from
Provably fair covers only games whose outcome the operator generates itself: dice, crash, plinko, mines and some card games. Slots supplied by external studios do not work this way at all. Their randomness is audited by testing laboratories instead, which is a different assurance with a different weakness, and a site can carry both and imply the first covers the second.
The scheme does not stop an account being closed, a bonus being voided, or winnings being held for review. Those live in the operator's terms and no hash touches them. It also does not prove the casino is solvent, licensed, or willing to pay a withdrawal. A verified round and a paid withdrawal are separate questions.
The operator picks the server seed before committing to it, which is expected. But leaving the client seed at whatever the site pre-filled weakens the commitment, because only one party contributed entropy. A client seed the player chooses is what makes the scheme binding, and many players never change it.
Where the terms and conditions narrow it
Operator terms routinely reserve the right to void bets the operator considers erroneous, to correct the consequences of a technical malfunction, and to close accounts at discretion. A provably fair result does not override any of those clauses. The clause that voids a round for a malfunction is the one that most often surprises people.
Even a fully verified round can be set aside under those terms, because the terms operate on a layer above the game's randomness. The hash proves what the game generated, not how the operator will treat that outcome afterwards. Withdrawal review and account closure happen after the result, under different rules.
That does not make provably fair worthless; it means the mechanism has a limited jurisdiction. It verifies the round, not the relationship. The operator's discretion over your account is written in the terms, and the seed pair cannot answer whether that discretion will be used.
Who this matters to, and who can ignore it
Provably fair matters most if you play in-house games such as dice, crash, plinko or mines. Those are exactly the games where the operator generates the outcome, and where you can meaningfully run the check. If you do not check, you are still relying on the site's word.
It can mostly be ignored if you only play slots from external studios. Those games are tested by laboratories rather than by seed commitment, so the provably fair badge on the site does not apply to what those slots do. Look for the game's RTP and the laboratory audit report instead.
The middle case is someone who wants a method, not a promise. If you are willing to spend ten minutes rotating seeds and comparing outputs, the check gives you something concrete. If you will not do that, there is no practical difference between a provably fair game and one that simply claims fairness.
Check it yourself
01
Open the fairness panel
Inside the game, open the fairness or settings icon. Record the server seed hash shown before your next rotation, along with the current client seed.
02
Rotate the seed pair
Rotate the pair and wait for the previous server seed to be revealed. Find a round from that seed pair in your bet history and note its client seed and nonce.
03
Run an independent verifier
Open an open-source provably fair verifier the casino does not host. Paste in the server seed, client seed, and game name, then enter the nonce.
04
Compare the result
Run the verifier and compare its output with the outcome shown in your bet history for that nonce. The result must match exactly.
05
Hash the revealed seed
Put the revealed server seed through any SHA-256 tool. Compare the hash to the one you recorded before rotating. It must match character for character.
Statements you can confirm independently
- A provably fair game publishes the hash of its server seed before the first bet on that seed, not afterwards.
- Rotating the seed pair is what reveals the old server seed; without a rotation there is nothing to check.
- A SHA-256 hash of the revealed server seed must be identical, character for character, to the hash published in advance.
- The same server seed, client seed and nonce always produce the same outcome; that determinism is what makes the scheme checkable at all.
- A verifier that runs outside the casino's own site can reproduce the result without the casino's cooperation.
Questions people ask about Provably fair
Is provably fair the same as a fair game?
No. Provably fair means the outcome can be reproduced from committed inputs, not that the odds are generous. A game can be provably fair and still have a high house edge or a lower return than another game. Fairness of process and payout rate are separate numbers, and providers often blur them.
Can a casino still cheat with provably fair?
It cannot change a result after the bet without breaking the hash check, if the player actually checks. But it can still set a high house edge, refuse a withdrawal, or close an account. Provably fair limits one specific kind of manipulation, not the whole relationship.
Does provably fair apply to slots?
No, not to slots supplied by external studios. Provably fair covers games whose outcome the operator generates itself, such as dice, crash, plinko and some card games. External slots are audited by testing laboratories instead, which is a different assurance. A site can carry both and imply the first covers the second.
What happens if I leave the client seed unchanged?
The commitment becomes weaker because only the operator contributed entropy to the round. A client seed you choose is what makes the scheme binding. Leaving the pre-filled value still produces checkable results, but it removes one of the two independent inputs.
Why do I need to rotate the seed?
Rotating is what reveals the previous server seed. Before a rotation there is no revealed seed to verify against, because only the hash has been published. The check requires hashing that revealed seed and matching it to the earlier hash, then re-running the rounds.
Does a verified bet mean the casino will pay?
No. A verified round shows the outcome was generated by the committed seed pair. It says nothing about the casino's solvency, licensing, or willingness to process a withdrawal. Payment and account decisions are governed by separate terms and separate risks.
How many bets do I need to check to be sure the game is fair?
A single verified round proves that round only. To build confidence that the distribution is honest over time you would need to check a large number of rounds, because selective checking cannot establish the overall return or absence of bias.
Where do I find the server seed hash?
Inside the game interface, usually behind a fairness or settings icon. You need the hash that was published before the first bet on that seed, not a later one. Record it before rotating, because after rotation the previous seed is revealed and the advance hash is the reference you compare against.
Facts last reviewed: 2026-08-26