Sampling
Every public bet feed is a sample. Casinos publish a stream of recent bets on their site for everyone to see; we read that stream, nothing more. No casino shows every bet. Stake and Shuffle emit roughly one bet per second regardless of load; Roobet shows about one bet a second of its ~90, and only stakes of a few dollars and up; Gamdom shows every bet of $200 and up but only a fraction of the smaller ones; and several casinos only show bets above a stake or payout cut-off on curated feeds such as "high rollers" or "lucky wins".
Where a casino also publishes a cumulative bet counter or wagered counter (Roobet, Gamdom, Winna, Duel, Spartans and others), we read it alongside the feed. The ratio between the counter's growth and the bets we saw is the feed's sample ratio, shown on /status. It counts bets, not dollars, and a feed's bets are rarely a fair sample of stakes, so we do not multiply an observed wager by it: a feed that favours large stakes, scaled up by its bet count, overstates the wager many times over. Bet counts are estimated from the counter. Wager is estimated only from a casino's own wager counter, or where the feed carries at least 95% of the counted bets; everywhere else it is the observed sum. Where no counter exists, we claim no ratio.
Every wager estimate is checked before it is shown: it must be no lower than what the feeds showed, below 2,000 times the casino's average daily on-chain deposits (when we know at least $100K of them a month) and below $2B a day. An estimate that fails is held back and noted on /status, and the observed sum is shown instead.
Curated feeds (big wins, lucky, high rollers) are biased by construction: they show wins. They are used for the win lists and records, never for RTP.
Measures
Every figure carries a mark that says how it was produced. The mark never changes the number's colour; it only tells you how far to trust it.
- observed Observed: summed from the individual bets the casino's feed actually showed us. Because feeds are samples, an observed total is a floor.
- estimated Estimated: read from the casino's own public counter, the bets it counted or the growth of its wagered total, or a feed carrying nearly every counted bet scaled up to the count. It approximates the casino's true total and carries the counter's own errors.
- on-chain On-chain: measured from blockchain transfers to and from the casino's reviewed wallets, converted to USD at the per-minute price when the transfer confirmed. Exact for the wallets we know; blind to the ones we do not.
Players online and race standings are read from the casino's own counters and are observed values of what the casino displays, not independent measurements.
RTP estimator
Observed RTP is the wager-weighted ratio estimator: total paid out divided by total wagered over the sampled bets in the window, rtp = Σ paid / Σ wagered. It is not the average of per-bet multipliers; a ratio of sums weights every dollar equally, which is what a return-to-player figure means.
The 95% confidence interval uses the delta method for a ratio of sums. With per-bet wager w, payout p, and r = Σp / Σw, the variance estimate is Var(r) ≈ Σ(p − r·w)² / (Σw)², computed from running sums of w, p, w², p² and w·p so it updates incrementally. The band is r ± 1.96·√Var(r). Slot payouts are heavy-tailed, so bands are wide until the sample is large; we show them rather than hide them.
Deviation from the advertised figure is a z-score, z = (rtp − official) / se, shown as +2.3σ. Hot and cold on the site mean past observed RTP above or below official by more than 2σ. They describe what happened in the window; every spin is independent and the figure says nothing about the next one.
Windows are 10 minutes, 1 hour, 24 hours, 7 days, 30 days and all time. A row needs at least 2,000 bets and $20,000 wagered in its window before it is ranked, coloured hot or cold, or flagged. Below that the number stays visible in grey with a "below min" tag.
Feed bias check
A sampled feed can be biased even when it is not curated: a casino may show more wins than losses, or drop small bets. Before a feed's bets count towards RTP we compare its per-game observed RTP against the game's official RTP across every game with enough sample, weighting each game's deviation by the inverse of its standard error.
If the deviations share one direction, a uniform shift, the feed is biased: the shift belongs to the feed, not the games. That feed is excluded from every RTP figure and marked RTP: excluded on /status. If the deviations scatter around zero and only one game sits far out, the feed passes and the single game's deviation is a finding about that game, which is what the hot/cold pages and the originals matrix report.
Right now 0 of 0 main feeds pass the check; 327 feeds across 60 casinos are read in total. The check reruns daily on the 7-day window.
Originals
Casino originals (dice, limbo, crash, plinko, mines and the rest) advertise an RTP or house edge in their own rules. We capture that advertised figure per casino and per game alias, with the source page and the date we read it, and compare observed RTP against it in the originals matrix. A flagged cell reads "advertised 99.00% is outside the 95% band" and nothing more; it reports a statistical disagreement, not a cause.
Crash and slide are measured from complete round history rather than sampled bets, because the casino publishes every round's result. The survival curve P(X ≥ x) is compared with the theoretical (1 − edge) / x for the advertised edge, and the share of instant crashes (result 1.00×) with its expected value. The observed edge is fitted from the curve with a bootstrap confidence interval over rounds.
Wallets and reserves
Deposits, withdrawals and reserves come from the blockchain, so they depend entirely on knowing which addresses belong to a casino. Wallet attribution uses, in decreasing order of confidence: public labels on block explorers (Etherscan, Tronscan, XRPScan, Arkham), the casino's own transparency or proof-of-reserves pages, community label sets, and a sweep heuristic that follows funds from known deposit addresses to the hot wallet they are consolidated into.
Each candidate gets a confidence score from its sources and passes a manual review before it is used. Transfers are then classified as deposit (into a casino address from outside), withdrawal (out to a non-casino address), internal (between casino addresses) or processor (to or from a known payment processor); only deposits and withdrawals appear in flows. Reserves are hourly balance snapshots of the reviewed hot and cold wallets per chain, priced at the snapshot time.
Chains indexed: Bitcoin, Litecoin, Dogecoin, Ethereum, BNB Chain, Tron, Solana, Polygon, Base, Arbitrum and the XRP Ledger (12 trackers running). Tokens follow the chain: USDT and USDC on Ethereum, Tron, BNB Chain, Solana, Polygon, Base and Arbitrum are included, as are DAI on the last three, ARB on Arbitrum and RLUSD on the XRP Ledger. On Base and Arbitrum, ETH counts in reserves but not yet in flows. XRP payments to a casino's shared account keep the destination tag that names the customer.
On-chain insights
The insights pages and each casino's On-chain insights tab turn the same wallet transfers into aggregate figures: average and median deposit, how many distinct addresses deposited, how deposits spread over sizes, hours and chains, how concentrated they are and how many addresses show up on several sites. Everything below is about what the tracked wallets showed in the window. None of it is a site's full volume, and nothing is scaled up to one.
What is counted
A deposit is a transfer into one of a site's approved deposit, hot or cold wallets from an address outside the registry; a withdrawal is a transfer out of such a wallet to an address outside it. Both are priced in USD at the minute they confirmed and bucketed into whole UTC days, so a window of 7, 30 or 90 days means that many calendar days up to and including today. The basis line next to every figure names the wallets, chains and days behind it; the refreshed time is the last rollup.
What is excluded
A transfer whose other side is an address the wallet registry already knows is left out and counted under excluded by reason: own, the site's own wallets (sweeps to cold storage, gas top-ups, rebalancing); casino, a wallet of another site we track; exchange, a known exchange's hot wallet, which hides who the customer is; processor, a known payment processor. Excluded transfers are shown with their count and USD on every insights surface so the size of the gap is visible.
Where the window starts
Each chain counts from the moment its scanner first ran, and never earlier: older transfers it read back are wallet history, not money that moved while we watched. While tracking is younger than the window the figures cover fewer days than the window asks for; the page then says 2 of 30 days tracked and shows no change against the previous window. A chain added recently is under-represented in a long window for the same reason.
Unpriced transfers
A transfer we cannot price (a token without a quote at that minute, a dust amount below the quote's precision) is dropped from every USD figure and from the counts, averages and medians that go with them.
XRP destination tags
On the XRP Ledger a site receives into one shared account and tells the customer apart by a destination tag, so an incoming payment's sender is the depositing address as on any chain. A withdrawal that carries a destination tag, usually to an exchange naming its customer by tag, counts its receiving address as address:tag; otherwise every customer behind that account would collapse into one recipient. Withdrawals to an exchange account the registry knows are excluded either way.
New and returning
An address is new when its first deposit to the site, on any tracked chain, falls inside the window, and returning when we had seen it deposit before. Our history starts when tracking starts, so in the first weeks nearly every address looks new: an address that had deposited for years before the scanner began is counted as new on its first deposit we see. The split, and the weekly cohort table built from it, becomes meaningful once tracking is older than the window; the first cohorts always read larger than they are.
Categories, ranks and shares
A site's rank and share compare it with the other tracked sites of its category, and the categories are the boards': the casinos include the case sites that also run a casino section, and those sites stay among the case sites too. Such a site therefore has two placings; its casino page shows the one among casinos, its case-site page the one among case sites. Because these sites sit in both overviews, the casino and case-site totals overlap and are never added together. A share is of what the tracked wallets showed, not of a market.
Addresses, not people
Every depositor figure counts distinct sending addresses, exactly up to 65,536 and as an estimate within about 1% above. One person can use many addresses and a shared wallet (a custodial service we have not labelled) stands for many people, so the counts, the concentration figures and the cross-site overlap are rough measures of reach, not head counts. The top addresses lists show addresses truncated as the API sends them, with no explorer link and no label; they exist to show how concentrated deposits are, never to identify anyone. Nothing on these pages says anything about a person's results.
Case sites
CS2 case-opening sites publish live drop feeds, case contents with odds, battles and upgrades instead of bet feeds and wallets. We read those public endpoints, 31 sites at the time of writing, and treat an opening as a bet and a drop as its payout. Nothing on-chain exists for them: their wagered figures are the value of the cases opened and their bets are the openings we sampled. They appear on the casino boards with a Cases label and have their own section at /case-sites. Six of them (500 Casino, CSGOEmpire, CSGORoll, Clash.gg, Chicken.gg and Cases.gg) also run a casino section whose bets reach us: they are listed with the casinos as well and have a casino page for their slots, live games and originals, and each is still counted once in totals.
Prices
Every value is the site's own item price in its own coin, converted at the rate the site states for that coin. We use no external market price reference, so a drop worth $500 on one site may list for $380 on another; the item pages show that spread. Each coin's USD rate and where we read it are public on the site page; rates set by the site's cashier are taken as given.
Advertised and observed RTP
A case with published odds has an advertised expected value: the odds-weighted mean of its items' values divided by its price. Casehug publishes one odds figure for several wears of an item; its value is the odds-weighted mean of those wears. Cases.gg prizes are physical goods rather than CS2 skins, priced as the site prices them. Where a site's feed shows every drop we also compute an observed RTP from the sampled drops with a 95% confidence interval. With odds (odds method) the interval comes from the case's own payout distribution and needs 100 openings and five expected tail hits before it counts, so a window before the first rare hit is not read as a low RTP; without odds (sample method) it comes from the sample's variance and needs 1,000 openings. Until then the row reads small sample. The method is shown next to every figure.
Sites that publish only their biggest drops (the top feeds) get advertised figures only; an observed RTP from a feed that hides the losing openings would be meaningless, so we never show one. When a case's advertised RTP falls outside the observed interval the row is marked outside band with both numbers side by side. That is a statement about the sample, not an accusation: the feed may be partial, the odds may have changed since we read them, or the sample may be unlucky.
Battles and upgrades
Battle RTP is the total unboxed divided by the total cost of the cases, per site and mode. DatDrop shows battle seats without values, so its battles count toward volume but not RTP. Upgrades compare the share of attempts that won against the chance the site displayed; a feed that lists only wins cannot support that comparison and says so.
Access and fairness
Restricted countries, regional exclusions, operator and licence details are quoted from each site's terms with the date we read them. Provably-fair descriptions are the sites' own; we have not audited them.
What we cannot see
- Bets that never reach a public feed: private tables, hidden players' names, and anything the casino does not publish.
- Bonus buys, unless the feed flags them; where it does, they are excluded from RTP because their payout distribution differs.
- Fiat deposits and withdrawals, card payments and bank transfers.
- Deposits that start inside an exchange and arrive through its hot wallet, which hide the depositor's chain.
- Chains we do not index, and tokens outside the list above.
- Anything about a player's net position: feeds show bets, not balances.
- On case sites: the losing openings of a top-only feed, the market resale value of a skin, and whether a displayed price can actually be withdrawn.
Where a figure depends on one of these gaps we say so next to it rather than fill it in.
Common questions
What is observed RTP?
What players got back over the bets the casino’s public feed showed us in this window: paid out ÷ wagered, so every dollar counts equally. It is not an average of multipliers.
The ± is the 95% band. Slot payouts are heavy-tailed, so the band stays wide until the sample is large; we show it rather than hide it.
Where does the official RTP come from?
The return to player the game is published with, as each casino shows it. We record the figure per casino together with its source, and the same game can run at a different official RTP on different casinos.
Observed RTP is compared against this figure; the deviation column says how far apart they are.
What does the 95% band mean?
The range that is consistent with this sample at 95% confidence: observed RTP ± 1.96 standard errors, from the delta method for a ratio of sums.
Few bets or a couple of big payouts make the band wide. A figure whose band still contains the advertised RTP is not in disagreement with it.
Why are some rows below the minimum sample?
Fewer than 2,000 bets or $20,000 wagered in the window. The figure stays visible in grey but is never ranked, coloured hot or cold, or flagged: with that little data the band is too wide to say anything.
What do hot and cold mean?
Hot: observed RTP at least 2σ above the official figure in this window. Cold: at least 2σ below. Both are statements about past results in the sample.
With hundreds of games some cross 2σ by chance. Hot is not good and cold is not bad; neither says anything about the next spin.
Do past results predict what a game will pay?
Hot and cold describe what already happened: observed RTP more than 2σ above or below the official figure over the sampled bets in this window.
They predict nothing. Every spin, roll and round is independent: a hot slot is not “due” to cool off and a cold one is not “due” to pay out. No figure on this site improves anyone’s odds.
What is the house edge and the expected loss?
The house edge is the share of every stake the game keeps on average: 100% minus its official RTP.
Expected loss is this stake times that edge, what the bet costs on average over many plays. A win on the spin does not change it; it is the price of playing.
How is a CS2 case’s advertised RTP worked out?
The odds-weighted mean of a case’s item values divided by its price, from the odds table the site publishes; the items are valued at the site’s own prices on the day we read them.
“Outside band” means the advertised figure sits outside the observed 95% band in that window. The feed may be partial, the odds may have changed since we read them, or the sample may be unlucky; it is a fact about the openings, not a verdict on the case.
What is a case site’s item price?
Every item value is what the site itself credits for the item, in its own coin at the rate it states. We use no external market price, so the same skin can be worth different amounts on two sites.
The coin rate and where we read it are on each site’s page.
Changelog
- 2026-11-03
- On-chain insights: deposit sizes, depositing addresses, timing, concentration, overlap and weekly cohorts from the tracked wallets, per site and across the market, with excluded transfers listed.
- 2026-11-03
- Wager is no longer scaled up by a feed's bet share: feeds that favour large stakes (Roobet, Gamdom, Winna) were overstated many times over. Estimates now come only from a casino's own wager counter or a near-complete feed, and are checked against on-chain deposits.
- 2026-11-03
- Fifteen more case sites join the boards. SkinRave, PLG.bet, CSGOFAST, CSBattle, KNIFEX, Hunt.gg and CSGORUN publish casino bets too and also count as casinos.
- 2026-11-03
- Case sites whose feeds carry casino bets (500 Casino, CSGOEmpire, CSGORoll, Clash.gg, Chicken.gg, Cases.gg) count as casinos too: they appear under Casinos with a casino page, and each site is still counted once in totals.
- 2026-11-02
- CS2 case-opening sites join the boards with a category label; dedicated pages for sites, cases, items, drops, battles and upgrades.
- 2026-11-02
- Feed status page lists the bias check result per casino and the sample ratio of the main feed.
- 2026-10-28
- Minimum sample raised to 2,000 bets and $20,000 wagered before an RTP row is ranked or flagged.
- 2026-10-21
- Crash and slide edge measured from complete round history instead of sampled bets.
- 2026-10-14
- Wallet attribution adds the sweep heuristic and a confidence score; every wallet passes review before it counts.
- 2026-10-07
- Feed bias check introduced; biased feeds are excluded from RTP figures and marked on /status.
- 2026-09-30
- First public version: 19 bet feeds, 7 chains, observed and estimated totals labelled separately.