Fairness policy
Rust Snowball uses HMAC-SHA256 commit-reveal RNG across every game. The verifier code is open source on GitHub — any past round is independently reproducible. Disclosed house edges equal the real Monte-Carlo edge, asserted in CI. This page is the binding operator commitment to those properties.
Provably-fair commit-reveal
Every game on Rust Snowball uses HMAC-SHA256(serverSeed, message) for its RNG. Before each round:
- Server picks a random 32-byte server seed.
- SHA-256 of that seed is published as the round commitment.
- Player can set their own client seed (or use an auto-generated one).
- Nonce auto-increments per round.
After the round resolves, the raw server seed is revealed, so anyone can re-derive:
HMAC-SHA256(serverSeed, `${clientSeed}:${nonce}` + gameSalt)and confirm the published outcome matches their own derivation. See the verifier page for the interactive tool.
Open-source verifier
The verifier library — @rustsnowball/provably-fair on npm, and on GitHub — is the same code the production engine imports. There is no separate “public verifier” vs “real engine” split. What you re-derive locally is exactly what the engine computed.
Disclosed edge = real edge
For every game, we publish the house edge openly (on /provably-fair, in the in-game rules panel, in each game's structured data, and on the respective game pages).
That published edge is asserted in CI to equal the Monte-Carlo edge of the actual engine code path. Drift fails the build. Concretely, the assertion scripts are:
pnpm --filter @rustsnowball/provably-fair verify:blackjack-rtppnpm --filter @rustsnowball/provably-fair verify:keno-rtppnpm --filter @rustsnowball/provably-fair verify:crash-rtp
Each script runs millions of synthetic rounds through the engine, measures the realised edge, and compares against the disclosed number. The CI badge on the repo reflects the current pass/fail state.
Seed rotation
Server seeds rotate per round (a fresh seed per round). Client seeds can be rotated by the player at any time via account settings. Nonces auto-increment per (player, game) pair.
The chain of commitments + reveals means an operator cannot alter a published outcome after the fact, AND cannot pre-target a specific player's round, AND cannot lie about a past round even if all records were destroyed (because the player has the seed reveal in their own browser history).
Anti-manipulation safeguards
- Crash: fail-closed payout-multiplier guard hard-clamps any payout above the disclosed 50x real cap and alerts ops.
- Mines / Towers / Blackjack: active-round seeds mirrored in Redis vault with 7-day TTL; missing-vault rounds page admin inbox rather than auto-refund (closes walk-away free-option exploit).
- Bot inventory pricing: consensus pricing across multiple sources with upside + downside clamps to prevent single-source manipulation of deposit / withdrawal values.
- Case battles: drop-pool hash bound to seed commit — case contents cannot be silently swapped mid-battle.
If you suspect unfairness
Use the verifier against the seed + nonce of any round in your history. If the verifier and our published outcome disagree, email [email protected] with the round ID — we treat any verifier mismatch as a critical incident.