Photo: Terry Vlisidis / Unsplash

What each operator actually publishes

One row per operator: the scheme it documents, the games the scheme covers, the games it leaves out, whether a third party could reproduce a result from the documentation alone, and the URL we read with the date we read it.

14 operators11 publish5 reproducible0 cover every gameread 2026-09-22

Reproducible: Someone with no account could recompute a result from the documentation alone. Runs on your machine: 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.

The two rows worth reading twice

Sportsbet.io publishes the best fairness documentation on the register

It is not the operator most players would name, and it is one of only two on the register, with Gamdom, that publishes a verifier we could confirm runs on the player’s own machine. The help centre article gives the whole chain rather than a summary of it: the commitment as SHA256 of the server seed published before the round, HMAC-SHA256 keyed by the server seed over clientSeed:nonce, SHA-256 of that HMAC used as a ChaCha20 key, the first twelve bytes of the HMAC as the 96 bit nonce, rejection sampling for bounded draws, Fisher-Yates for decks, and a second commitment for card games as SHA256 of the initial shuffle concatenated with the server seed. It then prints working source and states The verifier below is standalone, it depends only on the Node.js crypto module and reproduces the random draws exactly.

The detail that gives it away is the warning: the page flags the ChaCha20 initialisation vector convention that would otherwise make an independent implementation silently disagree. That sentence is written by someone who expects a reader to actually build the thing. Six games are in scope and the rest of the casino is not, which is the same limit everybody else has, stated more plainly.

Wild.io shows what a verifier that proves nothing looks like

Wild.io claims coverage of 20 Originals, second only to Stake on this register, and publishes one of the thinnest specifications against it. No hash function is named anywhere on the page. The mechanism is described only as two seeds, one hashed before play and revealed afterwards, which is the shape of the scheme without any of the content, so nobody outside the company can recompute a result. There is no dedicated fairness page at all: this is a games category page.

The instruction it gives the player is the exact failure: Go to Fairness, then Verify and input: Client Seed, Original Server Seed, Round ID. The tool instantly confirms the outcome. An instant confirmation from the party being checked verifies nothing. The player learns that the operator says the operator was honest, which is what they had before they opened the tool. The same doubt applies more weakly to Stake and Shuffle, whose calculators are good but whose pages never say where the arithmetic happens, and it is cheap to fix: one sentence.

The operators that cannot be verified, and why

• Winz.io. Publishes nothing. The URL that looks like documentation is a game lobby listing titles, and the operator’s own support answer confirms it: asked whether it provides provably fair games it replies Yes, you can find the list of Provably fair games in the relevant section and points back at the lobby. A list of game titles is a claim about which games qualify, not a system anyone can check.
• Rakebit. Publishes nothing. The home page says Fairness is verifiable, not promised. Every Rakebit Original runs on provably fair algorithms, so any player can independently confirm that a result was not manipulated after the bet was placed, and no fairness page exists behind it. Six candidate paths and the sitemap were tried. The sentence promising that fairness is not a promise is, on the evidence, a promise.
• Wild.io, Cloudbet and BetFury. Publish a system that cannot be recomputed from. Cloudbet names SHA3-256 and SHAKE256 and stops before the message construction. BetFury names SHA256 and never says what goes into it. Wild.io names no primitive at all.
• Flush. Explains the commitment carefully in plain English and calls the primitive a mathematical function called a hash function. It also claims to publish its code so a reader can build their own tool. We could not render that code block, so reproducibility is recorded as not established rather than credited.
• Thunderpick. Reproducible, and narrow on purpose. One equation, SHA256(Salt + Random) = Hash, with a worked example, covering Roulette and nothing else, not even its own Originals suite. It provides no verifier of its own and tells the player to use any SHA256 calculator, which is the honest answer when the scheme is that simple.

Where a scheme cannot be checked with our verifier

The schemes are not interchangeable, and several operators would fail a Stake-style verifier while being entirely honest. BC.GAME Classic Dice is plain SHA-256 over server_seed:client_seed:nonce, not an HMAC. BC.GAME Crash and Gamdom both run reverse SHA-256 hash chains committed in advance, with no client seed at all. Thunderpick hashes a salt against the winning number. Cloudbet is on SHA-3. Even among the HMAC-SHA256 operators the conversions differ, so Stake and Shuffle give different limbo multipliers from the same seeds. Any tool that reports a mismatch without first establishing which scheme the operator documents is manufacturing an accusation out of an assumption. Ours says so on its own page.

Coverage, operator by operator

What we could not retrieve

Two of those, Jackbit and Roobet, are the same two documents that resist retrieval elsewhere on this site. Each is a gap on one date, not a finding, and each should be closed by hand.

Notes on every row

The full note recorded against each operator when the documentation was read on 2026-09-22.

Related: the findings · the verifier · the casino register · method