The provably fair method
How is a provably fair claim tested?
The register asks whether the documentation lets somebody outside the operator take a server seed, a client seed and a nonce and arrive at the same outcome. 14 operators were checked: 13 were reachable, 11 publish something and 5 are reproducible by a third party. 9 provide a verifier. No score is published on this register.
Documents last checked Reviewed by CryptoGuardz Register Desk, editorial desk
Provably fair is the one claim in this industry that can be settled with arithmetic instead of trust. Either the documentation is specific enough that somebody outside the operator can take a server seed, a client seed and a nonce and arrive at the same outcome, or it is not. This register asks that question of every operator on the casino register and records the answer, collected 2026-09-22.
What goes on the register
Every operator on the casino register, whether or not it claims anything about fairness. An operator that publishes nothing is a row, because the absence is the finding and a register that listed only the operators with documentation would flatter the field it is describing.
1 of the 14 could not be reached at all. Those rows are excluded from every denominator printed anywhere in the section, with the exclusion named on the page. The register did not establish that they publish nothing. It established that nothing could be retrieved, which is a different sentence about a different thing.
What reproducible by a third party required
The field is set true only where the published documentation was sufficient, on its own, for somebody with no access to the operator to recompute a result. In practice that meant all of the following, from pages the operator publishes rather than from a forum post or a support reply.
- The hash construction named, including which value is the key and exactly what string is hashed, in an order a reader can reproduce without guessing.
- The conversion from hash bytes to a game outcome given per game, not described in general terms. A scheme that specifies the bytes and leaves the conversion to the reader produces a different number for every reader.
- The commitment scheme stated: what is published before play, what is revealed after, and what happens to the old server seed when the seed pair rotates.
- A result actually recomputed from those pages and checked against an independently published vector, with the working recorded on the entry.
5 of the 11 publishers meet that standard. Publishing a page about fairness is not the same as publishing a scheme, and 3 of the publishers are recorded as publishing a system a third party cannot recompute from. Coverage is tracked separately: 0 of the 11 publishers document a scheme that covers every game they offer, and the games left out are listed on each entry rather than summarised.
Why an operator-hosted verifier verifies nothing
9 of the 14 operators offer a verification tool. A tool that takes your seeds, sends them to the operator’s server and returns a verdict is asking you to trust the operator’s arithmetic about whether the operator cheated you. It is the same assurance you had before you used it. The only version of the tool that adds anything is one whose computation happens where you can inspect it, or whose source is published so that the computation can be run somewhere else.
2 of the 9 verifiers demonstrably do that. For the rest the documentation does not say where the computation happens, so the field is empty rather than false, and one of those entries is empty because the code block that would have answered it never rendered. Neither of those is a finding that the verifier is server-side.
The register therefore publishes its own verifier at the verifier. It runs in your browser, it shows every intermediate value rather than a verdict, and the arithmetic behind it is asserted against published third-party vectors by a test that runs on every build. If that test fails the build fails, which is the only reason a verifier published by a website is worth more than a verifier published by an operator.
What each field means
| Field | What true records |
|---|---|
| publishes | The operator publishes documentation of a fairness system on its own estate. A marketing sentence asserting that games are provably fair is not documentation and does not count. |
| algorithm_documented | The documentation names the hash function and states the input construction. |
| reproducible_by_third_party | Someone with no account could recompute a result from the documentation alone. |
| preimage_published_before_play | The hashed server seed is shown to the player before bets are placed. |
| rotation_reveals_old_seed | Retiring the seed, or the round ending, reveals the previous unhashed server seed. |
| verifier_runs_client_side | The verification runs on the player's own machine. A verifier that posts the seeds to the operator and receives a verdict verifies nothing, because the party being checked is doing the checking. |
What is not measured
Nothing here establishes that an operator runs the scheme it publishes. A documented scheme and an honest one are different claims, and only the first is checkable from the outside. An operator could publish a perfect specification and seed it dishonestly, and this register would record the specification.
Nothing here measures house edge, return to player, or the fairness of third-party slots and live dealer games, which are the majority of most of these catalogues and are covered by no provably fair scheme anywhere on the register. A bet you verify is one bet: verification says the result matched the committed seeds, not that the game was worth playing.
Why there is no score
There is no score on this register and there is not going to be one until there is something to compute. The fields here are documentary states, not quantities. An operator either published a scheme a third party can recompute or it did not, and averaging that with how many games it covers would produce a number in which a broad but unusable specification outranks a narrow and exact one.
A score is a claim that the things being compared differ along one measured dimension by a stated amount. Nothing in this register supports that claim, so a number here would be a measurement nobody made, dressed as one somebody did. The register publishes the fields instead and lets a reader weigh them, which is the part a single figure removes.
No Review, Rating or AggregateRating markup is emitted on any page in this section either, because none of those describes what is on the page.
How an absent value is written
| Token | What it means | On this register |
|---|---|---|
| Not measured | The measurement is in scope and we have not made it yet. The gap is ours. | Used where a property would require access we do not have, such as whether a published scheme is the scheme being run. |
| Not applicable | The concept does not fit this kind of entity at all. Reserved for a type mismatch, never for a count of zero. | Used where an operator publishes no verifier, so a question about where its verifier runs has no subject. |
| Not disclosed | The company publishes nothing on the point. The gap is theirs and it is a finding about them. | Used where documentation exists and is silent on the point, which is the commonest state on this register. |
| No data | We looked and either nothing exists or nothing would load. The gap is in the record. | Used where a page or a code block would not render on the date recorded. |
Corrections
If an entry about a fairness implementation is wrong, send the primary source that corrects it to the address on the contact page. A correction needs the document, not a request: a link to the clause, the register row or the page that shows the recorded value is not what it was on the date we read it.
Corrections are published with their date at corrections, and the original value stays visible rather than being edited away. A change to what an entry records about a company is logged at the change log on the day it is made. A register whose history can be rewritten quietly is not a register.
Commercial disclosure
CryptoGuardz holds commercial affiliate relationships with 3 of the 24 operators on the casino register, named in full at the disclosure page and named again on every page that carries one of them. Being paid through them is the intended model rather than a description of the current build: no outbound link here carries affiliate tracking yet. Commercial partners appear in this register on the same terms as everybody else, and the entries for them are among the ones recording that nothing could be reproduced. No commercial relationship is an input to anything computed on this site, and the build rejects a data file that tries to set a derived value by hand.
The data
Every row is published as a CSV with its columns and its known gaps at the data page. The register itself is at the implementations register, and the counts drawn from it are at the findings.