Provably fair, explained: what it proves and what it does not
Server seeds, client seeds, nonces and VRF. How provably fair verification works, how to run it, and the four things it cannot tell you.
Provably fair is the oldest verifiability claim in crypto gambling and the most misread. It is a genuine cryptographic commitment, it is worth having, and it answers a much narrower question than the marketing suggests. This page sets out the mechanism, how to run a verification yourself, and where the guarantee ends.
The problem it solves
In an ordinary online casino, the operator generates the result on its own server and tells you what happened. You have no way to distinguish a fair draw from one that was recomputed after seeing your bet. Regulators handle that with audits and licensing. Provably fair handles it with a commitment: the operator has to lock in its randomness before you play, in a way it cannot change afterwards, and publish enough for you to check.
The mechanism
The classic implementation has four parts.
Server seed
A random string the operator generates and keeps secret while you play. Before your first bet it shows you a hash of that seed — usually SHA-256. A hash is one-way: it reveals nothing useful about the seed, but the seed can only produce that one hash. Publishing the hash first is the commitment.
Client seed
A string you control. Most sites generate one for you and let you replace it. This is the part players skip and it is the part that matters: if you never set your own client seed, the operator chose both inputs, and the commitment is much weaker in practice even though the maths is unchanged.
Nonce
A counter that increments with each bet, so the same seed pair produces a different result every round without a new commitment.
The combination
The result of a round is a deterministic function of (server seed, client seed, nonce) — typically an HMAC, mapped onto the game’s outcome space. Deterministic means: given the same three inputs, the same result comes out every time, on any machine.
Verification happens when you rotate your seed. The operator reveals the old server seed; you hash it yourself and confirm it matches the hash you were shown at the start; then you re-run the published algorithm over your recorded rounds and check every result. If one round does not reproduce, the commitment was broken.
How to actually verify a round
Most sites host a verifier page, and using the operator’s own verifier only tells you the operator agrees with itself. The check worth doing is the independent one.
- Set your own client seed before you play. Anything unpredictable is fine.
- Record the pieces: the hashed server seed shown up front, your client seed, the nonce of the round, and the result.
- Rotate the seed to force the reveal, and copy the revealed server seed.
- Hash the revealed seed with any independent SHA-256 tool and compare it to the hash you recorded. If they differ, stop — nothing else matters.
- Re-run the game function yourself using the operator’s published algorithm, in a script you control rather than in its verifier.
Step five is where the published documentation earns its keep. An operator that publishes the exact function, including how the hash output is mapped onto the outcome, is making itself checkable. One that only offers a verify button is asking you to trust the button.
On-chain randomness and VRF
A commitment scheme still runs on the operator’s servers. The on-chain version moves the randomness somewhere neither party controls.
A verifiable random function produces two things: a random value and a cryptographic proof that the value was derived correctly from a private key whose public counterpart is known in advance. The proof is verified by the contract before the value is used. The operator cannot request a second draw because it did not like the first without that being visible on-chain.
Commit-reveal anchored on-chain is the other common pattern: the commitment hash is written to a contract, so the timestamp of the commitment is public rather than asserted. Block-derived entropy — using a future block hash — is cheaper and weaker, because block producers have some influence over what they publish.
This is the practical difference between a provably fair crypto casino and an on-chain one, and why our tier ladder separates them. A site can publish seed pairs from its own database and still be tier T2; a contract that verifies a VRF proof before paying out is doing something an outsider can check without permission.
Among operators we currently record at the on-chain end of the ladder — Solpump, JustBet and Overtime, as of September 2026 — the randomness design is part of what puts them there. We record the architecture those projects document publicly; we have not deposit-tested any of them, and their tiers stay marked as our reading rather than a verified finding.
The four things it does not prove
This is the part worth memorising.
It does not prove the odds are good. The commitment guarantees the published rules were followed. If the rules give the house a large advantage, a perfectly verifiable round will still lose you money at exactly the advertised rate. Fairness of process and fairness of terms are different questions.
It does not prove the operator is solvent. A verified win you cannot withdraw is a verified win you do not have. Payout behaviour and reserves are separate evidence, which is why they are separate criteria in our grid.
It does not cover the whole catalogue. In-house originals are usually the provably fair part. Third-party slots and live tables typically are not, because the operator does not generate those results. A site can be honest about this and still be described in coverage as “provably fair” without qualification.
It does not prove the operator will still be there. Nothing about a commitment scheme predicts survival. The operators in our graveyard did not fail a hash check; they stopped answering.
How we score it
Published provably fair records move the transparency sub-score, and they are worth more when the algorithm is documented well enough to reimplement. They do not lift the custodial cap on their own: if no bet can be reconstructed from chain data, transparency stays at or below 12 of 25 no matter how good the verifier page is. The full rule set is on the methodology page, and you can sort the whole index by tier and custody on the trust score ranking.
18+ only. Gambling involves real financial risk and can be addictive. Nothing here is financial, legal or gambling advice.
Questions
What does provably fair actually prove?
That a specific result was derived from a seed the operator committed to before you played, using the published algorithm. It proves the outcome was not altered after your bet. It proves nothing about the odds built into the game.
Is a provably fair game the same as an on-chain game?
No. Classic provably fair is a commitment scheme that can run entirely on private servers. An on-chain game puts the wager, the randomness and the payout in a contract. A site can offer the first without any of the second.
Do I have to verify every bet?
No, and almost nobody does. The value is in the ability to check: rotate your seed, verify a handful of rounds at random, and verify any round that matters. A scheme that is never checked by anyone is close to a scheme that does not exist.
What is a VRF and why does it matter?
A verifiable random function produces a random value together with a proof that the value was generated correctly from a key the producer cannot change after the fact. On a public chain the proof is verified by the contract itself, so nobody has to trust the operator's own records.
Can an operator cheat a provably fair system?
Not by editing a committed result, which is what the scheme is built to prevent. It can still change the odds inside the game, select which unverified rounds to publish, refuse a withdrawal, or simply stop operating. Those failures live outside the proof.
How the scores behind these guides are built
Five weighted criteria, three published caps and a tier ladder. Every total is a seed score you can recompute from the public registry.