Methodology

The Monte Carlo method

The simulator uses the same rule on every page: convert the published or modeled base rate into a per-roll chance, multiply by the luck input, then run 10,000 first-hit trials. I keep median and 95 percent ranges visible because first-hit RNG has a long unlucky tail.

The 100-roll sanity check is intentionally small. It is not proof of every hidden rate. It is a guardrail against obvious implementation mistakes on the common and uncommon side, where a bad formula would show up quickly during normal play.

When community sources disagree, I keep the conservative denominator until Stouts Studio or repeated in-game evidence points elsewhere. That is why the Inverted rate is modeled at 1 in 100,000,000 and marked as a model rather than a private server dump.

Why I show ranges instead of one number

Slime RNG drops are geometric: every roll is an independent shot at the same chance, so two players with identical luck can finish a Mythic chase thousands of rolls apart. A single "expected" number hides that completely. Instead, every calculator on this site reports a median plus a p75 and a p95, drawn from 10,000 simulated chases per query. The median tells you the typical result; the p95 tells you how bad the unlucky tail gets. For any rarity, p95 sits near three times the median, that is not a quirk of this game, it is what a geometric distribution does, and it is the single most useful thing to understand before starting a long chase.

The 100-roll validation log

I cannot datamine the game, so I sanity-check the model against real rolls. On 2026-06-18 I rolled 100 times at a 3x luck setup and compared the early-rarity outcomes, Common and Uncommon hits, against the simulator's expected range. They landed inside it. A 100-roll sample is far too small to confirm a 1-in-100,000,000 Inverted rate, and I do not claim it does. What it does catch is a broken formula: if my Common rate were wrong by a factor of two, a 100-roll test would expose it immediately. Treat it as a smoke test, not a proof.

Measured, modeled, and reported — kept separate

Three kinds of numbers appear on this site and I label which is which. Measured numbers come from my own timed sessions, coins per minute in a biome, the gap between hits during a logged run. Modeled numbers come from published-or-inferred base rates fed through the math, the simulator times, the cumulative odds. Reported numbers come from the community: Discord hit reports and screenshots I aggregate but cannot personally verify. When the three disagree, I say so on the page rather than averaging them into one confident-looking figure.

The tier formula

Tier scores are not vibes. A slime's ROI score is its cash-per-minute divided by log10 of its rarity denominator, a value that rewards income while penalising how hard the slime is to actually obtain. Huge Lucky gets an extra qualitative note on top, because a luck bonus improves every later roll beyond its own cash contribution, and a pure cash formula would understate it. The formula is printed on the tier list itself, so you can disagree with the weighting and recompute it yourself.

What I can't verify

Exact drop rates above Legendary, hidden pity systems, and event-only rates are the honest gaps. Stouts Studio does not publish a rate table, so the high-rarity denominators here are community-confirmed estimates cross-referenced against dozens of hit reports, not official figures. Where a number is an estimate, the page says "modeled" or "approximate." If that ever reads as false confidence, tell me, flagging an overstated claim is as useful as flagging a dead code.

Update cadence

Pages carry a visible "last updated" date and the author byline. After a major Slime RNG patch I re-test codes first because they expire fastest, then rates and zones. A guide that has not been re-checked since the last big update is a guide I would not trust either, which is why the date is on every page instead of buried in a footer.