Audit framework
Framework v1.0
Framework v1.0Our 5-point audit methodology
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, RNG algorithm, game logic, payout structure and advertised RTP must all be independently verifiable.
ProvablyFair.org defines and enforces that standard. We place thousands of real bets, independently recompute every outcome from the published algorithm, and verify that the results match exactly. We then run tens of millions of simulated rounds to confirm the stated odds.
The repo is the credential
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.
Every audit answers five questions
01Can the casino change your outcome after you bet?
We verify the cryptographic commitment that locks the result before you play.
02Is the randomness real?
We independently implement the algorithm and prove your seed genuinely affects every outcome.
03Does the game follow its own rules?
We recompute every bet in our dataset. 100% must match. Zero tolerance.
04Is the house edge honest?
We mathematically prove the RTP from first principles, never trusting the casino’s own numbers.
05Does 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.
How the audit follows a live outcome
ProvablyFair.org captures Duel's live outcomes and re-derives every one independently.
Framework overview
Five scored checks. Two required transparency deliverables.
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.
Claims require proof, and proof requires evidence that anyone can independently verify.Cryptographic foundations
A single failure means the game cannot be provably fair by definition.
Game logic & integrity
Proves the payout model and tests implementation integrity.
Required transparency
Not scored, but required for certification.
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 & audit boundaries
What the framework covers, and what each audit operates on.
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
Client seed + server seed
Hash chain
Server seed + external beaconExamples of games covered
Each entropy model is verified using the same S1–S5 structure, with model-specific adaptations documented in the Operator Trust Analysis. External beacons include drand and block hashes.
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
- Game logic & RNG specification
- API responses & published seeds
- Bet histories & live game behaviour
- Independent implementation & verification
Game logic & RNG specification
Bet histories & live game behaviour
Independent implementation & verificationOperators 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. These 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).
Outside this framework
Outside this frameworkThe audit covers fairness and cryptographic integrity of provably fair game outcomes. It does not cover:
- − Platform & infrastructure security
- − Licensing or regulatory compliance
- − Fund custody
- − Responsible gambling practices
- − Withdrawal processing
- − Anti-money laundering controls
- − Fairness of non-provably fair games
Technical methodology
Each layer is independently verified. Expand a section to read the full methodology.
01Seed, Nonce & DeterminismCan 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).
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.
What it proves
Hard fail criteriaAny 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)
Seed hash mismatch (any epoch)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.
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.
02RNG & Entropy ModelIs 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).
- 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
03Verifier ParityDoes 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
- Phase D: Client seed variation (multiple distinct client seeds across configs)
- 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.
- Any outcome mismatch between independent recomputation and recorded result
- Payout arithmetic error exceeding 1e-8
04RTP & Payout LogicIs 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.
- 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)
05Fairness Integrity TestingDoes 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).
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.
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.
06Player VerificationCan a player verify their own bets without trusting anyone?Required
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.
07ReproducibilityCan anyone independently reproduce every finding in this audit?Required
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 testor 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.
Standards & lifecycle
Verdict rules, coverage requirements and the responsibilities behind certification.
Verdict FrameworkPass, conditional pass and hard-fail rulesGovernance
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 ModelsPre-commitment guarantees and residual trustGovernance
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 comparison
Client Seed + Server Seed
- Architecture
- Server commits a seed hash. Player sets a client seed. Outcome depends on both.
- Pre-Commitment Control
- Casino controls server seed but not client seed.
- Cherry-Pick Risk
- Low — constrained by player-contributed entropy the casino cannot predict.
- Verdict Impact
- Full Pass eligible
Hash Chain
- Architecture
- 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.
- Pre-Commitment Control
- Casino selected the chain at generation time. Once committed, individual rounds cannot be altered.
- Cherry-Pick Risk
- 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.
- Verdict Impact
- Full Pass eligible
Server Seed + External Beacon
- Architecture
- 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.
- Pre-Commitment Control
- Casino controls server seed but the external beacon value is unpredictable and independently verifiable.
- Cherry-Pick Risk
- Lowest — casino cannot pre-select outcomes because the beacon value is unknown at commitment time.
- Verdict Impact
- Full Pass eligible
Server Seed Only
- Architecture
- 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.
- Pre-Commitment Control
- Casino has full control over every outcome before committing. Each round is independently selectable with full foreknowledge of the result.
- Cherry-Pick Risk
- 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.
- Verdict Impact
- 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:
- Client seed games: revealed seeds × 10,000 nonces, multi-window analysis.
- 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 RequirementsBaseline, repository access and minimum coverageGovernance
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 & RevocationRenewal, monitoring and failure responseGovernance
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.
| Event | Action |
|---|---|
| Initial audit | S1–S7 executed. Verdict issued. Repo published. Badge activated. |
| Ongoing (within certification year) | Unlimited game change re-checks and delta re-audits included. Spot checks (when operational). Player verification layer active. |
| Game update by operator | Operator notifies ProvablyFair.org. Delta re-audit of affected sections. Updated repo published. |
| Annual renewal | 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.
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 & VersioningPublic reproducibility, conflicts and version historyGovernance
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. |