Methodology

What this registry is

The Slot RTP Registry is a public snapshot of what slot providers and casinos publish on their own websites. For each slot in the registry, we record the RTP value, configurable variants where exposed, volatility, max win, hit frequency, release year, and the source URL.

We do not claim to know the "real" RTP behind closed doors. Regulators (UKGC, NJ DGE, MGA) do not publish per-slot RTP — only aggregate operator statistics. Anyone claiming "true regulator-verified RTP per slot" is fabricating it.

Sources we collect from

Currently 15 slot providers. Each parser is custom because every site uses a different structure (HTML span, JSON blob, WordPress REST API, Wix CMS leakage, etc.). Two columns, not one: records parsed counts the game records we successfully read, with RTP counts those that carried a return figure. Both come from the same run. The gap between them is the provider choosing not to publish, and it is a finding in its own right: Yggdrasil withholds RTP for 250 of 558 titles, Hacksaw for 100 of 138.

Second source: scanning operator catalogs

Alongside provider spec sheets we read the public game catalogs of online casinos and record one field, published_rtp: the number the operator itself writes next to a game in its own catalog.

This is not our payout calculation and not the studio spec sheet. It is a version label the operator publishes under its own responsibility, and we record it as a dated observation of what a shelf showed on a given day.

Sample size

Shelves that carried a return figure next to a game, as of 2026-08-23. Each row is the latest snapshot of that operator and market pair.

Totals across these 11 shelves: 9,230 catalog entries, of which 8,654 carry a return figure. Matched by normalised title, that is 5,471 distinct titles; 1,880 of them appear on two or more shelves, and 723 of those 1,880 carry labels that disagree.

Crawl footprint is not data footprint

The archive holds 1,011 JSON files and all of them parse without error, but only 754 are shelf snapshots: files carrying a slug, meaning one operator's catalog. The other 257 are service runs that record whether a shelf answered rather than what it showed, and we checked that directly: their 843 result records contain zero game rows. Across those 754 shelf snapshots we see 185 distinct operators. 48 returned a readable catalog, and 14 print a return figure next to the game: the 8 in the table above, plus 6 Flutter and Sky brands whose figure sits in a different field of a reconnaissance run where we could not confirm the market. Everyone else either blocks the catalog, serves it without a return figure, or could not be resolved to a market.

A shelf snapshot records its market in one of two fields, and 466 of the 754 carry a value, spread across 20 distinct strings. Twenty strings is not twenty markets. UK and GB are one market written two ways, 75 snapshots between them, and that inconsistency is ours: we name it here rather than quietly fold it away. The string international, on 24 snapshots, is not a market at all, and MT is Malta's licensing jurisdiction rather than a consumer market. That leaves 17 consumer markets in the crawl. Published RTP itself reaches us from six of them: DE, DK, ES, FI, SE and UK.

The sample is uneven, and we say so

Some operators are captured every day, others once, so counting snapshots would weight a daily brand many times heavier than a brand seen once. Counting files is worse still: 257 of the 1,011 are batch and comparison runs, each holding many operators at a time and none holding catalog contents, so sweep is a service label and not an operator. We count distinct shelves instead, and every figure above is computed per operator and market, not per file.

What a shelf shows that a spec sheet does not

Three worked cases from the snapshots. Every row names the shelf, the market and the exact snapshot time, so the same file can be opened and the same number read back.

Matching titles across shelves, and the trap in it

Shelves do not agree on how to write a name. The same game is listed as DiamondLinkMightyBuffalo on two German shelves, as Diamond Link: Mighty Buffalo on a third, and as Diamond Link with a trademark sign and a dash on a fourth. Nothing forces an operator to spell a title the way the studio does, so a title is a label too.

We therefore compare only after normalising: lowercase the name, then drop every character that is not a letter or a digit. Dropping means removing, not replacing with a space. Replacing with a space leaves diamondlinkmightybuffalo and diamond link mighty buffalo as two different keys, which is the same failure wearing a disguise.

This is the first thing that will bite anyone checking our numbers, and it fails silently: a search that misses a spelling returns an empty result, which looks exactly like a shelf honestly not carrying the game. We hit it ourselves while preparing this section and briefly concluded that only two German shelves stocked the title. On the 11 shelf summary above, the wrong rule yields 5,782 titles and 562 disagreements instead of 5,471 and 723, so it hides 161 of the 723 disagreements rather than reporting them.

What this source does not give

• We do not measure payouts and we do not verify that a label matches reality. We record what the operator published, nothing more. We neither confirm nor deny that a shelf figure is the figure the game actually runs at.
• We have not established why shelves disagree. Certified multi-return configurations, market specific editions, stale catalog copy and plain operator error would all produce the same pattern in our data, and we have not separated them.
• Land based machines are not covered at all. There the casino sets the configuration within the regulator's range via the par sheet, and that document is not published anywhere.
• There are no US shelves in the sample. Two brands in the crawl carry a US licence, and both were captured from the UK access point with the market unconfirmed, so we treat them as non US and exclude them.

How to check us

Every claim above can be re-derived from the raw snapshots:

• the field is published_rtp, holding the operator's raw string and the values parsed out of it, so a range such as 94.49 / 94.51 stays visible as a range;
• file names read slug, date, access point, then the requested market and the run label where they apply, so the shelf, the day and the vantage point are readable before the file is opened;
• every figure we publish from this source carries the date of the snapshot it came from. A figure without a date is not ours.

Figures in this section are correct as of 2026-08-23. The corpus grows daily and these counts are recomputed from the snapshot folder, not edited by hand.

Coverage status meanings

complete

More than 90% of the provider's catalog has usable RTP. Trust as primary source.

partial

50–90% coverage. Show with caveat. A second-pass scrape may help.

exhausted_public

The provider does not publish full RTP coverage on their public website. We record what we can.

Per-field confidence

Each field on each record carries a confidence label.

• high — extracted via strong DOM selector or canonical JSON blob.
• medium — regex fallback or structured text near a labeled field.
• low — best-effort extraction, may need verification.
• unavailable — the field is genuinely not present at the source.

Provenance & evidence

Every record carries:

• source_url — the page we read
• snapshot_id — sha256 of the full HTML body at fetch time
• fetched_at — ISO timestamp of the read
• parser_version — version of the extractor used

Snapshots (~270 MB across 4,076 source observations) are kept as gzipped HTML. If a provider changes their site, we can prove what we saw on a given date.

Roadmap

• Per-casino RTP variants. Top-5 UK-licensed casinos seeded manually 2026-Q3, automated weekly cron 2026-Q4. Will surface as "available at N casinos · RTP range X–Y%" inside the widget.
• Historical changelog. Accumulating from 2026-05-08 launch via weekly cron with meaningful-diff detection.Public feed live now; first entries arrive after the next Monday cron run.
• Community session data. Planned for v1.5 once anti-fraud thresholds + sample-size methodology are validated. Empirical "actual" returns from real player sessions, separate from provider-stated RTP.
• Provider expansion. 15 providers tracked at v1.0. BTG (image-based RTP requires OCR), ELK and Quickspin (partial public coverage) under evaluation for v1.1+.
• Internationalization. Widget UI in EN-only at v1.0; a Russian translation is planned.
• Pro tier & API keys. White-label widget + higher API quota. Early access via hello@toolsgambling.com; self-serve dashboard + billing post-validation.

Versioning

The current data contract is v1.0.0. v1.x means additive only: more providers, more optional fields. No field removal. Breaking changes require a v2 with migration window.