On-chain games can’t “just roll a die.” Every node must reach the same result, which conflicts with the idea of unpredictability. Getting randomness wrong creates edge cases, exploit windows, or outright bias—unacceptable for casino-grade play.
What “random” means on a blockchain
Randomness has three jobs: unpredictability before the spin, unbiasability during the spin, and verifiability after the spin. If any leg fails, players or operators can be harmed. The chain’s determinism makes native randomness tricky by design.
Block data feels tempting, but miners/validators can nudge it. Off-chain servers can draw fair numbers, but you must trust them. The goal is to minimize trust and expose proofs that any player can audit later.
Core terms in plain English
An oracle is a bridge that delivers off-chain data to smart contracts. For RNG, it transports randomness plus evidence of correctness. A VRF (verifiable random function) produces a random-looking number and a proof that the number truly came from a secret key and the request.
Commit–reveal is a two-step pattern: someone commits to a hidden value, then reveals it later. It avoids last-second cherry-picking, but timing and griefing risks remain if not designed carefully.
Approaches and trade-offs
Start by mapping your risk tolerance and latency budget. Pure on-chain tricks are fast but weak; external VRF is slower but robust. Hybrid models can add liveness and dispute paths.
| Method | Unpredictable | Unbiasable | Verifiable | Latency | Notes |
|---|---|---|---|---|---|
| Blockhash/slot data | Low | Low | Public | Near-zero | Cheap; miner/validator influence risk |
| Commit–reveal | Medium | Medium | Public | 1–2 blocks+ | Prone to no-reveal griefing |
| Oracle VRF | High | High | Cryptographic proof | Moderate | Good default for fair draws |
| Threshold VRF | High | High | Group proof | Moderate | No single oracle key holder |
Commit–reveal gotchas
If a player benefits from withholding a reveal, they will. Add penalties or escrow that auto-slash on missed reveals. That turns griefing into a cost, not a free option.
Also watch for last-look advantages. If multiple parties reveal, order should not let the final revealer decide after seeing others. Use fixed windows and aggregate reveals before deriving the final seed.
Oracle/VRF design tips
Treat the oracle as part of your consensus, not a “helper.” Rotate keys on a schedule, monitor proof verification gas, and expose events that wallets and dashboards can read without decoding byte arrays.
Define clear liveness rules. If a VRF response misses a deadline, fail safe and refund, or fall back to a secondary source with a recorded flag. Players should never wonder whether a draw is pending or abandoned.
VRF in practice: realism and limits
VRF gives you unpredictability and public proofs, but it doesn’t remove economic attacks. If a game lets a caller retry until they like the outcome, they’ll farm calls. Bind requests to a unique session and consume the first valid proof only.
VRF also doesn’t solve all timing issues. If price movements or game state change meaningfully while you wait for the proof, a caller might front-run with cancellations. Lock the state that matters when you request randomness and expire attempts quickly.
Deployment checklist (concise and practical):
- Bind randomness to a nonce, player, and round ID; reject duplicates.
- Lock bets and game state at request time; settle only with the first proof.
- Add circuit breakers: late oracle → refund or clean fallback, never silent hangs.
- Publish full audit events: request, proof, seed, result, and settlement.
- Cap retries and ban re-roll patterns that create selection bias.
Operational pitfalls and rules of thumb
Never let the house pick when to draw. Automate requests on a fixed schedule or on bet acceptance, not after peeking at partial information. If the operator can time calls, players will assume the worst.
Price in failure. Oracles can stall, networks can partition, and gas can spike. Hold collateral to honor refunds, and show timers so players know when a round will auto-resolve or unwind. Transparency calms disputes before support tickets start.