RTPLEDGER
Data & methodology

Data methodology

This page explains how RTP Ledger produces its figures. Each tracked field has a source type and confidence level. Legacy values remain unverified when their source is unknown. RTP Ledger flags suspicious values and leaves missing values blank.

What we collect

RTP Ledger records available data for 2410 slots. The data can include return to player (RTP), RTP ranges, implied house edge, maximum win, volatility, hit frequency, provider, release year, and layout. For Stake Engine games, RTP Ledger also records the mode RTP and event counts from the official catalogue. Casino pages separate sourced facts from unknown information. A blank value means unknown.

Source types

Each tracked provenance field is tagged with the kind of source it came from:

  • Official game rules — the provider's own published rules for a game.
  • Official provider source — a provider's own catalogue or game page.
  • Official API — a first-party data feed, e.g. the Stake Engine catalogue.
  • Independent database — a third-party slot database used for a dated value comparison. A match does not prove separate upstream origins.
  • Legacy import — a value from an earlier bulk import whose per-field origin was not retained.
  • Unknown / undocumented — no source is on record.

RTP Ledger Evidence Status Framework

RTP Ledger calls its field-level source and confidence classification the RTP Ledger Evidence Status Framework. The name describes this public record-keeping system; it is not a game certification, fairness rating or statistical confidence interval. Alongside the source, each tracked provenance field records one of these statuses:

  • official_verified — traced to an official first-party source.
  • secondary_verified — the legacy value matches a dated snapshot from a named secondary database. Because the legacy import's upstream source was not retained, this does not prove two independent origins or mean the provider confirmed the value.
  • observed — a value captured directly under a documented observation method. The field must say whether this was a paytable/configuration capture or a measured realized-return sample; the status alone never means “tracked-spin RTP”.
  • unverified — held on record but not yet matched to qualifying documented evidence.
  • conflict_detected — sources disagree; the raw candidates are retained in internal provenance while the unresolved value is withheld from publishable claims.
  • manual_review_required — the value looked wrong and is pending a human check.

Each available game page shows source and confidence status in its Data status panel. An unresolved primary-RTP conflict keeps the record out of the public slot projection and search publication. A legacy value for another field may remain visible when it is explicitly labelled unverified, but it is excluded from source-qualified rankings and claim schema. The source policy explains how RTP Ledger ranks sources.

How conflicts and suspicious values are handled

  • One source does not silently overwrite another. When they disagree, the conflict and raw candidates are kept in internal provenance while the unresolved value is withheld from publishable claims.
  • A value is only corrected when a documented source proves the correct figure. Otherwise it is set to unknown and marked for manual review.
  • RTP Ledger hides suspicious values or shows them as unknown. Examples include a maximum-win multiplier that is not a whole number and any implausibly low figure.
  • The original value is preserved internally for audit whenever a correction is made.

What the dates mean

  • Retrieved — when a value was first collected.
  • Checked — when it was last verified against a source.
  • Changed — when the value itself last changed.
  • Dataset updated — the most recent real change anywhere in the database.
  • Page modified — the last real content change for that page.

A code or design deploy does not move these dates. They only advance when the underlying data actually changes.

Limitations

  • RTP Ledger normally does not know which RTP version a specific casino has enabled for a game. A distinct build, paytable, mode or configuration can carry another theoretical RTP. The current range inventory does not establish which titles offer operator-selectable settings or which version a casino uses.
  • A published theoretical RTP is not evidence of one player's realized return or a named casino's active build.
  • RTP is a long-run mathematical average, not a promise about any single session.
  • Missing data is left blank; we do not guess it.
  • Some legacy imported values lack a full source history — they are labelled accordingly.
  • The database can contain delayed or incomplete updates.
  • Always check a game's own rules and paytable before you play.

Maintained by the RTP Ledger Data Team — Maintains the game database, validation rules and source records. Published · Last materially updated . Spot something wrong? Report a data issue.