RTPBOSS
Data & methodology

Data methodology

RTPBoss is a data project. This page describes the system that actually produces the figures on the site — not a marketing summary. It matches the code: every value carries a source and a confidence level, suspicious values are flagged rather than shown as fact, and missing data is left blank.

What we collect

For 2808 slots we record, where published: return to player (RTP), configurable RTP ranges, the implied house edge, maximum win multiplier, volatility, hit frequency, game identity, provider, release year, and layout/mechanics (reels, rows, ways). For games published through Stake Engine we additionally record exact per-mode RTP computed from the provably-fair outcome tables. Casino pages carry documented licensing, terms, fees and product facts. We do not list a field we do not hold — a blank means unknown, never zero.

Source types

Each value 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 outcome tables.
  • Independent database — a third-party slot database used for corroboration.
  • Legacy import — a value from an earlier bulk import whose per-field origin was not retained.
  • Unknown / undocumented — no source is on record.

Confidence status

Alongside the source, every field records how confident we are:

  • official_verified — traced to an official first-party source.
  • secondary_verified — an independent database agrees with the value. This does not mean the game provider has confirmed the value directly to RTPBoss.
  • observed — a value we measured or recorded directly.
  • unverified — held on record but not yet corroborated by a documented source.
  • conflict_detected — sources disagree; both values are kept.
  • manual_review_required — the value looked wrong and is pending a human check.

You can see these on each game's page, in the “Data status” panel. How sources are ranked is set out in the source policy.

How conflicts and suspicious values are handled

  • One source does not silently overwrite another. When they disagree, the conflict is recorded and both values are kept.
  • A value is only corrected when a documented source proves the correct figure. Otherwise it is set to unknown and marked for manual review.
  • Suspicious values (for example a max-win multiplier that is not a whole number, or an implausibly low figure) are hidden or shown as unknown rather than presented as fact.
  • 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 — read this

  • RTPBoss normally does not know which RTP version a specific casino has enabled for a game. Many titles ship in configurable versions and operators choose one.
  • Provider-published RTP is not the same as the RTP you actually experience at a casino.
  • 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 RTPBoss Data Team — Maintains the game database, validation rules and source records. Last materially updated 2026-07-16. Spot something wrong? Report a data issue.