Our Methodology

TL;DR: We don't trust casinos. We don't trust claims. We test raw cryptographic output against established statistical standards — all 15 tests from NIST SP 800-22 plus 4 additional statistical tests — using 50,000 to 100,000+ rounds per game. For deep audits, we add PractRand, Fourmilab ENT, Dieharder, and TestU01 — and we publish all results, including the ones that fail due to dataset limitations. Every dataset is published. Every test is reproducible. If you can do math, you can check our work.

Why This Page Exists

I spent years working as a pit boss in land-based casinos. I watched players lose money, sure — but they could see the wheel spin. They could watch the cards being dealt. Trust wasn't blind. It was built into the physical process.

Online crypto casinos removed all of that. They replaced it with a promise: "It's provably fair."

Here's the problem — provably fair proves integrity, not fairness. A casino can pass every hash check and still rig outcomes through seed timing exploits. That's not theory. That's a documented vulnerability with working proof-of-concept code.

So we built something different. A testing framework that doesn't care what the casino says. It only cares what the numbers show.

What We Actually Test

Raw Floats, Not Game Results

This is the most important architectural decision we made — and it's the same one used by GLI and eCOGRA, the gold standard in regulated gambling.

Every provably fair game works the same way under the hood:

HMAC-SHA256(server_seed, client_seed:nonce:round) ? 32 bytes ? float [0,1) ? game result

Dice, Crash, Limbo, CoinFlip, Roulette — they all start from the same raw uniform float. The game result is just a deterministic transformation of that float. If the source bytes are uniformly distributed, the RNG is producing genuinely random output — a necessary condition for game fairness.

We test the source. Not the transformation.

Why? Because testing game results introduces noise from the transformation function itself. A crash multiplier distribution should look skewed — that's by design. But the underlying bytes should be perfectly uniform. Testing at the byte level is cleaner, more powerful, and catches manipulation that game-level tests would miss.

Scope: What Statistical Testing Proves — and What It Doesn't

Transparency matters. Before diving into our test suites, here's exactly what our statistical analysis can and cannot prove.

What Our Tests Prove

• The RNG output is statistically random. No detectable patterns, bias, or predictability in the output stream.
• The observed distribution matches the expected distribution. If Dice claims uniform outcomes across 0—100, we verify that mathematically.
• No evidence of outcome shaving. If a casino subtly reduces payouts by 0.5%, our sample sizes are large enough to detect it.
• No drift or degradation over time. The RNG performs consistently across the full dataset, not just in short bursts.

What Our Tests Do Not Prove

• We do not verify game logic implementation. A game could have a perfect RNG but a broken or manipulated payout formula. Game logic verification is a separate discipline.
• We do not prove that client seeds are used in the calculation. A casino could accept your client seed and silently ignore it. Verifying this requires code-level or cryptographic auditing, not statistical testing.
• We do not prove that server seeds aren't pre-selected. A casino could theoretically generate multiple server seeds and pick favorable ones. Our tests detect the statistical fingerprint of this if done at scale, but not single-instance manipulation.
• We do not audit the seed commitment process itself. Whether the pre-committed hash was genuinely locked before your bet is a cryptographic verification question, not a statistical one.

Bottom line: Statistical testing and game logic verification are two fundamentally different protection layers. They are complementary — not competing, not redundant. We focus on the mathematical side: is the RNG output genuinely random and unbiased? For a complete picture of casino fairness, both approaches are needed. We are transparent about this because intellectual honesty is non-negotiable.

Why Statistical Testing Is a Separate Protection Layer

Game logic verification confirms that the code does what the specification says. Statistical testing confirms that the output is genuinely random. These are different questions with different answers — and a casino can fail one while passing the other.

Consider a concrete example: a casino implements its game logic perfectly — every payout formula is correct, every hash matches, every verifier confirms. But the server seeds were not generated randomly. They were selected from a pre-computed pool that slightly favors the house. The code is flawless. The game logic passes every review. But the outcomes are biased. Only statistical testing on large sample sizes catches this.

The reverse is also true: a perfect RNG does not prove correct game logic. A casino could feed genuinely random numbers into a broken payout formula. That is why we explicitly state our scope — and why both disciplines exist.

Manipulation scenarios that only statistical testing detects:

• Seed pre-selection at scale. Generating thousands of seed candidates and keeping only those that produce house-favorable sequences. The code is correct — the input is rigged.
• Outcome shaving. Subtly shifting the distribution by 0.3—0.5% — invisible to individual players, invisible to code review, but detectable across 100,000+ rounds through chi-square and distribution tests.
• RNG degradation over time. A system that starts fair but develops patterns after millions of rounds — detectable through autocorrelation and spectral analysis, not through code inspection.
• Nonce manipulation. Holding the nonce at zero or cycling through a small set of nonces to reuse favorable outcomes. The hash chain looks correct — but the statistical fingerprint reveals the repetition.

No code review catches these. No game logic reconstruction catches these. Only math on large datasets does. That is our lane — and we stay in it because doing one thing at rigorous depth is more valuable than doing everything at surface level.

Cryptographic End-to-End Reproduction

Statistical testing answers one question: are the outcomes random? It cannot answer a second, equally important one: did each specific round follow the casino's own published formula, from a seed fixed before you played? For provably-fair games that second question has the stronger answer — and it's not a sample. Where a game publishes its algorithm and seeds, we don't estimate; we recompute every round we can and check it byte-for-byte against the recorded result.

How it works

A provably-fair crash game derives each round's multiplier deterministically from two inputs: a secret server seed (revealed after the round) and a public client seed. The casino commits to the server seed in advance and fixes the client seed publicly, so nothing can be altered after a bet is placed. We take the casino's own published formula and recompute the outcome — for example, Blaze's:

hash  = HMAC-SHA256(key = server_seed, message = client_seed)
if  int(hash[0:13],16) % 15 == 0   ->  crash = 0.00   (instant bust)
else  h = int(hash[13:26],16);         crash = floor((100·2^52 − h)/(2^52 − h))/100

(This is the current formula generation — Blaze has used two over time; see “Formula generations” below.)

If our recomputed value equals what the game actually showed, that round is verified: the outcome was pre-determined and untampered. We repeat this for every round whose inputs are public. On our Blaze Crash audit that meant recomputing 1,156,220 of 1,457,364 rounds (79.34%) with zero mismatches.

The anchor: a public, unforgeable seed

Reproduction only means something if the public client seed can't be gamed. The strongest designs use the hash of a specific Bitcoin block, fixed before the rounds are played. A Bitcoin block hash is public, permanent, and impossible to predict or forge — not even by the casino. Anyone can look it up at a block explorer and confirm it matches. Remove that anchor and reproduction proves far less; keep it, and every round with a published seed becomes independently checkable.

In plain terms: the casino pre-prints millions of results in a sealed book (and publishes a fingerprint of it up front), then stamps every page with a public number it couldn't control — a Bitcoin block that didn't yet exist when the book was printed. Because that number only arrived after the book was sealed, it couldn't have stacked the pages against you.

Formula generations

Casinos sometimes change the exact byte-level derivation between game generations. We don't assume one version — we identify each empirically and reproduce it exactly. On Blaze Crash we found and confirmed two distinct formula generations, each matching 100% of its rounds. Reproducing both is how you know the math was actually run, not copied from a blog.

Do it yourself — no trust required

Every input is public and every step is repeatable:

• One round, in your browser: our client-side Blaze Crash Verifier runs the exact math above — no server, view the source, works offline.
• The whole dataset, one command: the data, checksums, reproduction script, and the casino's own verifier code are published in our open repository. Download it and re-derive the numbers yourself.

What it proves — and what it doesn't

Cryptographic reproduction proves that verified rounds followed the published formula from a pre-committed seed: no post-hoc tampering, no rigged individual outcomes. It does not, by itself, tell you the price of the game (the house edge) or whether the long-run distribution is unbiased — that's what the statistical layer and the payout analysis add. And where the seed for an older or unlisted game chain is no longer publicly retrievable, some rounds simply can't be reproduced; we report exactly how many we verified rather than implying full coverage. The two layers are complementary: cryptography proves integrity round by round; statistics prove fairness across many. A complete audit needs both.

Five Testing Frameworks, One Verdict

We don't rely on a single test or a single framework. We run up to five independent, complementary test suites — and we document every result honestly, including limitations:

Framework 1: NIST SP 800-22 Rev. 1a — Complete Suite

The National Institute of Standards and Technology published SP 800-22 as the standard for evaluating random and pseudorandom number generators. It's what governments, military contractors, and financial institutions use to certify their cryptographic systems.

We run the complete battery — all 15 tests. Not a subset. Not a "simplified version." The full thing.

Each test produces a p-value. We use a significance level of ? = 0.01 (99% confidence). A p-value below 0.01 means the output deviates from randomness more than chance alone would explain.

A note on multiple testing: Running 19 tests at α = 0.01 means roughly 1 in 100 tests may fail by chance alone. NIST SP 800-22 Section 4.4 explicitly addresses this concern: their analysis shows “the degree of duplication among the tests seems to be very small,” and they do not recommend Bonferroni or other multiple-testing corrections. We follow NIST’s approach: each test is evaluated independently at α = 0.01, and the overall verdict is based on the proportion of tests passed, consistent with Section 4.2.1 of the standard.

Additional Statistical Tests

Beyond NIST, we run four more tests from standard statistics — different mathematical lenses on the same data:

Framework 2: PractRand

NIST is the industry standard. PractRand is widely considered the most demanding PRNG test suite available.

Developed by Chris Doty-Humphrey, PractRand is widely regarded as the most demanding PRNG test suite in existence. Where NIST tests might pass a mediocre generator, PractRand will tear it apart.

PractRand works differently from NIST. It consumes a raw binary stream and runs progressively harder tests at increasing data volumes — from kilobytes to terabytes. It doesn't just check for bias. It hunts for subtle correlations, periodicities, and structural weaknesses that standard tests miss entirely.

If NIST is the baseline, PractRand goes deeper. It finds structural weaknesses you didn't know were there.

We convert casino outcomes into raw binary streams and feed them directly into PractRand. A generator that passes both NIST and PractRand is, for all practical purposes, indistinguishable from true randomness.

Framework 3: TestU01 (BigCrush)

TestU01 is the academic gold standard, developed at the Université de Montréal. Its BigCrush battery runs 106 statistical tests over 3—4 hours — the most comprehensive single-run analysis of a random number generator that exists in peer-reviewed literature.

Where NIST gives you the government stamp and PractRand hunts for subtle structural flaws, BigCrush throws everything academia has developed over decades at your data. If a generator survives all three, there is no known statistical method that could distinguish it from true randomness.

Framework 4: Fourmilab ENT

ENT is a lightweight entropy analysis tool created by John Walker (Autodesk founder) in 1998. It runs five independent metrics on any binary file: Shannon entropy, chi-square distribution, arithmetic mean, Monte Carlo pi estimation, and serial correlation coefficient.

ENT serves as an independent cross-check. It uses completely different mathematics from NIST, PractRand, and TestU01 — providing a fourth independent lens on the same data. A dataset that passes ENT with entropy of 8.000000 bits per byte and near-zero serial correlation is, by any reasonable measure, indistinguishable from true randomness at the byte level.

Framework 5: Dieharder

Dieharder (Duke University, maintained by Robert G. Brown) extends George Marsaglia's original Diehard battery to 200+ tests. It is the largest single test battery available and is widely used in academic PRNG evaluation.

Important limitation: Dieharder is designed for unlimited PRNG streams and ideally requires 3-10 GB of data. When run on finite historical datasets (even 960 MB), it rewinds the file repeatedly, which can cause false failures from artificial periodicity. Additionally, certain tests (notably marsaglia_tsang_gcd) are known to fail for all SHA-256 and HMAC-SHA256 based generators — this is a structural property of cryptographic hash functions, not a fairness issue. We run Dieharder for completeness and document both genuine passes and expected structural failures transparently.

Ultra-Audit: Full Framework Validation

To validate our methodology before going public, we ran all five frameworks against Bustabit's complete hash chain — 30 million HMAC-SHA256 outputs (960 MB of binary data). This is the largest independent RNG validation ever performed on a crypto casino's provably fair system.

What We Tested

Bustabit publishes its complete hash chain: 10 billion+ SHA-256 hashes with a known terminating hash and salt. We generated 30 million HMAC-SHA256 outputs — the actual game result layer, not the raw hash chain — and fed them into all five frameworks.

Why HMAC outputs, not raw hashes? The raw hash chain (SHA256 to SHA256 to ...) has inherent structural correlations — each hash is derived from the previous one. That is by design. But the game results use HMAC-SHA256(salt, game_hash), which decorrelates the chain through the salt. Testing the HMAC layer tests what players actually experience.

Results

Honest Analysis: Why BigCrush Shows Failures

TestU01 BigCrush ran for 3 hours 11 minutes and consumed 357 billion uint32 reads — equivalent to approximately 1.3 terabytes of data. Our file contains 960 MB. The file was rewound 1,487 times during testing.

This means BigCrush read the same 960 MB of data nearly 1,500 times in sequence. Every test that examines long-range correlations detected the artificial periodicity created by this wrap-around — not a flaw in the data, but a mathematical consequence of reading a finite file in a loop.

The failures span all major test families: RandomWalk (20 failures), HammingIndep (6), WeightDistrib (6), CouponCollector (4), Gap (4), SimpPoker (4), Fourier3 (2), and others. This broad distribution across unrelated test types is the signature of wrap-around artifacts, not targeted manipulation. A genuinely biased RNG would show failures in specific statistical properties, not uniformly across every test family.

BigCrush is designed for unlimited PRNG streams — algorithms that can generate data on demand, forever. It was never designed for finite historical datasets. Our 960 MB (30 million game rounds) is the largest dataset ever tested from a crypto casino, but BigCrush needs approximately 1.3 TB. We ran it anyway, because transparency means showing what happens when you push the limits — not hiding inconvenient results.

Honest Analysis: Why Dieharder Shows 4 Failures

Dieharder's 4 failures come from two sources:

• marsaglia_tsang_gcd (2 failures): This test is known to fail for all SHA-256 and HMAC-SHA256 based generators. It detects a structural property of cryptographic hash functions — the GCD distribution of hash outputs differs from true random integers. This is documented in academic literature and affects every hash-based PRNG, not just casino implementations.
• rgb_lagged_sum at specific lags (2 failures): At lags 19 and 23, the HMAC output shows subtle correlations. Notably, lag 15 — which failed on the raw hash chain — passed on the HMAC layer, confirming that the salt decorrelation works. The remaining lag failures are consistent with known properties of HMAC-SHA256 at those specific offsets.

The 8 WEAK results are within expected statistical variance — at alpha = 0.01, roughly 1-2% of tests are expected to show borderline results by chance alone.

What This Proves

The three frameworks appropriate for our dataset size — NIST, PractRand, and SmallCrush — show 100% PASS rates. Zero anomalies. Zero failures. Across 263 independent statistical tests.

The two frameworks designed for larger datasets — BigCrush and Dieharder — show failures that are entirely explained by data size limitations and known SHA-256 structural properties. No failure points to manipulation.

We publish this analysis in full because anyone claiming "BigCrush failed" without understanding why is either uninformed or dishonest. The raw output files are available on request for independent verification.

Dataset Size Requirements

We run all six test batteries regardless of data size because transparency demands it. But we classify results honestly: frameworks that received adequate data get a definitive verdict. Frameworks that did not get enough data get an explanation of why. Hiding the BigCrush results would be easy — and dishonest. Publishing them with context is harder — and correct.

Audit Tiers

Not every audit needs the same depth. We run two tiers:

Standard Audit (Every Report)

Every published audit report runs through our 19-test core battery plus game-specific validation:

• 15 NIST SP 800-22 tests (complete suite)
• 4 additional statistical tests (Chi-Square, K-S, Serial Correlation, Runs Up/Down)
• Game-specific validation tests (varies by game type — typically 1–2 per game)

This already exceeds what any competitor runs. It covers everything a well-implemented provably fair system should pass.

Deep Audit (On Request)

For casinos that want to prove they’re beyond reproach — or players who need absolute certainty — we go further:

• PractRand — progressive binary stream analysis, from kilobytes to terabytes
• TestU01 BigCrush — 106 academic-grade tests, 3—4 hour runtime

A Deep Audit is available on request. We run it when the stakes are high, the dataset is large, or someone challenges our findings. Five independent scientific frameworks, zero overlap in methodology, one verdict.

NIST is the baseline. PractRand, ENT, Dieharder, and TestU01 go deeper. Most audits only need the standard battery — but when the data warrants it or a casino requests maximum scrutiny, we run all three frameworks.

Game-Specific Validation

On top of the raw-float analysis, we run game-specific tests on the actual outcomes. These verify that the transformation from raw float to game result is implemented correctly — a casino could have a perfect RNG but a broken game formula.

Total: 19 core statistical tests per audit, plus game-specific validation (1–2 tests per game type) — 15 NIST + 4 additional statistical + 6 game-specific. For Deep Audits, add PractRand and TestU01 BigCrush (106 additional tests) on top.

Sample Sizes

We don't do spot checks. Our target sample size is 100,000+ rounds per game, though some audits start with smaller datasets. Audits with fewer than 100,000 rounds are marked as preliminary — statistically indicative but below the NIST-recommended minimum of 10⁶ bits. They still provide a useful signal, especially when clustered across multiple game types (e.g., 5 games × 50,000 rounds = 250,000 total data points). We always disclose the exact sample size. Some preliminary audits begin at (50,000–75,000 rounds) when data availability is limited — we always disclose the exact sample size. For major audits, we go to 250,000 or more. Our Bustabit audit analyzed 100 million rounds.

Why does sample size matter? Because small samples hide manipulation. A rigged coin that lands heads 52% of the time looks normal after 100 flips. After 100,000 flips, the bias screams. Statistical power increases with sample size — and we use enough data to detect deviations as small as 0.1%.

Data Integrity

Every audit report includes:

• SHA-256 dataset hash — cryptographic proof that the data hasn't been altered after testing
• Complete seed parameters — server seed, client seed, nonce range
• Reproducibility instructions — step-by-step guide so anyone can regenerate our results
• Raw data download — the actual outcomes as JSON, available for independent verification

We don't ask you to trust us. We give you the tools to verify us. That's the difference between an audit and an opinion.

What We Don't Do

Transparency means being honest about limitations too:

• We don't verify game logic or code implementation. Our scope is statistical analysis of RNG output. Whether the game code correctly implements its published specification is a separate audit discipline that requires source code review or independent game reconstruction.
• We can't test live server behavior in real-time. We audit historical data. A casino could theoretically behave differently for specific players or time periods. Statistical analysis catches systematic manipulation, not targeted single-round rigging — that’s exactly what the cryptographic layer catches instead (see “Cryptographic End-to-End Reproduction” above).
• We don't audit smart contracts. On-chain games with published Solidity code are a different beast. Our focus is HMAC-SHA256 based provably fair systems.
• We don't guarantee future fairness. An audit is a snapshot. That's why we advocate for continuous monitoring and regular re-audits.
• We don't test withdrawal speed or customer support. Our scope is mathematical fairness. For business practices, read why math alone isn't enough.

The Scoring System — RNG Audit Score

Each audit produces a FairPlay Score from 0 to 10:

Important: The FairPlay Score reflects RNG randomness and statistical integrity only. It does not cover game logic implementation, payout formula correctness, or the seed commitment process. A casino can score 10/10 on RNG quality and still have issues elsewhere. This score answers one question: is the random number generator producing genuinely unbiased output? For the full picture, RNG auditing and game logic verification are both needed — we do the math side.

The score is calculated as: (passed tests / total applicable tests) × 10. For example, passing 19 out of 19 tests = 10.0. Passing 17 out of 19 = 8.9. This is deliberately simple and transparent — no hidden weighting, no subjective adjustments. The raw pass/fail for every individual test is published in each audit report.

Longitudinal RNG Monitoring — The Consistency Comparator

A single audit tells you one thing: the RNG was fair on that day. But what about next week? Next month? What if a casino passes our 19-test battery in June, then quietly changes something in July?

This is the gap that nobody in the industry addresses. Traditional provably fair verification — including our own standard audit — is a snapshot. It tells you the state of the RNG at one point in time. It cannot tell you whether things changed after the audit.

The Consistency Comparator solves this.

How It Works — In Plain English

Imagine you fill two jars with marbles from the same machine. If the machine is consistent, both jars should look roughly the same — similar colors, similar ratios, similar randomness. If you open the second jar and suddenly find twice as many red marbles, something changed.

That’s exactly what the Consistency Comparator does with casino data:

Phase A: We collect a large sample of game outcomes — say, 100,000 rounds of Crash. We run our full test battery. We save the results.

Phase B: Weeks or months later, we collect another 100,000 rounds from the same game. Same casino, same game type — but fresh data from a new anonymous account.

Then we compare.

The Comparator runs seven independent statistical tests between Phase A and Phase B. Each test looks at the data from a different angle — distribution shape, average values, spread, information content. If all seven agree the data looks consistent, the casino gets a high Consistency Score. If the tests detect a shift, the score drops — and we know something changed.

The Seven Comparison Tests

You don’t need a math degree to understand what each test checks:

1. Kolmogorov-Smirnov Test — Do the two samples follow the same overall pattern? Think of it as overlaying two graphs and checking if they match.

2. Chi-Square Homogeneity — If you sort outcomes into buckets (0-10%, 10-20%, etc.), do both samples fill the buckets the same way?

3. Jensen-Shannon Divergence — An information theory measure. How surprised would you be if you thought the data came from Phase A, but it actually came from Phase B? Low surprise = consistent.

4. Welch’s t-Test — Are the average outcomes the same? A rigged game that shaves 1% off high payouts will shift the average.

5. F-Test — Is the spread (variance) the same? A tighter or looser distribution over time signals a change in the RNG.

6. Cohen’s d — Even if a difference is statistically real, is it big enough to matter? This separates meaningful changes from noise.

7. Bhattacharyya Distance — A geometric measure of how much two distributions overlap. Perfect overlap = identical behavior.

The Consistency Score

All seven tests feed into a weighted Consistency Score from 0 to 10:

9—10: CONSISTENT — No detectable change. The RNG behaves the same as before.

8—9: STABLE — Minor statistical fluctuations within normal range.

6—8: DRIFTING — Some tests flag differences. Could be natural variance, could be early signs of a change. Warrants closer monitoring.

4—6: CONCERNING — Multiple tests detect shifts. Something likely changed in the RNG or game configuration.

0—4: DIVERGENT — The data looks fundamentally different. Strong evidence of RNG manipulation or replacement.

Detection Sensitivity

In our validation tests:

A 0.5% outcome shave — barely noticeable to any individual player — drops the Consistency Score from 9.4 to 5.6 (CONCERNING). A 2% manipulation drops it to 2.6 (DIVERGENT). With 100,000+ samples, there is nowhere to hide.

Why This Changes Everything

Traditional audits have a fundamental weakness: the casino knows it’s being tested. If you announce an inspection, you’ll find a clean kitchen. Our approach uses anonymous accounts — the casino doesn’t know which player is collecting data for a monitoring run.

This means:

A casino can’t ‘perform’ for the auditor and then change behavior afterward. If the RNG drifts, degrades, or gets manipulated between monitoring periods — we catch it. Not because someone reported a problem. Not because we got lucky. Because the math doesn’t lie, and we’re always watching.

The Consistency Comparator is source-available under BSL 1.1, like the rest of our tools: gitlab.com/fairplay-audit/provably-fair-audit.

Why One Audit Isn't Enough

A single audit proves fairness on one day. That's it.

Think about it from the casino's perspective. They know an auditor tested their Crash game in June. The report is public. They scored 10/10. Great marketing material. But what happens in July? August? December?

Nothing stops a casino from changing seed generation parameters, swapping RNG implementations, or introducing account-specific behavior after the audit is published. A one-time audit creates a perverse incentive: perform well for the test, then do whatever you want afterward.

This isn't paranoia. It's basic game theory. If the inspection only happens once, the cost of cheating after the inspection is zero.

Longitudinal monitoring removes that safety net. We audit the same casino multiple times over weeks and months, using anonymous accounts the casino can't identify. Each monitoring run is unannounced. The casino doesn't know when we're collecting data, which account is ours, or which game we're testing.

If anything changes between audits — a shifted distribution, a new pattern in the output, a subtle increase in house edge — the Consistency Comparator flags it. Not because a player complained. Because the math caught it.

One audit is a photograph. Longitudinal monitoring is a surveillance camera. Both have their place. But only one catches what happens when nobody's looking.

What You Get

Provably fair verification works on two levels. Both matter. Neither is sufficient alone.

Level 1: Individual Round Verification

Every player can verify their own bets. Export your seeds, paste them into our free verifier, and confirm that the casino calculated your result correctly. This proves cryptographic integrity — the outcome matches the committed hash.

This is necessary. But it only proves that the casino followed its own formula for that specific round. It tells you nothing about the quality of the randomness feeding into that formula, and nothing about whether the casino treats all players equally over thousands of rounds.

Level 2: Statistical Audit Over Time

We verify the big picture. 100,000+ rounds per game, analyzed against 19 statistical tests, repeated over time with the Consistency Comparator. This catches what individual verification cannot:

• Subtle outcome shaving (0.3—0.5% bias invisible to any single player)
• RNG degradation or replacement between audit periods
• Account-specific treatment differences
• Post-audit manipulation

Both Together

Individual verification confirms: my bet was calculated correctly.
Longitudinal statistical auditing confirms: the underlying randomness is genuine and hasn't changed.

One without the other leaves gaps. A player who only checks individual rounds can't detect systemic bias. An auditor who only tests once can't detect post-audit changes. The combination — self-verification plus ongoing independent statistical monitoring — is the most complete protection against manipulated seeds that currently exists in crypto gambling.

We're not claiming perfection. We've listed what our tests don't prove above. But within the domain of RNG statistical analysis, this is as thorough as it gets.

The Deal

FairPlay Audit is funded through affiliate partnerships with the casinos we audit. Here's how that works in practice:

You register at a casino through one of our links. You play normally. The casino pays us a commission on your activity. Standard affiliate model — every casino review site works this way.

The difference: when you sign up through FairPlay, you're playing at a casino under ongoing independent statistical review. Not a one-time check. Not a paid placement. Continuous, unannounced monitoring with published data.

What it costs you: Nothing. Zero. Your odds, payouts, and house edge are identical whether you sign up through us or directly. Affiliate tracking doesn't change game mechanics.

What you get: Access to the same casino you'd use anyway — but with a third party running 19 statistical tests on 50,000–100,000+ rounds, publishing the results, and flagging any changes over time. For free.

What the casino gets: New players and a public, verifiable fairness certification that no marketing budget can replicate.

What we get: Commission that funds more audits, deeper testing, and broader casino coverage.

The incentive alignment is straightforward: we only earn if you play at casinos we've audited. We only maintain credibility if our audits are honest. A rigged audit would destroy the only asset we have. The business model enforces the integrity — not despite the affiliate structure, but because of it.

Full disclosure of all affiliate relationships is published in our Independence & Affiliate Disclosure.

How Verification Methods Compare

None of these methods alone is complete. Self-verification confirms individual rounds. One-time audits confirm RNG quality at a snapshot. Longitudinal monitoring confirms consistency over time. The strongest protection uses all three — and that's exactly what playing through FairPlay gives you.

Source Code Commitment

Repository: gitlab.com/fairplay-audit/provably-fair-audit — Community Edition with 8 core statistical tests. Licensed under BSL 1.1 (converts to Apache 2.0 in 2030).

The Community Edition on GitLab includes 8 core statistical tests (4 NIST SP 800-22 + 4 additional). Our full audit pipeline runs all 15 NIST tests plus 4 additional. The remaining 11 tests represent our competitive advantage and are not published — but we make them available to qualified researchers and critics under appropriate security terms. If you want to verify our full methodology, contact us. The Community Edition is enough to independently verify our published results — if our conclusions are wrong, you can prove it with the source-available tool. You can read the code. You can run it yourself. You can file issues if you find a bug.

This isn't generosity — it's strategy. Publishing the source code means our methodology is under permanent peer review. If our tests are flawed, someone will find it. That pressure keeps us honest. And honestly? That's exactly how it should work.

Not every casino appreciates this level of scrutiny. We’ve documented the seven most common excuses casinos give when asked about independent audits — and why none of them hold up.

Challenge Us

If you think our methodology has a gap, our math is wrong, or our conclusions don't follow from the data — tell us. We publish a standing invitation to challenge any audit we've ever produced. Bring data, not opinions, and we'll respond in kind.

That's the whole point. We're not asking you to believe us. We're asking you to check.