How the commit-and-reveal model works
The basic idea is a commitment made before play. The operator commits to a hidden server seed by showing its hash. The player side contributes a client seed, while a nonce distinguishes one bet from the next. After a seed is retired or revealed, the original server seed can be hashed again and used with the other inputs to reproduce the supported result.
If the revealed server seed does not match the earlier commitment, or the calculated outcome does not match the game history, the check fails. If they match, the test supports the integrity of that specific calculation. It says nothing about whether the stake was sensible.
Server seed, client seed and nonce in plain English
| Term | Role | Common mistake |
|---|---|---|
| Server seed hash | Commitment shown before the original seed is revealed | Pasting the hash where a verifier expects the revealed seed |
| Server seed | Hidden operator input revealed after rotation | Sharing an active secret before it is retired |
| Client seed | Player-side input used by the calculation | Using the wrong client seed for an older round |
| Nonce | Counter that separates bets under the same seed pair | Being off by one or using the session count |
| Game algorithm | Maps the cryptographic output to a game result | Using a verifier built for another operator or game |
A careful verification workflow
- Open the supported game's fairness information before play and record the displayed server-seed hash, client seed and current nonce.
- After the relevant seed is retired, obtain the revealed server seed and keep the matching game-history entry.
- Hash the revealed server seed and compare it with the commitment recorded earlier.
- Use a verifier that explicitly supports the same Roobet game and implementation.
- Enter the matching client seed and nonce, then compare the calculated output with the recorded result.
Independent verifier documentation notes that Roobet games do not all share one output mapping and that a generic verifier can produce a mismatch even when the inputs are correct. That is why a game-specific implementation matters.
What a successful check proves—and what it does not
It can support
The committed seed matches the revealed seed and the disclosed inputs reproduce a completed supported result.
It cannot support
That the next round will win, that every casino product uses the method, or that account and withdrawal decisions are fair.
Provably fair concerns calculation integrity. Licensing, game availability, KYC, payment processing, account security and responsible gambling are separate questions. A mathematically valid losing result remains a loss.
Why a verifier can show the wrong result
- The server-seed hash was entered instead of the revealed server seed.
- The client seed or nonce belongs to another round.
- The verifier uses another operator's message format.
- The selected game uses a different mapping from the one being checked.
- Whitespace, capitalization or copy-and-paste errors changed an input.
- The game uses a shared-seed flow rather than a personal seed pair.
A mismatch deserves a second careful check, not an immediate claim of fraud. Preserve the original game record, seed commitment and timestamp. Then ask official support or a technically qualified reviewer to reproduce the calculation.
Treat active seeds as account data
Do not paste an active unrevealed secret or account credentials into an unknown website. Prefer a verifier whose code and data handling you understand. An independent tool saying that calculations run locally in the browser is useful, but it is still worth checking its current implementation and privacy behavior.