What “provably fair” means on-chain
In blockchain betting, “provably fair” means every random outcome is derived by code you can audit and by randomness you can verify—so neither the operator, a miner/validator, nor an oracle can secretly bias the result. Because blockchains are deterministic and public, naïve tricks like using blockhash or timestamps let block producers influence results; security guides and developer discussions flag these as unsafe foundations for gambling RNG.
Why randomness is hard on a blockchain
Blockchains require every node to re-execute the same steps and agree on the same result, which clashes with “hidden entropy.” That determinism plus miner/validator incentives make simple on-chain sources predictable or biasable unless special protocols are used. OWASP’s 2025 Smart Contract Top 10 calls out insecure randomness as a common risk, and multiple analyses explain how block attributes can be manipulated within limits.
Three battle-tested patterns for verifiable on-chain randomness
1) Verifiable Random Functions (VRFs)
A VRF returns both a random value and a cryptographic proof. Your contract verifies the proof on-chain before using the number, so a compromised oracle or miner can’t swap in a “better” outcome undetected. Chainlink VRF is the most widely integrated service; its docs emphasize that proofs are verified on-chain before consumption and highlight production users like PoolTogether.
When you see a betting contract calling a VRF consumer method and checking a proof, that’s the on-chain fairness anchor. If the proof check fails, the game logic should not proceed.
2) Commit–reveal schemes
Participants first commit to a secret (hash), then later reveal it; the combined secrets produce randomness. This prevents last-minute tampering with inputs, though “last-revealer” withholding can still bias outcomes unless incentives or slashing are added. Tutorials and research discuss commit–reveal for lotteries and games, including mitigations for last-revealer bias.
3) Public randomness beacons
Independent networks like drand’s League of Entropy publish periodic, publicly verifiable random values. dApps can use beacon outputs on-chain (often via oracles or libraries) to source unbiased randomness with public verification. The drand docs and operators (e.g., Cloudflare) describe the beacon’s threshold-cryptography design and verifiability guarantees.
Ethereum’s native context: RANDAO and beyond
Ethereum’s proof-of-stake consensus mixes validator contributions (RANDAO) to make validator selection unpredictable. This makes the protocol fairer, but application contracts shouldn’t just read block data for game randomness; instead, they typically rely on VRFs or robust commit–reveal with incentives. Current references describe RANDAO’s role and caveats (e.g., withholding can bias at the margins), and there are active proposals to harden beacon randomness using BLS-based VRF semantics.
End-to-end transparency: what users can actually verify
A provably fair betting dApp should let you trace every step:
- The request: you can view the transaction that requests randomness (e.g., “requestRandomWords”) and the emitted event.
- The proof: the fulfillment transaction carries the VRF proof that the consumer contract verifies on-chain.
- The mapping: the contract maps the random word to a game outcome without introducing bias (see next section).
- The payout: settlement uses the recorded random value and emits final events. Case studies such as PoolTogether explain this audit trail at a user level.
Avoiding hidden bias when mapping random numbers
Randomness is only as fair as the mapping from uint256 to outcomes. Simple modulo (% n) can introduce “modulo bias” when 2²⁵⁶ isn’t a multiple of n. Security write-ups and beacon implementers show why modulo reduction skews low values and recommend rejection sampling or other uniform techniques.
Off-chain “provably fair” vs. on-chain provably fair
Traditional crypto casinos often use client/server seeds and HMAC (e.g., SHA-256/SHA-512) so players can verify results after the fact. That improves transparency, but you still trust the server to run the algorithm correctly and to handle seeds honestly. On-chain VRF/commit–reveal/beacon designs move both the draw and the verification into public, immutable code and proofs that any user can check on a block explorer.
Threats and mitigations
Miner/validator influence over naive sources
Don’t use blockhash, timestamps, or difficulty for gambling RNG—these can be nudged by block producers within limits. Use VRF, beacons, or well-incentivized commit–reveal.
Last-revealer bias in commit–reveal
Add deposits/slashing and tight reveal windows, or combine with beacons/VRF to remove discretion. Research on beacon design and Ethereum forum threads outline techniques.
Biased range mapping
Avoid modulo bias with rejection sampling or equivalent uniform methods when converting random words to dice faces, cards, or slot indices.
Oracle/liveness risk
VRF requests depend on oracle liveness. Contracts should include timeouts, retries, or fallbacks (e.g., re-requesting) so games don’t stall. VRF docs discuss on-chain proof checks and delivery semantics.
Buyer’s guide: how to evaluate an “on-chain provably fair” casino
Check the randomness source
Look for VRF (with on-chain proof verification), a well-specified beacon (like drand via a trusted bridge), or a documented commit–reveal with incentives. If a site claims “provably fair” but relies on block attributes, that’s a red flag.
Read the code and events
Open the contract and scan for a VRF consumer and a fulfillment handler that emits the result used for settlement. Verify that settlement references the stored random word from the same round. PoolTogether’s public materials illustrate the pattern from request to draw.
Test the mapping
Confirm the mapping from random word → outcome uses rejection sampling or another unbiased method, not naive % n. Beacon operator posts and crypto-security guides explain why.
Confirm the audit trail
A solid dApp links to its contracts and past draws; you should be able to reproduce outcomes from on-chain data. Case studies and docs from production users (e.g., PoolTogether) highlight this reproducibility.
Developer checklist for building provably fair games
- Use a VRF (e.g., Chainlink VRF) or a verifiable beacon; verify proofs on-chain before use.
- If using commit–reveal, design around last-revealer attacks (bonds, slashing, deadlines).
- Avoid modulo bias when mapping to ranges; use rejection sampling.
- Emit events for requests, fulfillments, and settlements so users can audit every round.
- Document the fairness path in your docs and UI; point to explorer links (good projects do—see PoolTogether).
- Treat “provably fair” as separate from regulation: audits, licensing, and KYC rules still apply in many markets. (See your local regulator’s guidance.)
FAQ
Is VRF better than commit–reveal
VRF removes last-revealer discretion and gives a proof the contract verifies on-chain. Commit–reveal can work with incentives and careful design, but it’s more fragile if participants can simply withhold reveals.
Can’t I just use the block hash
No—block producers can bias outcomes by choosing whether to publish a block or by slightly shifting timestamps. Security references and long-running dev threads advise against it for gambling.
What’s a randomness beacon
A public, periodically generated random value you can verify, like drand’s League of Entropy. It’s useful when you want a neutral, auditable source of entropy.
Do real apps use this today
Yes. For instance, PoolTogether uses Chainlink VRF to select prize winners and explains the process publicly, so anyone can verify draws.
Where is Ethereum heading on native randomness
Consensus already uses RANDAO for validator selection; there’s active discussion about harder-to-bias, VRF-style improvements at the protocol layer. App-level games still typically rely on VRF or robust beacons.
Final note
Provable fairness is both a cryptography problem and a product discipline. If you can’t audit a casino’s randomness path from request to settlement—and reproduce outcomes on a block explorer—it isn’t truly “on-chain provably fair.” Favor games that verify VRF proofs on-chain, avoid biased mappings, and publish a clear audit trail.
