What “provably fair” actually means
Provably fair is a way to let players independently verify that a game’s outcome wasn’t manipulated. The most common web2-style model commits to a hidden server seed up front (often by publishing its hash), combines it with your client seed and a per-bet nonce, and reveals the server seed later so you can recompute the result end-to-end.
On fully on-chain games, smart contracts can use cryptographic randomness that comes with a proof. A popular option is a verifiable random function (VRF): each request returns both a random value and a proof that the contract verifies on-chain before using the number.
Randomness can also come from decentralized “beacons”—public services that regularly publish unpredictable, publicly verifiable random values generated by a set of independent participants.
Why blockchains need special randomness
Blockchains are deterministic and miners/validators have limited influence over block data like timestamps and hashes. If a contract naively uses values such as blockhash for randomness, a block producer with enough incentive can bias or withhold a block to nudge outcomes—unsafe for high-value games. Security guides and community answers highlight this as a classic pitfall.
That’s why robust approaches use commit–reveal with delays, VRFs, or decentralized beacons rather than raw block data.
The two main models you’ll see (and how to verify them)
A) Off-chain “server/client seed + nonce” (provably fair on web2 casinos)
You’ll typically see three inputs: a server seed (committed up front via a hash), a client seed you can set, and a nonce that increments each bet. After the round or when you rotate seeds, the site discloses the server seed; you can recompute the outcome and confirm it matched the pre-published hash. Many operator pages and explainers walk through this flow.
Beginner check: confirm the site shows a server-seed hash before you play, lets you change the client seed, and provides a verification tool or algorithm to reproduce each result.
B) On-chain “provably fair” (smart contracts + verifiable randomness)
Here, the contract fetches randomness plus a proof and verifies it on-chain before it settles your bet. Chainlink VRF is a widely used implementation; case studies show consumer apps using it so players can audit draws on a block explorer.
Some projects use randomness beacons such as drand’s League of Entropy, which produces publicly verifiable, unpredictably generated values at fixed intervals via threshold cryptography and multiple independent operators.
Step-by-step: how to verify a “provably fair” result
- Record the inputs shown to you before play: server-seed hash, your client seed, and the current nonce value. After the round, the casino should reveal the raw server seed. Use the stated hash algorithm to confirm the reveal matches the original commitment, then recompute the game’s output with server seed + client seed + nonce to check it matches your result.
- If it’s an on-chain game using VRF, open the transaction in a block explorer and confirm the contract consumed a randomness response with a valid proof (VRF requests and fulfillments are visible on-chain).
- Make sure the game maps raw randomness to outcomes without bias. A common mistake is using modulo on an RNG whose range isn’t a multiple of the target range, which introduces “modulo bias.” Rejection sampling (discarding out-of-range values) avoids this.
Commit–reveal in a nutshell
Commit–reveal means a party first commits to a value by publishing its cryptographic hash and only reveals the value later. In randomness contexts, multiple parties can contribute to reduce single-party influence (examples include RANDAO-style schemes). Educational explainers and solidity pattern write-ups cover this design.
How “provably fair” compares to traditional RNG testing
Traditional online casinos typically rely on lab-tested random-number generators and compliance certifications rather than per-bet cryptographic proofs. Independent labs such as eCOGRA and Gaming Labs International publish and test against standards like GLI-19; many regulators reference or benchmark against these standards.
Both approaches can support fair games: lab-certified RNGs emphasize third-party audits and controls; provably fair systems emphasize user-verifiable math and transparent inputs. Many modern platforms use a mix, depending on the game type.
Common pitfalls and how to avoid them
Using block data for randomness. Do not accept games that rely only on blockhash/timestamp—this is flagged under “Insecure Randomness” in smart-contract security guides. Prefer VRF, beacons, or well-designed commit–reveal with delays.
Biased mapping from random numbers to outcomes. If the fairness page shows simple modulo without rejection, outcomes can be skewed; reputable guides explain why and how to fix it.
Assuming “provably fair” equals “licensed.” It doesn’t. In many jurisdictions, licensed operators must verify identity before allowing play; in Great Britain, that includes verifying name, address, and date of birth. Check local rules regardless of the randomness method.
Beginner checklist: quick questions to ask any site
Does the fairness page show a server-seed hash before play and reveal the seed later, or link to on-chain VRF/beacon proofs you can inspect?
Can you change your client seed, and is the nonce explained?
Is there guidance—or code—for verifying results yourself?
If it’s a traditional site, does it list an independent testing lab (eCOGRA/GLI) and current certificates?
Glossary
Server seed. Secret value generated by the casino; its hash is published in advance as a commitment. Revealed later for verification.
Client seed. Value you set or your browser generates; combined with the server seed to derive outcomes.
Nonce. An incrementing counter to produce a fresh result with the same seed pair.
VRF. Verifiable Random Function; returns both randomness and a proof the contract verifies on-chain.
Randomness beacon. Public, verifiable randomness produced by independent participants (for example, drand’s League of Entropy).
FAQ
Is VRF better than server/client seeds
They solve different problems. VRF gives an on-chain proof verified by the contract; seed-and-nonce models let you recompute the result off-chain after reveal. Both are valid when implemented correctly.
Can a miner still cheat a VRF-based game
The contract verifies a cryptographic proof tied to the request, so the miner can’t fabricate the random value itself. As with any oracle or beacon, liveness and implementation details still matter.
If a site says “provably fair,” do I still need a licence or KYC
Yes, legality is separate from fairness. Many regulated markets require ID checks before play.
How do I spot biased mapping
Look for simple modulo reductions without rejection. Sources explain why modulo bias skews probabilities and how to avoid it.
Bottom line
Provably fair isn’t magic—it’s math you can check. Whether a site uses seed-and-nonce with reveals, an on-chain VRF, or a decentralized beacon, the key is transparency you can verify yourself. Combine those checks with reputable oversight (or lab certification, where applicable), and you’ll know when you’re truly playing on a fair system.
