Provably fair has no industry-wide standard. Casinos define it themselves, typically limited to verifiable randomness — but randomness alone doesn't prove a game is fair. A provably fair system must be transparent end-to-end: the commitment scheme, the RNG algorithm, the game logic, the payout structure, and the advertised RTP must all be independently verifiable. ProvablyFair.org defines and enforces that standard. We place thousands of real bets, independently recompute every outcome using the casino's published algorithm, and verify that the results match exactly. We then run tens of millions of simulated rounds to confirm the odds are what the casino says they are.
53,475
Live Bets Verified
253M
Simulated Rounds
10
Games Certified
100%
Open Source
What We Verify
Every audit answers five questions
1
Can the casino change your outcome after you bet?
We verify the cryptographic commitment that locks the result before you play.
2
Is the randomness real?
We independently implement the algorithm and prove your seed genuinely affects every outcome.
3
Does the game follow its own rules?
We recompute every bet in our dataset. 100% must match. Zero tolerance.
4
Is the house edge honest?
We mathematically prove the RTP from first principles, never trusting the casino's own numbers.
5
Does the system hold up under pressure?
We test the game's API for integrity issues that could compromise fairness.
We also provide an independent verification tool so you can verify any bet yourself — built from the same code we used to audit the game, not controlled by the casino.
Every finding, every dataset, and every line of verification code is published in an open-source repository. You don't have to trust us. You can check our work.
How each audit section maps to the casino's outcome pipeline
Captured by ProvablyFair.org
Outcome Generation — Casino
Seed Inputs
Server + client + nonce
↓
RNG algorithm
Deterministic computation
↓
Deterministic Outcome
Computed from seeds
↓
Payout Applied
Multiplier × bet amount
↓
Live Result Recorded
Player sees outcome
Independent Validation — ProvablyFair.org
Live Bets Captured
Real-money data collected
↓
Seed & Determinism Check
Section 1
↓
RNG & Entropy Validation
Section 2
↓
Verifier Parity
Section 3
↓
RTP
Section 4
Integrity
Section 5
↓
Certified
Framework Structure
Audit Overview
ProvablyFair.org evaluates the fairness of provably fair casino games through a structured, evidence-based audit framework. Every audit follows the same methodology regardless of game type, casino, or seed architecture.
The framework is designed around a single principle: claims require proof, and proof requires evidence that anyone can independently verify.
The framework consists of five scored audit sections (S1–S5) and two transparency sections (S6–S7). Sections 1–3 are cryptographic foundations — a single failure means the game cannot be provably fair by definition. Sections 4–5 test the game logic and implementation integrity. Sections 6–7 ensure the audit itself is player-accessible and fully reproducible — they are not scored but are required for certification.
S1
Seed & Determinism
Cryptographic
S2
RNG & Entropy
Cryptographic
S3
Verifier Parity
Cryptographic
S4
RTP & Payout
Analytical
S5
Fairness Integrity
Integrity
S6
Player Verification
Transparency
S7
Reproducibility
Transparency
A typical per-game audit involves thousands of real-money bets placed and individually verified, tens of millions of simulated rounds for statistical validation, and a purpose-built verification codebase written independently from the casino's own code.
Every audit produces a public, open-source repository. Anyone can clone it, run the test suite, and independently verify every finding. The repo is the credential.
Scope
Current Scope & Audit Boundaries
This framework is optimized for provably fair games that use commit-reveal seed architectures — including single-player games (Dice, Plinko, Keno, Mines, Limbo, Wheel) and shared-outcome games (Crash, Roulette). These represent the vast majority of provably fair games in the crypto casino market.
Entropy Models Verified
Client Seed + Server Seed
Hash Chain
Server Seed + External Beacon
HMAC-SHA256 & SHA-256 architectures validated
Examples of Games Covered
DicePlinkoKenoMinesLimboHi-LoBlackjackTowerCross the RoadRouletteCrashWheel
Any provably fair game is eligible
The framework supports multiple entropy models: client seed + server seed, hash chain, and server seed + external beacon (e.g. drand, block hash). Each model is verified using the same S1–S5 structure with model-specific adaptations documented in the Operator Trust Analysis.
The framework has been validated on HMAC-SHA256 commit-reveal architectures and plain SHA-256 architectures. Additional architectural patterns are validated as the client base expands.
What Every Audit Operates On
Operator's game logic & RNG specification
Player-facing API responses & published seeds
Bet histories & live game behaviour
Independent implementation & verification
Every test in this framework operates on the operator's game logic, player-facing API responses, published seeds, bet histories, and live game behaviour. Operators provide their game algorithm and RNG specification as part of the audit engagement. ProvablyFair.org independently implements the algorithm, collects live data, and verifies every outcome.
This framework is purpose-built for provably fair game verification. Provably fair systems are designed so that game outcomes can be independently verified — the cryptographic inputs are visible by design. The methodology combines source-level review of the operator's game logic with independent implementation, live data collection, and cryptographic verification to produce independently verifiable proof of every claim tested.
Source-level review of the operator's game logic is included in every audit. Where operators additionally grant ongoing repository access, the audit scope extends to continuous code monitoring (see Assurance Tiers below).
Not in scope
This audit covers the fairness and cryptographic integrity of provably fair game outcomes. It does not cover:
Platform & Infrastructure Security
Fund custody
Withdrawal processing
Licensing or regulatory compliance
Responsible gambling practices
Anti-money laundering controls
Fairness of non-provably fair games
Audit Sections
Technical Methodology
Each layer is independently verified. Click to expand the full methodology for each section.
1
Seed, Nonce & Determinism
Can the casino change your outcome after you bet?
Scored
▶
Section 1 verifies the commit-reveal scheme that prevents the operator from choosing outcomes retroactively. If the commitment chain is broken, the entire system is meaningless.
What we test
Seed hash integrity — For every seed epoch, we verify that the cryptographic hash of the revealed server seed matches the commitment published before play. The specific hash construction varies by casino (SHA-256, SHA-512, HMAC-SHA256, HMAC-SHA512, or other schemes). The audit identifies the construction used, implements it independently, and verifies every commitment. A single mismatch means the commit-reveal chain is broken.
Commitment linkage — The hash committed before a betting epoch matches the hash seen in live bet responses.
Next-seed pre-commitment chain — For each seed rotation, we verify that the hash of the next server seed displayed to the player before rotation matches the active server seed hash used after rotation. This confirms the server seed was generated and committed before the player submitted their new client seed at rotation time. Without this check, the server could theoretically observe the player's chosen client seed and generate a favourable server seed after the fact. Method: the capture script records the next server seed hash from the API response before each rotation. The verification step checks equality across every consecutive epoch pair. A single mismatch is a hard fail.
Hash consistency within epoch — The server seed hash is identical across every bet in an epoch. Any mid-epoch change is a commit-reveal violation.
Nonce sequence — Nonces increment sequentially (0, 1, 2, …) with no gaps, repeats, or resets within an epoch. Gaps allow the server to skip unfavourable outcomes.
Client seed stability — The client seed remains constant within an epoch. Silent swaps remove the player's influence.
Client seed origin — We verify whether the client seed is generated client-side or server-side, and whether the player can change it to a custom value. Method: browser developer tools network inspection during seed rotation, confirming no server response contains the new client seed value before the player submits it. Evidence captured as screenshots stored in the audit repository. One-time check per casino, re-verified at annual recertification. The client seed origin determines the cherry-pick risk tier (see Client Seed Origin Tiers below).
What it proves
If the commit-reveal chain is intact, the server cannot retroactively choose a seed that produces a desired outcome — the seed was locked before bets were placed, and the hash proves it.
Hard fail criteria
Any of the following is an automatic NOT PROVABLY FAIR verdict:
Seed hash mismatch (any epoch)
Nonce gap or repeat within an epoch
Client seed changed mid-epoch
Server seed hash changed mid-epoch
Player cannot set their own client seed (client seed origin hard fail)
Next-seed commitment not honoured on rotation (pre-displayed next server seed hash does not match the server seed hash that becomes active after rotation)
Client Seed Origin Tiers
The client seed origin affects how Pass 2 cherry-pick detection is applied and how the game is evaluated. These tiers apply to games using client seed architectures — hash chain and external beacon games are evaluated separately under the Operator Trust Analysis.
Full Pass
Client-side generated
Client seed generated client-side (e.g. crypto.getRandomValues) AND player can change it to any value of their choosing. Both conditions required. The server cannot know the client seed at commitment time, and the player retains the ability to override the auto-generated value. No server response contains the client seed value during network inspection. Cherry-picking is structurally impossible. Pass 2 is included as a confirmatory check but is not strictly necessary.
Conditional Pass
Server pre-filled
The casino pre-fills the client seed from the server, or the server can know the default seed value — but the player can change it. Because the server could in principle predict the default seed, Pass 2 cherry-pick detection (run against the casino's revealed seeds) is the key check for this configuration. The verdict for a game with this seed origin depends on the Pass 2 result and is stated in the game's report.
Hard Fail
Player cannot set seed
Player cannot set their own client seed. Game receives NOT PROVABLY FAIR verdict regardless of other results.
Evidence for client seed origin is captured as a screenshot of the browser developer tools network tab during seed rotation, stored in the audit repository under evidence/. This is a one-time check per casino (not per game), re-verified at annual recertification. Each audit report includes the client seed origin verdict under S1.
External Beacon Verification
For drand and other public beacon architectures, three additional checks apply beyond the standard S1 framework: (1) beacon authenticity — each round's beacon value is fetched from the public source and confirmed to match what the operator used, (2) beacon monotonicity — round IDs must strictly increase with no round-shopping, (3) commitment timing — the operator must accept the player's bet before the beacon for that round is published.
Commitment timing proof. The timing check uses two authoritative sources, neither of which is the auditor's clock. The bet-placement timestamp comes from an operator-side record (transaction API, signed database entry, or equivalent). The beacon publication time comes from the public beacon's known schedule — for drand quicknet, computed as genesis_time + (round − 1) × period; for blockchain beacons, read from the block header. A positive margin between beacon publication and bet placement proves the bet existed before the beacon value did. Any negative margin is a hard fail. This is structurally stronger than local-timestamp proofs because both endpoints are independently verifiable from public or operator-authoritative sources.
2
RNG & Entropy Model
Is the randomness genuinely random, or could it be rigged?
Scored
▶
Section 2 examines the random number generation algorithm itself — not whether outcomes look random (that is tested statistically in S4), but whether the algorithm is structurally capable of producing unbiased, unpredictable outputs.
What we test
Algorithm correctness — We independently implement the RNG from the published cryptographic specification (not from the casino's code) and verify it produces the same results.
Modulo bias — If the RNG uses modular arithmetic, we check for bias. For binary outcomes (e.g. Plinko uint32 % 2), bias is mathematically zero. For larger outcome spaces (e.g. Keno's 40-position shuffle), rejection sampling is required and verified.
Entropy sources — We identify all inputs to the RNG (server seed, client seed, nonce, cursor/round index) and verify no additional hidden inputs exist.
Client seed influence — We recompute all outcomes with a deliberately wrong client seed. If outcomes don't change, the client seed isn't actually used and the "provably fair" claim is false. The change rate is quantified across all seed epochs.
Key encoding — We verify the correct encoding of the server seed (hex-decoded bytes vs UTF-8 string — a common implementation error that produces different HMAC outputs).
What it proves
The RNG produces unbiased outputs determined entirely by the declared inputs. No hidden entropy source can influence outcomes. The player's client seed is a genuine contributor to every result.
Hard fail criteria
Client seed not used in computation (0% change rate with wrong seed)
Hidden inputs detected (outcomes cannot be reproduced from declared inputs alone)
Modulo bias exceeding 1/2^32 without rejection sampling
3
Verifier Parity
Does the live game actually follow its own rules?
Scored
▶
Section 3 independently recomputes every live bet outcome using revealed seeds. This is the empirical proof that the game engine in production matches the published algorithm.
What we test
Full outcome recomputation — Every bet in the dataset is independently recomputed using (serverSeed, clientSeed, nonce) and the game-specific algorithm. 100% exact match required. Zero tolerance.
Multi-phase data collection — Bets are collected across structured phases:
Phase A: Configuration coverage (all game configs at minimum stake)
Phase B: High-volume single-config for statistical depth
Phase C: Code-path equivalence at elevated stake ($10) — proves bet amount is not an RNG input
Payout math — For every bet: win_amount = bet_amount × payout_multiplier within 1e-8 tolerance.
Multiplier table provenance — Every payout multiplier in the dataset matches the reference configuration file.
Bet-size independence — Phase C deterministically proves the same (serverSeed, clientSeed, nonce) produces the same outcome regardless of bet amount.
What it proves
The game engine in production computes outcomes exactly as the published algorithm describes. No conditional logic was detected across all tested configurations and stake levels. Section 3 exists specifically to detect implementations where the RNG runs correctly but a secondary layer modifies results before delivery — the attack pattern seen in real-world investigations where player verifier results matched the algorithm but live game results diverged conditionally. The elevated-stake test (Phase C) is designed to catch conditional code paths that activate only at higher bet amounts.
Hard fail criteria
Any outcome mismatch between independent recomputation and recorded result
Payout arithmetic error exceeding 1e-8
4
RTP & Payout Logic
Is the house edge what the casino claims?
Scored
▶
Section 4 mathematically verifies payout tables and multipliers against independently computed theoretical models. The key innovation is anti-circularity: RTP is computed from first principles, not from the casino's own probability fields.
What we test
Anti-circularity proof — The theoretical RTP is derived independently, never using the casino's own probability fields or claims. The method varies by game type:
Distribution-based games (e.g. Plinko, Keno, Mines): Probabilities are computed from first principles using the known mathematical distribution (binomial, hypergeometric, combinatorial) and multiplied by observed multipliers to derive RTP.
Hardcoded payout table games (e.g. Wheel, Slots-style): Where probabilities are not derived from a clean distribution, we derive them from the verified RNG mechanics. The algorithm maps a uniform RNG output to outcomes via defined ranges or thresholds — the probability of each outcome is a mathematical consequence of that mapping. We independently compute the outcome probabilities from the verified algorithm, then multiply by the observed multipliers. The casino cannot misrepresent probabilities because they are determined by the RNG mapping function already verified in S2–S3.
Finite-outcome games (e.g. Blackjack, Video Poker, Slots): Where the outcome space is finite and fully enumerable, RTP is established by exhaustive enumeration — every possible outcome is computed exactly and weighted by its true probability, producing an exact RTP figure rather than a statistical estimate. For a cluster-pays slots game, this can mean enumerating the full 2³² outcome space to produce an exact RTP. Monte Carlo simulation then serves as an independent cross-check on the enumerated value.
Simulation cross-check: In all cases, millions of simulated rounds through our independent RNG implementation confirm the empirical distribution matches the independently derived probabilities. For finite-outcome games, the simulation cross-checks the exact enumerated RTP rather than replacing it.
This is the test that catches payout table manipulation — if a casino hardcodes probability tables that differ from what the verified algorithm actually produces, this test detects it.
Two-pass Monte Carlo simulation:
Pass 1 (fresh random seeds): Millions of rounds per configuration with independently generated seeds. Chi-squared goodness-of-fit at Bonferroni-corrected thresholds. Serial independence (autocorrelation + runs test). Confirms the RNG produces the expected distribution.
Pass 2 (casino seeds — cherry-pick detection): All revealed server seeds × 10,000 nonces each. Tests whether the casino pre-selected seeds that produce favourable early outcomes. Multi-window analysis on flagged combinations distinguishes real cherry-picking from statistical noise. Pass 2 is adapted based on client seed origin (verified in S1): for Full Pass origin (client-side generated seed), Pass 2 uses auditor-chosen seeds as a confirmatory check — cherry-picking is structurally impossible when the server cannot know the client seed at commitment time. For Conditional Pass origin (server-assigned default seed), Pass 2 must use the actual server-assigned client seed pairs to test the real cherry-pick scenario; results using auditor-chosen seeds are not scored.
Statistical testing — multi-configuration games — Games whose outcomes split across configured variants (e.g. Plinko rows × risk levels, Keno pick counts, Mines mine counts, Dice targets):
Chi-squared goodness-of-fit applied per configuration, with Bonferroni correction (α = 0.01 / N_configs) to control family-wise error across the full set of tests.
Serial independence per configuration — lag-1 autocorrelation and the Wald-Wolfowitz runs test — with pass thresholds |lag1Z| < 3 and runs p ≥ 0.01.
Pass 2 cherry-pick detection uses binomial survival thresholds based on expected failure counts under H₀.
Statistical testing — single-distribution games — Games producing a single outcome distribution with no configurable variants (e.g. Crash, Wheel, Video Poker, Blackjack) — whether continuous, like Crash, or discrete with one fixed configuration, like a Wheel's fixed set of positions or a hand-rank distribution. With no natural configuration split, one long goodness-of-fit test is vulnerable to tail-bin variance, so we construct multiple independent tests via seed streams:
Per-stream goodness-of-fit (chi-squared, or a z-test against the analytical RTP where appropriate) across 10 independent seed streams — typically 500K-1M rounds each (5M-10M total).
Stream p-values combined via Fisher's method: −2 Σ ln(p_i) ~ χ²(2K). Pass criteria: Fisher's combined p-value ≥ 0.01, with no more than 2 individual streams below α = 0.01.
Per-stream results are reported as context in each audit report. This multi-stream design is derived from NIST SP800-22's proportion-of-sequences-passing methodology used in cryptographic RNG validation.
Serial independence is evaluated on the combined sample, with the same thresholds as multi-configuration games (|lag1Z| < 3 and runs p ≥ 0.01).
Multiplier symmetry and floor checks — All payout tables verified for internal consistency, symmetry where expected, and minimum payout floor enforcement.
Progressive house edge disclosure — Where house edge varies by bet amount (scaling edge brackets), the full structure is documented with the bracket boundaries and edge values.
Consolation payout analysis — Edge-case configurations (e.g. non-zero payouts on zero hits) are identified and verified within the overall RTP design.
Scored vs informational separation — Live-bet statistical tests (chi-squared, serial independence) are reported as informational context at small sample sizes. Simulation is the authoritative statistical layer. This prevents false confidence from underpowered tests and false concern from expected-variance results.
What it proves
The mathematical relationship between outcomes, multipliers, and RTP is exactly what the theoretical model predicts. The casino's seeds do not show evidence of pre-selection bias. The house edge is what is claimed — no more, no less.
Hard fail criteria
Anti-circularity: config probabilities diverge from independent mathematical computation
Simulation Pass 1: chi-squared failure at Bonferroni-corrected threshold across multiple configs
Simulation Pass 2: broad cherry-pick flags (early AND extended windows anomalous)
5
Fairness Integrity Testing
Does the implementation maintain fairness under non-standard conditions?
Scored
▶
Sections 1–4 prove the game is mathematically fair. Section 5 proves the implementation maintains integrity under adversarial conditions. This is where we find vulnerabilities in the gap between theory and production.
What we test
A standardized matrix of fairness integrity tests is applied to every game. The matrix covers:
Replay protection — Completed bet IDs cannot be replayed to duplicate payouts.
Input validation — Invalid, out-of-range, or malformed parameters are rejected.
Seed integrity under adversarial input — Server and client seed fields cannot be injected or overridden via API.
Cross-player isolation — One player's seeds, nonces, or outcomes are not observable or influenced by another player.
Payout field integrity — Client-supplied payout or multiplier values are ignored by the server.
Nonce sequence enforcement — Nonce values cannot be forced, replayed, or skipped via API.
Parameter boundary enforcement — Bet amounts, configuration values, and game parameters outside valid ranges are rejected.
Game-specific state tests — For multi-step games (eg. Mines), additional tests cover state integrity (e.g. revealing the same tile twice, cashout after loss).
Each test has defined steps, expected behaviour, and captured request/response evidence. Each test result is classified as PASS, FLAG, or HARD FAIL (see the severity framework below).
Scope: Section 5 testing is scoped to fairness-relevant API behaviour. It is not a full application security assessment or penetration test — platform security, authentication, infrastructure, and payment systems are out of scope (see Not in Scope).
What is published
Section 5 results are published as a summary matrix in the audit report showing: test ID, category, what was tested, expected behaviour, result (Pass / Flag / Hard Fail / Remediated), and a finding summary where applicable. This gives full transparency on test coverage and outcomes.
What is retained
Section 5 combines two kinds of test. The data-driven tests draw on the same published dataset, audit code, and S1–S4 evidence as the rest of the audit — their basis is fully transparent and, where they are code checks, reproducible from the repository. The live API-probe tests are different: their detailed request payloads and reproduction steps are documented internally and shared privately with the operator under responsible disclosure, but not published, to avoid providing the exact requests against a live production endpoint. The probe results are published in full; only the request-level specifics are withheld.
What it proves
The game implementation enforces its fairness invariants under non-standard inputs and adversarial conditions. The API cannot be used to produce outcomes, payouts, or state transitions that violate the game's rules.
Severity framework
PASS — Test passed; no issue detected.
FLAG — An anomaly was found but the fairness guarantee remains intact. Documented for transparency and disclosed to the operator. Does not block certification.
HARD FAIL — A fairness guarantee is broken or cannot be confirmed. Certification is blocked until remediated and re-verified.
6
Player Verification
Can a player verify their own bets without trusting anyone?
Transparency
▶
Section 6 translates the technical audit into player-accessible verification. A provably fair system that no player can actually verify in practice is provably fair in name only. S6 is not scored but is a required deliverable for certification.
What we deliver
Independent player verifier tool — A standalone, open-source web-based tool built and maintained by ProvablyFair.org from the same codebase used during the audit. Players can paste their bet details (server seed, client seed, nonce, game parameters) and independently verify the outcome. Unlike the casino's own built-in verifier — which the casino controls and can modify without notice — the ProvablyFair.org verifier is independent, open-source, and version-controlled. Any post-certification change to the casino's game logic will produce a mismatch when players verify through the ProvablyFair.org tool, effectively creating a continuous, player-driven monitoring layer.
Verification scripts — JavaScript and Python implementations published in the audit repository. Any technical user can run these locally.
Verification walkthrough — Step-by-step guide: place a bet, open the details, verify the result, rotate the seed to reveal.
Plain English algorithm explanation — How the game works, what the seeds are, why it matters, written for a non-technical audience.
What it proves
The audit's findings are accessible to the people the audit is designed to protect. Players don't need to trust the casino or the auditor — they can verify themselves.
7
Reproducibility
Can anyone independently reproduce every finding in this audit?
Transparency
▶
Section 7 is what separates a certification claim from a certification proof. Every finding, every statistic, every pass/fail result in the audit can be independently reproduced by anyone with the repository. S7 is not scored but is a required deliverable for certification.
What we deliver
Complete audit repository — Source code, datasets, configuration files, evidence screenshots, and verification outputs. Published on GitHub.
Dataset integrity — SHA-256 hash of the master dataset computed and verified before every test run. If the dataset is tampered with, the hash check fails before any analysis executes.
Single-command reproduction — npm test or equivalent runs the entire verification suite and produces all outputs.
Deterministic outputs — verification-results.json, determinism-log.json, simulation-results.json, chi-squared-results.json — all reproducible from the pinned dataset.
Evidence chain — Timestamped screenshots at phase start/completion, game UI captures, fairness page documentation.
What it proves
The audit is not an opinion — it is a verifiable, reproducible proof. The repository is the credential. Anyone can clone it and confirm every claim.
Governance & Process
Standards & Lifecycle
Verdict criteria, operator trust analysis, certification lifecycle, and independence commitments.
Verdict Framework
▶
Every game receives one of three verdicts:
Verdict
Meaning
Criteria
Full Pass
All scored sections pass with no fairness-affecting findings. Any flags are advisory (non-fairness) and disclosed in the game's audit report.
S1–S5 all pass. S6–S7 complete.
Conditional Pass
All hard-fail criteria pass and no manipulation is detected, but the game carries a residual fairness consideration that is documented and disclosed in the report.
S1–S5 pass. The residual consideration is documented with explanation. S6–S7 complete.
Not Provably Fair
One or more hard-fail criteria triggered.
Any hard fail in S1, S2, S3, S4 anti-circularity, or S5 critical.
A casino receives the ProvablyFair.org Certified badge only when all games in the audit scope achieve a pass verdict (Full or Conditional), with S6 and S7 complete and published. S6 and S7 are not scored but are required deliverables — a game cannot be certified without player verification tools and a reproducible audit package.
Operator Trust Analysis & Entropy Models
▶
Every audit includes an explicit operator trust analysis documenting what the commit-reveal scheme guarantees and what residual trust the player must extend.
What the operator cannot do (prevented by protocol, verified in S1–S3): - Change the server seed after commitment - Alter payout multipliers post-bet - Insert hidden RNG inputs - Override client seed influence (where client seed is used)
Entropy Models
Different game architectures provide different levels of pre-commitment assurance. Certification requires that the commit-reveal architecture prevents the server from independently selecting individual round outcomes with foreknowledge. Client seed participation, pre-committed hash chains, and external randomness beacons each achieve this through different mechanisms. Server-seed-only architectures do not — each round's outcome is independently chosen by the server with full knowledge of the result. The entropy model is explicitly disclosed in every audit report.
Any game using the server-seed-only model receives a NOT PROVABLY FAIR verdict, regardless of whether the player takes action after commitment. While post-commitment player actions (e.g. Mines tile selection, Hi-Lo choice, multiplayer betting) may limit the server's ability to exploit seed selection in some game designs, this is a game-logic argument, not a cryptographic guarantee. Provably fair certification requires structural prevention of pre-selection — the architecture must make it impossible, not merely impractical. Operators can achieve certification by adding client seed participation, a hash chain, or an external beacon.
Model
Architecture
Pre-Commitment Control
Cherry-Pick Risk
Verdict Impact
Client Seed + Server Seed
Server commits a seed hash. Player sets a client seed. Outcome depends on both.
Casino controls server seed but not client seed.
Low — constrained by player-contributed entropy the casino cannot predict.
Full Pass eligible
Hash Chain
Casino pre-generates a chain of N hashes (e.g. 10M). Each hash produces one round's outcome. Chain is released in reverse order — each hash is the SHA-256 of the next, making the chain verifiable backwards.
Casino selected the chain at generation time. Once committed, individual rounds cannot be altered.
Medium — casino could have selected a favourable chain from many candidates at generation time, but cannot manipulate individual rounds after the chain begins. The longer the chain and the more rounds played, the harder it is for a pre-selected chain to maintain a biased distribution without detection.
Full Pass eligible
Server Seed + External Beacon
Server commits a seed hash. Final outcome incorporates a value from an external, publicly verifiable randomness beacon (e.g. drand, block hash) that the casino cannot predict at commitment time.
Casino controls server seed but the external beacon value is unpredictable and independently verifiable.
Lowest — casino cannot pre-select outcomes because the beacon value is unknown at commitment time.
Full Pass eligible
Server Seed Only
Casino generates a fresh server seed per round. No client seed, no hash chain, no external entropy. Outcome determination is fully controlled by the server, regardless of whether the player takes action after commitment.
Casino has full control over every outcome before committing. Each round is independently selectable with full foreknowledge of the result.
Highest — every round's outcome is independently chosen by the casino with no constraining entropy. Post-commitment player actions may limit exploitability in some game designs but do not provide cryptographic prevention.
Not Provably Fair — the server can independently select each round's outcome with full foreknowledge. Commit-reveal prevents post-bet changes but does not constrain pre-commitment selection. Operators can upgrade to client seed participation, hash chain, or external beacon.
How Entropy Model Affects the Audit
S1–S3 verification applies to all models — the commit-reveal chain, nonce integrity, and outcome recomputation are tested regardless of entropy source.
S4 Pass 2 (cherry-pick detection) is adapted per model:
Hash chain games: statistical analysis of the observed crash point sequence against the expected distribution. Extended runs testing for systematic bias across the chain.
External beacon games: verification that the beacon value is authentic, externally published, and correctly incorporated into the outcome computation.
Operator Trust Analysis in the audit report discloses the model used, explains the residual trust implications, and notes whether a stronger model is available for the game type.
Server-seed-only games receive a NOT PROVABLY FAIR verdict regardless of game design, because the server can independently select each round's outcome with full foreknowledge of the result. This is the one architectural property the methodology treats as an unconditional hard fail — not because pre-selection always leads to exploitation, but because provably fair certification requires structural prevention, not game-specific arguments about impracticality. This creates a clear upgrade path for operators: add client seed participation, a hash chain, or an external beacon.
Assurance Tiers & Coverage Requirements
▶
The S1–S7 framework is the audit baseline — the minimum standard every game must clear for certification. The operator provides their game logic and algorithm specification. ProvablyFair.org independently implements, verifies, and publishes the results.
Both tiers pass the same S1–S5 scored tests. The baseline certification is fully defensible on its own. Repo Access adds ongoing visibility that is noted on the certification page, giving operators a visible incentive to provide it.
The key difference: baseline confirms what the code looked like at audit time. Repo access confirms what the code looks like right now — and at any point during the certification period.
Tier
Access Level
What It Proves
Certification Notation
Baseline
Operator provides game logic and algorithm specification. ProvablyFair.org independently implements and verifies.
Every outcome is cryptographically verified, every payout is mathematically correct, the codebase contains no conditional logic or hidden post-processing, and every claim is independently reproducible.
ProvablyFair.org Certified
Repo Access
Operator grants ongoing read access to their live repository
Everything in Baseline, plus the ability to detect code changes between audits. ProvablyFair.org can verify at any point that the live codebase matches the audited version, and can review any changes before or after deployment.
ProvablyFair.org Certified — Repo Access
What Every Audit Includes
Every baseline audit includes source-level review as standard:
Source-level RNG review — Direct verification of the operator's game logic against the published specification. Confirms no conditional logic, no hidden inputs, no post-processing of outcomes.
Independent implementation — The verification codebase is built from the operator's algorithm specification and cross-referenced against their source code.
Fairness integrity testing — Standardised FI matrix applied against the live API.
What Repo Access Adds
Where an operator grants ongoing repository access:
Change detection — ProvablyFair.org can diff the codebase at any point during the certification period against the version that was audited.
Pre-deployment review — Operator can request ProvablyFair.org review of changes before they go live.
Faster re-certification — Annual renewals and game update re-checks are faster when ProvablyFair.org has continuous visibility into the codebase.
Limitations by Tier
Baseline confirms the game logic contains no conditional or unfair behaviour at the time of audit. It does not guarantee that future code changes maintain the same properties (this is addressed by the annual renewal and the independent player verifier tool).
Repo Access significantly narrows this gap — ProvablyFair.org can check the live codebase at any time during the certification period and verify it matches the audited version. However, repo access does not guarantee that the deployed production build matches the repository (deployment pipeline verification is outside the scope of this framework).
In both tiers, the independent player verifier tool (S6) and the reproducible audit repo (S7) provide ongoing assurance that catches any divergence between the audited logic and live production behaviour.
Extended access findings are documented separately from baseline verification. A game that passes S1–S7 via external verification is certified to the same baseline standard regardless of whether source access was provided — source review provides additional assurance, not a different standard.
Minimum Coverage Requirements
These are verification coverage minimums — actual audits typically collect 5,000–8,000+ bets per game. Every bet is individually recomputed; a single mismatch is a hard fail. Simulation volumes (1M rounds Pass 1, 10K nonces Pass 2) detect RTP deviations as small as 0.1%.
Requirement
Minimum
Live bets verified per game
1,000 (configuration coverage across all collection phases)
Configs covered
All published configurations
Bets per config (Phase A)
50 (verification coverage, not statistical sample)
High-volume config (Phase B)
1,000 bets on primary statistical config
Code-path equivalence (Phase C)
100 bets at elevated stake
Client seed variation (Phase D)
2+ distinct client seeds
Monte Carlo Pass 1
1,000,000 rounds per config
Monte Carlo Pass 2
10,000 nonces per revealed seed
Seed epochs with full reveal
All epochs — zero unverifiable bets
Next-seed pre-commitment chain
All rotation events — zero unverified transitions
S5 fairness integrity tests
All tests in standardized matrix
Certification Lifecycle & Revocation
▶
Certification is not a permanent stamp. It remains valid only as long as the system continues to pass verification.
Operators are required to notify ProvablyFair.org of material changes to certified games within 14 days. Failure to notify does not invalidate the certification retroactively, but the certification applies only to the game version that was audited.
Full re-audit on fresh data. Badge renewed or suspended.
Spot check failure
Badge suspended immediately. Full re-audit required for reinstatement.
Player-reported failure
ProvablyFair.org investigates within 5 business days. If confirmed, badge suspended.
Failure & Revocation Protocol
When an audit results in a NOT PROVABLY FAIR verdict, or when a certified game fails post-certification verification:
During Initial Audit:
Private disclosure — Hard-fail findings are communicated to the operator privately within 48 hours of confirmation.
Remediation window — The operator has 30 days to remediate the finding and request a re-test of the affected layer(s).
Re-test — ProvablyFair.org re-collects data and re-runs the affected verification steps. If the finding is resolved, the audit continues. If not, the game receives a NOT PROVABLY FAIR verdict.
Publication — Audit results are published regardless of outcome. A NOT PROVABLY FAIR verdict is published with the same transparency as a pass — full dataset, full code, full reproducibility.
Post-Certification Revocation:
Immediate badge suspension — Badge is deactivated within 24 hours of confirmed failure.
Operator notification — Operator is notified with specific findings and evidence.
Public disclosure — Revocation is published on the ProvablyFair.org certification registry with the date, reason, and evidence reference.
Reinstatement path — Operator may request a full re-audit after remediation. Reinstatement requires passing all S1–S7 sections on fresh data.
ProvablyFair.org publishes all certification outcomes — passes, conditional passes, failures, and revocations — on a public certification registry. This registry is the transparency mechanism that maintains the certification's credibility.
Ongoing Assurance
Certified games are continuously monitored through three operational mechanisms: the independent player verifier tool (Section 6), annual re-audits on fresh data, and mandatory operator notification of material changes within 14 days.
As an additional layer, an automated spot check system is being developed to periodically place bets on certified games using the same verification pipeline as the initial audit. Bets are independently recomputed and compared to server responses. If a mismatch is detected and verified, the certification badge is suspended pending a full re-audit.
Spot check status: In active development. Initial deployment targets Late 2026.
Player Verification Layer
The published player verification tools (S6) and open-source audit repos (S7) enable any player to independently verify any bet at any time. This creates a distributed verification layer — the more players who verify, the harder it becomes for a casino to deploy conditional logic that behaves differently outside the audit window.
Re-Audit Triggers
The following events trigger a re-audit of the affected game:
Spot check mismatch (verified)
Material change to game logic, payout tables, or seed architecture
Player-reported verification failure (confirmed by ProvablyFair.org)
Annual renewal (12 months from certification date)
Implementation Status
Component
Status
S1–S4 verification suite
Fully operational
S5 fairness integrity testing
Operational (standardized matrix)
S6 player verifier tool
Operational — open-source, built from audit codebase, maintained by ProvablyFair.org
S6 bet history converter
Per-casino adapters in development
S7 reproducibility package
Fully operational
Automated spot checks
In active development; initial deployment Late 2026
Configuration hash capture
Implemented where public endpoints available; documented as operator-provided otherwise
Certification registry
Operational
Failure & revocation protocol
Defined (this document)
Independence & Versioning
▶
ProvablyFair.org is funded by audit fees paid by casino operators. This creates an inherent conflict of interest — the same conflict faced by credit rating agencies, financial auditors, and traditional gaming certification labs.
ProvablyFair.org mitigates this conflict through:
Public reproducibility — Every audit finding is independently verifiable. The repos ensure that no finding can be suppressed or softened without detection.
Published failure record — The fraud investigation portfolio demonstrates willingness to publish negative findings against industry participants, including cryptographic proof of live manipulation.
Methodology transparency — The methodology, verdict criteria, and hard-fail thresholds are published and version-controlled. Auditors cannot apply subjective judgment to pass/fail decisions on hard-fail criteria.
This section exists because intellectual honesty about structural conflicts is more credible than pretending they don't exist.
ProvablyFair.org is contractually committed to publishing all audit findings regardless of verdict. No operator engagement agreement includes the right to suppress, delay, or modify findings.
Boundaries of Verification
ProvablyFair.org certification provides cryptographic and empirical proof that the audited game operates as specified at the time of audit and across the bets we tested. Post-audit code changes, bets outside the dataset, and manipulation scenarios that fall outside the verified system behaviour are addressed through ongoing assurance mechanisms — annual re-audits, the independent player verifier tool, automated spot checks, and mandatory operator change notification — rather than by the initial audit alone.
Methodology Versioning
This page always reflects the current version of the methodology. The methodology evolves as the framework matures and as new game types, casino architectures, and adversarial vectors are encountered; every change is recorded in the version history below. Each audit states the methodology version it was conducted under. Audits remain valid under the version in effect at the time of certification; annual renewals and re-audits are conducted under the current version.
Current version: v1.0 · Published June 2026
Version
Published
Status
Summary
v1.0
June 2026
Current
Initial public release. The standard applied across the launch audit suite.