What “provably fair” really means
Provably fair systems let players independently verify that each game result was generated without post-hoc manipulation. In practice, casinos disclose the method and inputs used by their randomization algorithm so anyone can recompute an outcome and check it against the result shown in the bet history. This transparency typically relies on standard cryptography rather than “trust me” claims.
At the heart of most implementations is a commit-reveal flow: the operator commits to a secret value before a round by publishing only its cryptographic hash, then reveals the secret afterward so players can confirm it matches the earlier commitment. That behavior is an application of cryptographic commitment schemes, which are designed to be hiding and binding.
The cryptographic building blocks
Secure hash functions (e.g., SHA-256, SHA-512)
Hashes deterministically map arbitrary inputs to fixed-length digests; good hash functions make it infeasible to find preimages or collisions. These properties allow a site to publish a hash of a secret “server seed” before a game, then reveal the seed later for verification. The SHA-2 family is standardized by NIST.
HMAC
Many casinos generate random bytes by running an HMAC over seeds and per-bet counters. HMAC is a keyed construction built on a hash function and is widely specified by RFC 2104.
Commitment schemes
Commit-reveal is precisely a commitment scheme: publish a commitment now, reveal the committed value later so others can verify it hasn’t changed.
Verifiable Random Functions (VRFs)
Some on-chain games use VRFs to produce randomness plus a cryptographic proof that anyone can verify on-chain, removing the need to trust an operator’s server. Chainlink VRF is the most widely used implementation in production smart contracts.
How the classic off-chain model works (server seed + client seed + nonce)
Most “web2-style” crypto casinos use three inputs for each bet:
- Server seed: generated by the casino and committed in hashed form before play.
- Client seed: chosen by the player or browser.
- Nonce: an incrementing counter per bet to ensure uniqueness.
A typical flow:
- Before play, the casino shows the hash of its server seed.
- For each bet, the RNG derives bytes from an HMAC of the seeds.
- After you rotate seeds or finish a session, the casino reveals the plaintext server seed so you can recompute previous outcomes and confirm the pre-published hash matched.
Stake’s documentation, for example, notes an HMAC-SHA256 based generator that takes the client seed, server seed, a nonce, and cursor as parameters. Primedice describes an HMAC-SHA512 approach for its dice roll. Details vary by site, so always follow the operator’s published verifier steps.
A quick verification checklist for players
- Copy the revealed server seed, your client seed, and the exact nonce from your bet record.
- Use the casino’s open verifier or a third-party/verifier code sample that matches the site’s algorithm to recompute the random bytes.
- Map those bytes to the game’s outcome exactly as documented (dice roll, card shuffle, crash multiplier, etc.).
- Confirm the computed result equals the recorded result. If not, contact support with the test vectors.
Some community threads and explainers illustrate the standard “seed pair + nonce” model and how the nonce increments per bet. These can be useful sanity checks while you follow the official docs.
On-chain randomness: VRF and commit-reveal
Where games are implemented as smart contracts, randomness must be deterministic yet verifiable for all nodes. Two widely used patterns are:
• Chainlink VRF: an oracle network returns randomness with a proof; the contract verifies the proof before using the value. This gives anyone an on-chain audit trail of how the random number was derived.
• Commit-reveal: participants first commit to randomness by publishing its hash, then reveal inputs later. Academic and industry resources discuss how Ethereum projects implement this and where naive schemes can be gamed if not carefully designed.
Common pitfalls and how to spot them
Modulo bias when mapping bytes to ranges
Turning hash bytes into a game range using a simple modulo can bias outcomes when the range doesn’t evenly divide the numeric space. Correct implementations use rejection sampling or sufficiently large unbiased sources to make residual bias negligible.
Biased shuffles
Card games must use an unbiased shuffle (e.g., Fisher–Yates). “Sort-by-random” or naive swaps introduce detectable bias.
Underdocumented algorithms
If a site won’t document its exact input concatenation, hash/HMAC choice, and mapping to outcomes, you can’t truly verify fairness. Prefer operators that publish verifiers and test vectors. Stake and Primedice publicly document their implementations.
Misconception: “provably fair” means positive EV
Provable fairness proves an outcome wasn’t tampered with; it doesn’t remove the house edge or guarantee long-term profit. Always treat it as a transparency feature, not an advantage play. General explainers emphasize this distinction.
Operator best practices (for teams building casinos or on-chain games)
• Publish a clear fairness page with exact algorithms, seed handling, and mapping rules, plus open-source verifier code and test vectors.
• Use SHA-2 and HMAC as specified by standards bodies; avoid home-rolled crypto.
• Prevent modulo bias and implement Fisher–Yates for shuffles. Document the mapping precisely.
• Rotate seeds frequently and expose easy seed rotation for players. Track nonces per game.
• For on-chain titles, prefer VRF or robust commit-reveal constructions and verify proofs on-chain.
Step-by-step example: verifying a typical dice roll
- Retrieve from the bet record: server seed (revealed), server seed hash (archived), client seed, nonce, and game identifier.
- Compute HMAC using the documented function. For Stake/Primedice, the docs specify HMAC-SHA256 or HMAC-SHA512 with specific input ordering.
- Convert the resulting digest to an integer as specified and transform it into a roll value using the site’s exact method.
- Compare your computed roll to the recorded roll.
Because implementations differ in concatenation and parsing rules, always follow the operator’s page or its open verifier for the correct byte slicing and mapping.
FAQs
Is provably fair the same as traditional RNG certification?
No. Certification audits the RNG implementation and operational controls; provably fair exposes verifiable per-bet proofs using cryptography so players can self-check outcomes. They can be complementary. Overview explainers make this distinction clear.
What is a nonce and why does it matter?
It’s a per-bet counter so the same seed pair never produces the same output twice. Without a nonce, repeated inputs would repeat outputs.
Can an operator cheat by picking “lucky” server seeds?
The commit-reveal flow prevents seed changes after commitment because the hash of the server seed is published in advance. If the revealed seed’s hash doesn’t match the earlier hash, the scheme fails verification.
How do VRFs improve on off-chain seeds?
A VRF generates randomness plus a proof that a smart contract verifies on-chain before using it, eliminating reliance on a private server.
Why do some community posts warn about “modulo bias”?
Mapping bytes to a range with naive modulo can overweight some outcomes; robust systems use rejection sampling or large domains to minimize bias.
Conclusion
Provably fair gaming is best understood as verifiable transparency. Using standard primitives—hashes, HMAC, and commitment schemes—or on-chain VRFs, reputable operators let you reproduce and validate outcomes yourself. When you can inspect the algorithm, verify seeds and nonces, and rule out bias in byte-to-range mappings or shuffles, you gain confidence that results weren’t tampered with—while remembering the house edge still applies.
