Provably fair explained: what the proof covers

Twenty-one of the hundred operator records in our library describe their own games as verifiable. That is the honest size of the category: twenty-one claims recorded from site text, with a reading date attached, and not one audit among them. The mechanism behind the claim is genuinely elegant and can be explained without a single number, which is what this page does first. Then it does the harder part, which is saying what a provably fair commitment does not cover — and in our files the uncovered part is where nearly all the money wording lives.

What a provably fair claim is a claim about

Our operator records carry a short tag list taken from how the site describes itself. One of the tags is provably-fair, and twenty-one of a hundred records have it. Fourteen records carry crypto-only, twelve carry instant-withdrawal, twenty carry original-games, forty-seven carry live-dealer.

The tag is a record of a claim, not a test of one. We did not verify a round for this page. We did not open an account, we did not hash a seed, and we have no ledger of outcomes. What we have is a note that on a given reading day the site said this about itself, which is a modest fact and worth keeping modest. Anyone writing that a site “is provably fair” when they mean “says it is” has already lost the distinction this page is about.

Eight of the twenty-one also carry crypto-only: BC.Game, Flush, LTC Casino, Metaspins, bspin, Primedice, Wolf.bet and JacksClub. Ten of the twenty-one also carry instant-withdrawal: Bitsler, Flush, KatsuBet, LTC Casino, Rakebit, Shuffle, Wild.io, bspin, DuckDice and Wolf.bet. Those overlaps are not evidence of anything on their own; they are the shape of how these sites describe themselves, and the shape is useful when you are trying to work out which claims travel together.

The commitment, step by step, in letters

Four moves, no arithmetic required.

1. Commit. Before the round, the operator generates a secret value — conventionally the server seed — and publishes a hash of it. A hash is a one-way summary: trivial to compute forwards, impractical to reverse, and different for any change to the input, however small.
2. Contribute. The player supplies or is assigned a second value, the client seed, which the operator did not know when it published the hash.
3. Derive. The outcome is computed from the two seeds combined, together with a round counter, by a rule the site states in advance.
4. Reveal. Afterwards the operator publishes the server seed. Anyone can hash it and compare against the commitment from step one, then re-run the stated rule and confirm the outcome follows.

The logic is a lock with two keys turned in sequence. The commitment fixes the operator’s half before it can see the stake. The client seed stops the operator from having pre-computed a convenient outcome for that particular player. The reveal makes the pair checkable after the fact. Nothing in the scheme requires trusting the operator’s honesty in the moment; it requires only that hashing cannot be reversed, which is the assumption the whole construction rests on. The round it usually wraps is described in the crash round this commitment is usually wrapped around.

It is worth noticing what is not in those four steps. There is no statement of how likely each outcome is. The rule in step three can map two seeds onto any distribution its author chooses, and the commitment will verify perfectly either way. A provably fair round is a round whose result was fixed in advance and can be reproduced. That is all four steps promise, and it is a real promise — it just is not the promise most readers assume.

What a verified round actually rules out

Three specific frauds, and they are worth naming because they are the ones the scheme was built against.

A provably fair commitment rules out choosing the outcome after seeing the stake. If the server seed was committed before the betting window closed, it cannot have been swapped for one that produces a worse result for a large stake. It rules out choosing the outcome per player. The client seed is an input the operator did not control, so a result tailored to one account cannot have been pre-computed. And it rules out retroactive editing of the result, because the published hash pins the seed and any altered seed hashes differently.

Those three are the classic attacks, and a working commitment scheme closes all three. If a site publishes a commitment, publishes the reveal, and states its derivation rule, a player can check a specific round without trusting anybody’s word about that round.

Here is where the usefulness stops, though. Checking one round tells you about one round. To say anything about the game as a whole you need many rounds, a record of them, and a statistical test — and at that point you are no longer relying on the commitment at all, you are doing an audit. We have not done one. Nothing on this site reports the results of such a test, for any operator, because no such test is in our files. A dice roll built on the identical pair is walked through in a dice roll derived from the same seed pair.

Four things the proof does not cover

The margin. The derivation rule can be weighted however its author likes. A round can verify perfectly and still come from a game with a far larger house edge than the site’s marketing implies. Our files contain no return-to-player figure for any game from any studio, so we cannot tell you any site’s real margin, and we will not print a figure we did not read.

The distribution. A single verified outcome says nothing about how often each outcome occurs. Verification is per-round; fairness in the sense most people mean is per-thousand-rounds.

The stated rule itself. Verification confirms the result matches the published rule. It does not confirm the published rule is the one the server ran for players who never check, and it does not confirm the rule is favourable. Reproducibility and fairness are different properties that happen to share a marketing word.

Getting the balance out. This is the big one, and it is the reason a provably fair tag should never be read as a payout assurance. Of the twenty-one tagged records, nineteen also carry verification wording taken from the operator’s own terms — documents may be requested, at the operator’s discretion, before a payout. Not one of the twenty-one states a monetary figure at which that happens. Shuffle’s clause 4.1 describes a risk-based threshold and gives no amount. Primedice states every account is suspended once a risk-based withdrawal threshold is reached and does not say what the threshold is. Windice’s clause 15.1 reserves documents at any time with no figure. Wolf.bet requires verification before a payout and notes that large withdrawals require it, again without a figure. Those clauses are counted in the discretion clause sitting behind nineteen of these twenty-one records.

Where the tag is missing, and what that does not mean

Seventy-nine records do not carry the tag, and the temptation is to read that as seventy-nine sites that hide their arithmetic. The temptation should be resisted, because the reason differs record by record and our files say which.

Twenty-one records are empty end to end: retrieval is marked “none”, so no tag list, licence, clause or coin list could be read for them at all. In those cases the absence of a provably fair tag carries exactly no information, because the absence of everything else carries none either. Another large group had pages read but described themselves in other terms — forty-three records carry sportsbook, thirty-seven carry vip-program — and a site that leads with sports or a loyalty scheme simply may not have put the word on the page we read.

The opposite trap also exists. Eight records carry original-games without the verifiability tag: BetFury, BitStarz, Bitcasino.io, Rocketpot, TrustDice, Fairspin, Sol Casino and Punt Casino. All eight describe in-house games; none of the eight described them as checkable in the text we read. That combination is the one worth noticing, because in-house games are precisely where a commitment scheme would apply, and here the claim is available to make and was not made.

So the census has three states rather than two: claimed, not claimed on a page we read, and nothing read. Collapsing the last two into one column is how a comparison table turns twenty-one into an implied verdict on seventy-nine.

The tag next to the licence field

Reading the twenty-one tagged records against their licence entries produces a wider spread than the shared tag suggests.

Ratings among the tagged records run from 3.5 to 8.5, and three carry no rating at all because fewer than three components could be scored. The tag is constant across all of them; nothing else is. BC.Game’s Curaçao entry reads Revoked while its domain also appears in the Anjouan register as valid under a different company name, Twocent Technology Limited. Mega Dice has no licence field filled at all, and also happens to be one of only two records in the entire library that earn the point for demanding no verification at signup. What a register entry can and cannot settle is set out in what a register entry can confirm that a hash cannot.

How the formula treats the claim: it does not

Our rating file has seven components and none of them is verifiability. Licence takes 2.5, verification clarity 2.0, publishing a country list 1.5, coin coverage 1.5, reach 1.5, no verification at signup 1.0, provider breadth 1.0 — and provider breadth is marked unscored, so it contributes nothing. A record needs at least three scorable components before it gets a number at all, which is why fifty-three of a hundred records carry null rather than a low score.

Leaving verifiability out was deliberate and the reason is the one this whole page turns on: the tag records a claim we cannot check from a document. A licence number can be looked up in a register. A clause number can be found in terms. A coin list can be counted. A provably fair assertion can only be checked by playing rounds and hashing seeds, which is not what we do, so scoring it would smuggle an unverified claim into a number that is otherwise traceable field by field.

That is also why you will not find a “fairness score” anywhere on this site. The formula’s components are printed with their arithmetic so any figure can be traced back to a field. A component with nothing behind it would break that property for every record that carried it. The resulting table is top no KYC casinos scored from licences and clauses, not from claims.

Checking a claim yourself, without a number from us

Five questions, each answerable from a site’s own pages, in the order that gets to an answer fastest.

• Is the commitment published before the round, and is it visible without an account? A scheme whose hash only appears afterwards has skipped the only step that mattered.
• Is the derivation rule written down, in enough detail to re-run? “Uses SHA-256” is not a rule; a rule states the inputs, their order and the mapping to an outcome.
• Can the client seed be set or rotated by the player? If the operator supplies both seeds, the second key is not being turned.
• Is there a verifier, and does it accept seeds you paste in rather than only ones the site pulls from its own history? The second kind checks nothing.
• Does the same page say anything about the margin? Almost none do, and the silence is the point: the commitment and the margin are separate facts and only one of them is being published.

And then the question the scheme cannot answer, which belongs in a different document entirely: what does the terms page say about documents before a payout, what cap applies, and how many days does the operator give itself? Nineteen of the twenty-one tagged records answer the first part with discretion and no figure. Fourteen records across the whole library publish a cap. Those answers are in the terms, next to a clause number, and they are checkable in a way a provably fair claim is not.