This page explains how we audit 100% RTP, zero-edge and fair-return casino claims. It exists so readers can understand why one claim is marked strong, another is treated cautiously, and another remains pending until more data is available.
Our goal is not to assign generic star ratings. The goal is to identify what can be verified, what is only operator-stated, and what still needs live testing, paytable extraction or platform documentation.
Core principle: game fairness, RTP, allowance terms and platform safety are separate layers. A casino game can be provably fair and still have a house edge. A game can advertise 100% RTP and still have caps, variance, KYC risk or withdrawal caveats.
What We Audit
| Audit Layer | What We Check | Typical Evidence |
|---|---|---|
| Game math | Whether the payout formula, multiplier table or paytable supports the stated return. | Dice multiplier, Mines survival formula, Plinko lane probabilities, Keno match probabilities. |
| Provably fair verification | Whether a completed outcome can be reproduced from server seed, client seed, nonce and the platform algorithm. | Seed hash match, HMAC output, reproduced Dice roll, Crash point or Mines layout. |
| Allowance and limits | Which wager volume qualifies for fair or near-fair pricing, and what happens after the limit. | Daily allowance, per-bet cap, reset timer, post-cap RTP, max-win cap. |
| Platform model | Whether the return is native, hybrid, reward-adjusted, token-based or capped by payout limits. | Operator terms, in-game tracker, help-center wording, reward rules. |
| Platform risk | Licensing, KYC rights, withdrawal caveats, operator history and dispute exposure. | Terms of service, footer entity, license display, public support/withdrawal signals. |
Evidence Levels
We do not give every claim the same confidence level. A visible multiplier that matches a known formula is stronger than a marketing statement. A completed seed reproduction is stronger than a generic “provably fair” label.
| Evidence Level | Meaning | Example |
|---|---|---|
| Independently verified | We can reproduce or calculate the result from available math, paytable data or seed inputs. | A Dice multiplier matching 1 / win chance; a Mines board reproduced from seed data. |
| Formula-level verified | The probability model is confirmed, but the live payout table or full distribution still needs extraction. | Plinko binomial lane probabilities; Keno hypergeometric match odds. |
| Rules-supported | The in-game rules or paytable support the claim, but a complete engine or distribution audit has not been completed. | A slot rules screen stating 100% RTP without full symbol-weight modeling. |
| Operator-stated | The operator makes the claim, but we have not independently verified the complete mechanism. | Unconfirmed post-cap rate, unpublished deck model or platform-level return language. |
| Pending | The claim exists, but the available information is insufficient to confirm or reject it. | Missing paytable, missing seed algorithm, unresolved live-game verification. |
How We Verify RTP Claims
RTP is a payout-design question. It is not proven by a provably fair badge alone.
Simple Probability Games
For games such as Dice, Mines, Plinko and Keno, we start with the probability model.
- Dice: fair multiplier should equal 1 / win chance.
- Mines: fair multiplier should equal the inverse of survival probability.
- Plinko: lane probabilities and lane multipliers should sum to the stated return.
- Keno: match probabilities and match payouts should sum to the stated return.
If the game displays the relevant payout table, the math can often be checked directly. If the table is not visible or is rounded, the confidence level is lower.
Distribution-Based Games
For Crash and similar games, RTP depends on the bust-point distribution, edge factor, instant-bust rule and rounding method. A fair reference model may be simple, but the exact platform implementation still matters.
For that reason, we separate model plausibility from full distribution verification.
Strategy-Dependent Games
Blackjack and video poker are not automatic-return games. Their theoretical return depends on rules and player decisions.
- Blackjack: deck model, dealer rules, blackjack payout, surrender, double and split rules affect base return.
- Video Poker: paytable and optimal hold strategy determine RTP.
A headline RTP claim is not enough for these games. We need the exact rules, paytable and strategy assumptions.
Slot-Style Games
Slot-style games require the deepest audit. A full RTP check may require symbol weights, grid behavior, tumble rules, feature frequency, bonus distribution, multiplier behavior and max-win treatment.
If only the rules screen is available, we may mark the claim as rules-supported rather than independently verified.
How We Verify Provably Fair Claims
Provably fair verification checks whether a completed result can be reproduced from committed randomness. It does not prove RTP by itself.
| Step | What We Check | Why It Matters |
|---|---|---|
| Server seed commitment | The revealed server seed hashes to the pre-bet server seed hash. | Shows the seed was committed before the result was revealed. |
| Input set | Server seed, client seed, nonce and any game-specific input are available. | Missing inputs prevent independent reproduction. |
| Algorithm match | The platform’s encoding, HMAC format, conversion and rounding are known. | Small implementation differences can produce different results. |
| Outcome reproduction | The reproduced result matches the game history. | Supports round-level integrity for the tested result. |
| Scope caveat | We identify what the check does not prove. | PF does not prove RTP, withdrawals, regulation or future outcomes. |
Where possible, we use the Provably Fair Checker to reproduce supported outcomes. If a game has a claimed verifier but no completed test has been performed, we mark that clearly.
What Provably Fair Does Not Prove
| Claim | Can PF Prove It? | What Is Needed Instead? |
|---|---|---|
| The result was generated from committed seed data. | Yes, if the implementation is known and inputs match. | Seed hash, client seed, nonce and platform algorithm. |
| The game has 100% RTP. | No. | Payout formula, paytable or distribution audit. |
| The casino will process withdrawals reliably. | No. | Operational history, terms, limits and small withdrawal tests. |
| The platform is strongly regulated. | No. | License verification and jurisdictional review. |
| The next result is predictable. | No. | Nothing legitimate; prediction claims should be treated as scams. |
How We Review Allowance Models
Many fair-return products are not unlimited. They use caps, trackers, post-cap pricing or max-win constraints. These terms are part of the RTP audit.
| Limit Type | What We Look For | Why It Matters |
|---|---|---|
| Daily wager allowance | Eligible volume, reset period and visible tracker. | Defines how much play receives the advertised pricing. |
| Per-bet cap | Maximum stake eligible for fair or near-fair pricing. | Large bets may not qualify. |
| Post-cap pricing | RTP or house edge after the allowance is used. | High-volume players may spend much of their play outside the fair window. |
| Max-win cap | Maximum payout per bet or round. | Can reduce effective RTP if fair payout would exceed the cap. |
| Eligible game list | Which games qualify and which do not. | Fair-return claims rarely apply to every product on the platform. |
How We Classify Casino Models
We separate platform models because similar marketing language can describe different economics.
| Model | Definition | Audit Focus |
|---|---|---|
| Native fair pricing | The visible game payout formula is calibrated to fair value. | Probability and multiplier table. |
| Allowance-based fair play | Fair pricing applies up to a defined wager volume. | Tracker, cap, reset and post-cap edge. |
| Hybrid return model | Base RTP, rewards and instant returns combine to reduce cost. | Base game RTP and reward-layer mechanics. |
| Rakeback model | The game has an edge, and part of the theoretical margin is returned. | Base edge, refund percentage and eligibility. |
| Lossback model | The platform refunds part of actual net losses. | Calculation period, exclusions and withdrawal conditions. |
| Token reward model | Return depends partly on reward tokens. | Token value, liquidity, volatility and redemption rules. |
How We Handle Conflicting Information
Operator wording can change. Help centers, promotional pages, older blog posts and third-party reviews may disagree. When that happens, we avoid forcing a false certainty.
Our order of preference is:
- Live game interface when visible to the player.
- Current operator help center or terms when clearly dated or actively maintained.
- Current in-game rules screen for paytables and feature rules.
- Independent reproduction from seeds, formulas or calculators.
- Third-party reviews only as supporting evidence, not as final proof.
- Older operator announcements treated cautiously if newer pages conflict.
If the conflict cannot be resolved, we say so and mark the item as requiring live verification.
Affiliate Independence
100RTP.games may earn revenue from affiliate links. That revenue helps fund research, hosting, tools and editorial work.
Affiliate relationships do not determine evidence levels. A partnered operator can still receive caveats, pending labels or negative findings. A non-partner platform can still be discussed if it is relevant to the topic.
Our editorial position is that affiliate links should not change the math. If a game is 99%, it is 99%. If a paytable is missing, it is missing. If a claim is unverified, it remains unverified regardless of commercial relationship.
Update Policy
Casino terms, paytables and allowance rules can change. We update pages when new evidence appears, when operator documentation changes, or when reader/game data exposes a correction.
Typical reasons for updates include:
- New or changed paytable.
- Updated allowance cap or reset rules.
- New post-cap pricing.
- Changed help-center wording.
- New provably fair algorithm information.
- Correction of a mathematical or editorial error.
- New tool output or live verification result.
Where a page contains time-sensitive operator data, readers should verify current live terms before making decisions based on the information.
Reader Corrections
We welcome corrections, especially when they include verifiable data.
Useful correction evidence includes:
- Current in-game paytable screenshot.
- Rules screen showing RTP or feature details.
- Seed data and completed bet output for verification.
- Help-center URL showing updated terms.
- Operator response clarifying cap, reset or post-limit behavior.
Do not send private keys, wallet seed phrases, passwords, active unrevealed server seeds or personal identity documents. For contact options, see Contact.
Responsible Gambling Context
Mathematical fairness does not make gambling safe. A 100% RTP game can still produce losing sessions and bankroll loss. Variance, bet size and player behavior remain important.
Our guides and tools are designed to explain risk, not to encourage more gambling. See Responsible Gambling for warning signs and support resources.
Bottom Line
Our methodology is conservative by design. We verify what can be verified, label operator-stated claims, and leave unresolved items marked as pending until stronger evidence is available.
The central rule is simple: a claim is only as strong as the evidence behind it. For 100% RTP and zero-edge games, that evidence must include more than marketing language. It must include math, paytables, allowance terms, verification paths and platform-risk context.