The proof of a single hand
How to verify provably fair: what the proof covers and what it does not
A method that lets you see, by your own calculation, that the result was not altered afterwards. Its force is real and its reach is narrow: it shows the integrity of one hand, not the payout, the house edge or the licence.
Provably fair is an arrangement that lets you work out for yourself that the result of an online game was not chosen after your bet. Before starting the hand, the house commits to a secret number and publishes a digest of that commitment. Once the hand is over it reveals the number, and you check that the digest matches and that the result comes out of the same inputs.
The diagram below separates the inside of the proof from the outside. The sections that follow set the method out step by step, list the six subjects the proof does not cover, and give what the operators write about it on their own pages, with the date each was read.
The provably fair arrangement has four parts
The logic of the method rests on a rule of order: the house commits to a number before it knows what you will do, and cannot go back on that commitment afterwards. Four parts make that work.
The server seed. The secret number the server generates. It is not revealed before the game starts, because if it were the result could be worked out in advance.
The hash. A digest of the server seed put through a one-way function. The digest is easily computed from the number, and the number cannot be recovered from the digest. The house publishes that digest before the game, so it has committed to a number without yet showing it.
The client seed. A number the player supplies or can change. Because it also goes into the calculation that produces the result, the house cannot determine the result on its own.
The nonce. A counter that goes up by one on every hand. A hundred hands played with the same two seeds are told apart by that counter alone, and each gives a different result.
The result comes out of a formula in which those three inputs — the server seed, the client seed and the nonce — are processed together. The formula itself should be written on the operator's verification page; without it, you cannot rebuild the calculation.
Verification step by step
Actually doing the verification once, on a small hand, teaches more than reading about how the method works. The steps are these:
- Record the hash. Before you start playing, copy the server seed hash shown on screen and paste it somewhere.
- Set your client seed. Enter a value yourself or note the one on screen.
- Note the nonce. Write down the counter value of the hand you want to verify.
- Change the seed. Close the session or refresh the server seed; the server then reveals the old seed.
- Compare the hash. Put the revealed seed through a hash tool and compare it character by character with the digest you recorded at step one.
- Recompute the result. Put the three inputs into the formula on the verification page and compare what comes out with what you saw on screen.
If the two digests are identical at step five, the house was committed to that seed before the game. If the result matches at step six, that hand was produced from those inputs. If either step fails to match, keep the screenshots and the values and ask the support team in writing. All of this can be done in the browser without installing anything; the real force of the proof lies in its being doable without asking anyone.
The six subjects the proof does not cover
What the method proves is single and clear: the result of that hand was not altered once the hand had begun. Everything outside that is the business of another document and another check.
- The house edge. How much the game earns the house in the long run is a design decision independent of whether the result can be verified. A verifiable game can still favour the house.
- Payment. It says nothing about when the money you won can be withdrawn or in what pieces; those are the business of the period-cap and instalment clauses, set out in detail on the page describing the withdrawal rules.
- The account. Documents being asked for, the account being suspended or being closed hang on separate clauses; the page comparing the identity clauses lists them.
- Third-party games. In slots and live-dealer tables that come from a provider, the result arises not on the casino's own server but in the provider's system; in those games what you rest on is the provider's testing and certification regime.
- The licence and the register. The diagram just above shows that licence information is read through a separate register search; the checks on the number, the holder and the domain are in the steps of a register search.
- The long-run outcome. Every hand being honest on its own does not mean you will be in profit when you add the hands up.
In short, the method is not an assurance of payment but a tool for testing the integrity of a single hand. Keeping that distinction in mind sets your expectations correctly when you come across a site's verification page.
Common mistakes in verification
The method itself is simple, but a few small lapses can make the proof worthless. The commonest are these:
- Recording the hash afterwards. A hash you did not see before the game shows a commitment to nothing. You have to have copied the digest before the first bet.
- Trying to verify the active seed. A server seed in use is not revealed. You have to change the seed first and wait for the old one to be revealed.
- Muddling the counter. When the seed changes, the counter starts again from the beginning in most arrangements. Note together which seed pair and which counter the hand you want to verify belongs to.
- Converting the result wrongly. The raw number the calculation produces is converted into a different form in every game: a dice value, a multiplier or a card. If the game's conversion rule is not written on the verification page, you cannot match the raw number to the result on screen.
- Never looking at the client seed. The default value goes into the calculation too, but entering your own makes it plainer that the house could not have staged the result in advance.
None of these is a weakness of the method; they all come from keeping an incomplete record. Keeping the values as screenshots, with the date, means you have a concrete record if you later see something that does not add up.
The difference between proof and assurance
A verifiable hand is no reference for anything else the operator says. A site's verification page can work flawlessly while the same site's identity clause still gives no amount and its licence entry still points at a different domain. So the method should not be read as a quality label.
Its value should not be belittled either. Most promises in this business consist of sentences the reader cannot check; this method is one of the rare tools you can test in your own browser without asking anyone. Its proper place is this: it hands you a measure of the honesty of a single hand in the game, and for everything else you still have to read the terms and the register separately.
What the operators write on their own pages
The operators in the ranking do not state their position on this in the same detail. What follows was read from the operators' own pages on 2 September 2026 and is reported as the operator's statement.
Rainbet writes in the frequently asked questions section of its home page that its own games work on this logic. For Case Battles and EOS Roulette it states that it uses a different source: in those two games the randomness is taken from block data on the EOS blockchain. That is a different design; the server has no secret seed, and the result is derived from an event anyone can see. Even so, which block data the result is drawn from and under which rule depends on the operator's description, and you still have to see by calculation that the description is correctly applied.
Bitsler writes on its home page that all its games work on this technology. The same page also promotes third-party slots and live tables; because the results of those games are not produced on the operator's server, the statement cannot cover them. We report the statement as it stands and write its limit beside it.
Bitcasino.io describes another kind of assurance in cl. 14 of its terms: testing of the random number generator and external compliance testing. That is an assurance resting on an independent laboratory's report, not a proof the player can recompute alone. The two approaches do not stand in for each other; they answer different questions.
What to look at on a provably fair screen
It is not enough that a site mentions the method; you have to be able to do the check yourself. Going through the list below once shows whether the screen really works:
- Is the hash visible before the bet? The server seed hash should be on screen before play begins.
- Can the client seed be changed? Being able to enter the value yourself is the assurance that the house cannot determine the result on its own.
- Is the nonce visible on every hand? If the counter is not visible, verifying a particular hand becomes harder.
- Is there a seed-change tool? The old seed being revealed depends on that tool.
- Is the formula written down? To recompute the result, the formula has to appear plainly on the verification page.
- Which games are covered? The operator's own games, or the whole catalogue? Slots and live tables are usually outside the scope.
Once you have worked through that list, check the subjects the method does not cover separately. The identity clause, the licence entry and the withdrawal cap of twelve operators stand side by side in the list where the files are gathered. For short definitions of terms such as server seed, nonce and hash, see the glossary.