Twenty-one claims in a hundred, none of them verified here
What a provably fair check actually proves, and the five steps that produce it
Twenty-one of the hundred operators in this library advertise a published fairness scheme, four of them among the twelve rows here. Zero verifier pages have been opened for this index, so what follows is the shape of the check and not a report on anybody's implementation.
A fairness scheme is the one claim in this trade that a reader can test without trusting anybody, which makes it worth understanding precisely and worth over-claiming not at all.
The four parts a scheme has to have
Strip the marketing away and the construction the term refers to needs four components. Any scheme missing one of them cannot be checked, whatever it is called.
A commitment made before play. The operator publishes a hash of a server seed. A hash is a one-way summary: the string can be published without revealing the seed, and the seed cannot be changed later without the hash failing to match.
An input the player controls. A client seed, which the player sets and can change. Without it, the operator alone determines everything and the commitment secures nothing useful.
A counter. A nonce, incrementing with each round, so that the same pair of seeds produces a different result every time.
A revelation. A way to make the operator disclose the server seed it committed to — normally by rotating to a new one, which retires the old seed and publishes it.
Add a published, deterministic function that turns the three inputs into an outcome, and the system is checkable. Take away the fourth part and it is a promise.
The five steps, in order
Before the round matters. Almost every failed attempt at this check fails because the first step was skipped.
One. Copy the hashed server seed the operator shows before play, and set your own client seed rather than accepting a generated one. Keep both somewhere outside the account.
Two. Play, and note the nonce of the round you want to check.
Three. Rotate the seed. This is the step that costs something: it ends the current sequence, and it is what forces the server seed into the open.
Four. Take the revealed server seed and hash it with SHA-256, using any hashing utility. Compare the result with the string you copied in step one, character for character. If they match, the operator is holding the same seed it committed to before the bet.
Five. Run the operator's published function on the server seed, the client seed and the nonce, and compare the result with the outcome that was paid.
Steps four and five answer different questions. Four asks whether the commitment held. Five asks whether the published rule was applied. A scheme can pass one and fail the other, and only running both settles anything.
What the check settles, and what it leaves alone
It settles that a result was fixed in advance of the stake. That is a real property and it removes one specific way of cheating: choosing an outcome once the bet size is known.
The list of things it does not touch is longer, and every item on it belongs in the open.
It says nothing about the house edge. A game can be provably fair and pay badly, and the two facts are unrelated. It says nothing about rounds played on a seed that has not yet been revealed, because until rotation there is nothing to verify against. It covers games the operator wrote itself and not slots licensed from a studio, which is most of a lobby. It does not reach a sportsbook at all.
And it has no bearing on whether a balance is paid. That is decided by a verification clause and a withdrawal clause, in a different document, and for this operator the relevant one is clause 4.8, which reserves the right to demand documents at any time and to restrict payment until identity is sufficiently determined. What that clause does and does not contain is set out on the verification clause.
A verified round and an unpaid balance are entirely compatible.
What this index actually holds
Twenty-one of the hundred operators in the library advertise a published fairness scheme on their own pages, recorded on 26 August 2026. Four of the twelve rows compared here are among them: Stake, Shuffle, BC.Game and Cloudbet.
That figure counts an assertion, not an implementation. No fairness page has been opened for any row on this index, no verifier has been run, and no round has been checked, because that would require an account and a stake and this desk holds neither.
So the four names above tell a reader where to look and nothing about what they will find when they get there.
The honest way to use this article is as a checklist to take to the operator's own fairness page: does it publish a hash before play, does it let the client seed be set, does it expose the nonce, does rotation reveal the old seed, and is the function written out. Five yeses make a scheme checkable. Four make it a claim.
Why the claim is common and the check is rare
Publishing the words is cheap; publishing a working verifier with the function written out is not, and rotating a seed to test one costs a player the sequence they are on.
That asymmetry is why 21 operators advertise the property and why this index scores none of them on it. A claim recorded from a marketing page sits in the same category as a game count or a loyalty tier: useful as a description, worthless as evidence, and never allowed to lift a row.
The part of a lobby that a scheme like this applies to — the games an operator writes rather than rents — is set out on the in-house games. What four documents can and cannot establish about an operator is worked through on the four questions inside one word.