How provably fair works
Before you play, the casino generates a server seed and shows you its cryptographic hash. You supply or accept a client seed, and a nonce increments with each round. The outcome is derived by combining all three through a hash function.
Because the server seed was committed to as a hash before the round, the operator cannot change it afterwards without breaking the hash. When you rotate your seed, the previous server seed is revealed and you can recompute every round it produced and compare against the results you saw.
That is the whole guarantee: not that the game is generous, but that the outcome was fixed before you bet and was not manipulated in response to your wager.
Verifying a round step by step
- Open the fairness panel and copy the hashed server seed shown before play.
- Set your own client seed rather than accepting the default, so the input is demonstrably not operator-controlled.
- Play a series of rounds, noting the nonce for at least one of them.
- Rotate the seed pair, which reveals the unhashed server seed.
- Hash the revealed server seed and confirm it matches the commitment you copied earlier.
- Run the seed, client seed and nonce through the published algorithm — or a third-party verifier — and confirm the outcome matches what you were shown.
What provably fair does not prove
It does not prove the house edge is low. A verifiably random Dice game with a 5% edge is still a 5% edge. Check the stated RTP separately.
It does not cover third-party slots. Studio games run on the provider's own RNG, certified by a testing lab rather than verified by you. A crypto casino can be provably fair on originals and conventionally certified on everything else.
It also does not guarantee you get paid. Fairness is about outcomes; solvency and payout policy are separate questions that come down to operator reputation.
Which casinos implement it properly
The strongest implementations expose the full toolset: seed rotation on demand, a public algorithm, and an in-browser verifier that accepts pasted values. BC.Game and Stake both meet that bar across their originals, and LuckyHash builds its whole interface around hash verification.
Weaker implementations show a badge and a hash but no way to rotate seeds or recompute results. If you cannot complete the verification steps above, the claim is decorative.
Fairness, RTP and wagering requirements together
Read the three numbers as a set. A provably fair game with published RTP and a bonus carrying a reasonable wagering requirement is a transparent product. Any one of the three missing should lower your confidence in the other two.
In practice, operators that invest in real fairness tooling also tend to publish clearer bonus terms, because both come from the same commitment to being checkable.