DFS Simulator

What Is Monte Carlo Simulation in DFS? Why Averages Lose Tournaments

By DFS Simulator TeamPublished July 15, 20268 min read

Monte Carlo simulation in DFS runs your slate thousands of times with players drawn from full score distributions instead of single-point projections — revealing each lineup's ceiling, floor, and win probability rather than one misleading average.

Every projection you've ever seen is a compression. When a site tells you a player projects for 42.5 fantasy points, it has collapsed an entire probability distribution — the blowup games, the duds, the injury-shortened nights — into one number. That compression is convenient and, for tournament play, quietly ruinous. This guide explains what Monte Carlo simulation actually does with that distribution, why the mean is the wrong number to optimize in guaranteed prize pools (GPPs), and how iteration count changes what you can trust.

Averages are a cash-game tool wearing a GPP costume

Consider two players who both project for 40 points. Player A is a metronome: his real outcomes cluster between 34 and 46. Player B is volatile: plenty of 22-point duds, but a meaningful share of 65-point eruptions. A classic optimizer sees two identical 40s. A tournament sees two completely different assets — in a 100,000-entry GPP, Player A's 46-point best case is nearly worthless, while Player B's 65-point tail is exactly what first place is made of.

The math behind this is not exotic. A large-field GPP pays roughly the top 20% of entries, but the life-changing money sits in the top 0.01%. To finish there, your lineup doesn't need the highest expected value — it needs the highest probability of an extreme outcome. Those are different optimization targets, and only one of them is visible in a mean projection.

What one iteration actually does

A single Monte Carlo iteration is one alternate universe of the slate:

  1. For every player, draw one score from that player's distribution — not their projection, a random sample consistent with their range of real outcomes.
  2. Score every candidate lineup against those sampled outcomes.
  3. Record where each lineup finished.

Repeat ten thousand times and the bookkeeping becomes a distribution per lineup: how often it beat a target score, its 90th-percentile outcome (a realistic ceiling), its 10th-percentile outcome (a realistic floor), and how often it beat the other candidates. None of those numbers exist in a single-point projection.

According to DFS Simulator's engine design, the difference between a 500-iteration and a 50,000-iteration run isn't the average — means converge almost immediately — it's the tails: at 500 iterations, only ~25 samples land beyond the 95th percentile, versus ~2,500 at 50,000 iterations, which is the difference between guessing at a ceiling and measuring one.

How many iterations are enough?

The honest answer is: it depends on which number you want to trust. Some rough sampling arithmetic, using the fact that the count of samples in a tail follows a binomial distribution:

Iterations vs. reliability of the estimate, by statistic
Statistic500 iterations10,000 iterations50,000 iterations
Mean / median lineup scoreSolidExcellentExcellent
80th-percentile outcomeUsable (~100 tail samples)Solid (~2,000)Excellent (~10,000)
95th-percentile ceilingNoisy (~25 tail samples)Usable (~500)Solid (~2,500)
99th-percentile GPP tailUnreliable (~5 samples)Noisy (~100)Usable (~500)

Sampling-theory arithmetic, not benchmarks: tail-sample counts are iterations × tail probability, and estimates sharpen roughly with the square root of that count. Real-world reliability also depends on how well the underlying player distributions are specified — no iteration budget rescues bad inputs.

This is why DFS Simulator's plans scale by iteration budget — 500 on Basic, 10,000 on Pro, 50,000 on Elite. Cash-game decisions stabilize quickly; tournament tail-hunting is where the extra iterations earn their cost.

Correlation: the part most simulators skip

Independent sampling — every player drawn separately — already beats point projections. But real slates are correlated: a quarterback's big game usually is his receivers' big game; a hockey line scores together; when an NBA game goes to overtime, everyone in it gets a minutes bump. Correlated multivariate simulation draws whole-game scripts rather than isolated player outcomes, which is the only honest way to price a stack. That deserves its own article — how stacking correlation wins GPPs covers the math.

Reading simulation output like a tournament player

  • Ceiling (90th–99th percentile): your GPP number. Sort by it — the ordering will disagree with mean projections more than you expect.
  • Floor (10th–20th percentile): your cash-game number. High-floor lineups sacrifice tail upside for consistency, which is exactly the right trade in double-ups.
  • Win rate vs. your own candidates: when building a multi-entry portfolio, you want lineups whose simulated wins come in different universes — not 20 variations that all need the same game script.

The workflow in any supported sport is the same: pick a slate, adjust the projections you disagree with, lock or block players, run the sim, and read the distribution end that matches your contest type.

Frequently asked questions

How many Monte Carlo iterations do I need for DFS?

It depends on what you're estimating. Means stabilize within a few hundred iterations, but tail percentiles — the 95th-percentile ceilings that decide GPPs — need thousands. 10,000 iterations gives roughly 500 samples beyond the 95th percentile; 500 iterations gives about 25, which is why Basic-level sims are fine for cash games while tournament tail-hunting benefits from Pro or Elite iteration budgets.

Is a Monte Carlo simulation better than an optimizer?

They answer different questions. A classic optimizer maximizes the sum of mean projections — one lineup, one number. A simulator runs the slate thousands of times and reports the distribution: how often each lineup wins, its ceiling, its floor. For cash games the optimizer answer is close to right; for tournaments the distribution is the whole game.

What is quasi-random sampling in a DFS simulator?

Quasi-random (low-discrepancy) sequences spread sample points evenly across the outcome space instead of clustering the way pure random draws do. Practically, that means percentile estimates converge with fewer iterations — you get more reliable tail estimates from the same iteration budget.

Why do two identical projections produce different sim results?

Because a projection is only the center of a distribution. A 40-point projection built on 30 safe points plus occasional spikes behaves completely differently from a 40-point projection with a wide spread. Simulation consumes the whole distribution — variance, skew, and correlation with teammates — not just the mean.

Do cash games and GPPs need different simulation settings?

Yes. Cash games (50/50s, double-ups) reward high floors — you want lineups whose 20th-percentile outcome still cashes. GPPs reward ceilings — you want the lineup whose 98th-percentile outcome beats a field of thousands. The same simulation output contains both answers; you just read different ends of the distribution.

Keep reading

Put the theory into practice

DFS Simulator runs correlated Monte Carlo sims across 21 sports — up to 50,000 iterations per slate, from $19.99/month.