Rebuilt verifiers for dozens of casinos and 13 game types: enter server seed, client seed and nonce to recompute the exact committed result.
One verifier page per casino, covering every original game we have reverse-engineered for that operator.
Replay a whole session from a revealed seed pair, settled against the real paytables.
Analysis of each operator's in-house originals: the published provably fair construction, independent verifiability and declared house edges. Snapshot 2026-08-18; rubric documented on each report page.
| Casino | Fairness score | Verifiable | Construction |
|---|---|---|---|
| Stake | 10/10 | yes | HMAC-SHA256 · serverSeed as key · message "clientSeed:nonce:round" · 4-byte floats |
| Shuffle | 9.5/10 | yes | HMAC-SHA256 seed pair (Stake engine) · RNG additionally certified by iTech Labs |
| BC.GAME | 9/10 | yes | Mixed: plain SHA-256 (dice family) · HMAC-SHA256 (Mines/Keno/Wheel) · 10M-value SHA-256 hash chain (Crash) |
| Gamdom | 9/10 | yes | SHA-256 hash chain per game (1M–10M rounds) · public salt from a real Bitcoin block hash |
| Thrill | 9/10 | yes | HMAC-SHA512 seed pair (documented) — not the Stake-family SHA-256 |
| Duelbits | 8.5/10 | yes | SHA-256-based seed pair (server seed committed, client seed settable, per-bet nonce) · Dice Duels adds an EOS block id |
| Rollbit | 8/10 | yes | Dual model: SHA-256 hash chain (legacy: X-Roulette, X-Crash) + ECVRF SECP256K1_SHA256_TAI (2024: Mines, Plinko, X-Flip, Rollbot Bonanza, Lootboxes) |
| Rainbet | 7.5/10 | yes | HMAC-SHA256 seed pair (Stake-style; not officially documented per game) |
| Duel | 7.5/10 | yes | HMAC-SHA512 · 52-bit doubles · cursor per event (extracted from the client bundle) |
| 500 Casino | 7/10 | yes | Commit-reveal seed pairs, per-game fairness pages (exact construction not extracted) |
| BetFury | 7/10 | yes | SHA-256 commitment: hash(random result + server seed) published pre-bet, revealed after |
| Roobet | 6.5/10 | yes | HMAC-SHA256 seed pair (Stake-like), per roobet.com/fair |
Provably fair is a commitment scheme, not a trust badge. Before your bet the casino publishes the hash of a secret server seed; you contribute a client seed; the outcome is derived from both plus an incrementing nonce. When the server seed is later revealed, you can hash it to confirm it matches the earlier commitment and recompute every result it produced.
The important consequence: the casino cannot pick an outcome after seeing your bet, because doing so would require a server seed that no longer matches the hash it already published. That is the whole guarantee — and it is a real one, unlike an RNG certificate you have to take on faith.
A verifier hosted by the casino asks you to trust the same party you are checking. We reimplemented the algorithms independently — HMAC-SHA256 and SHA-512 constructions, per-game float extraction and the game-specific mapping from bytes to outcome — so the recomputation happens outside the operator’s control.
Coverage differs by operator, and we label it: verified means we confirmed the construction against real revealed seeds, extracted means we recovered it from the platform’s own client code, assumed means we are applying the standard construction without a confirmation. Where we are assuming, we say so rather than implying certainty.
Provably fair proves an individual round was not tampered with after the fact. It does not prove the house edge is low, that the RTP build you are playing is the standard one, or that the operator will pay you — those are separate questions we measure separately.
It also cannot help if you never check. The system is only as good as the verification, which is why per-game verifiers exist here for thirteen game types rather than a single generic form.
Not on an individual verified round. It can still choose a high house edge, serve a lower RTP build of a third-party slot, or handle withdrawals badly — none of which the seed commitment addresses.
It is your half of the input. Without client-seed control the operator could in principle choose both inputs; contributing your own removes that possibility. Rotating the server seed matters for the same reason in reverse.
Yes: the revealed server seed, the client seed and the nonce of the round. Casinos expose these in bet history once a seed pair is rotated.