Choosing Between FPPS and PPLNS Pools: A Decision Guide
Choosing fpps vs pplns is one of the few operational decisions in Bitcoin mining where the math is unambiguous but the right answer depends entirely on the operator’s cash-flow constraints, hashrate stability, and time horizon. Both schemes pay the same expected value over a long enough window — that is not what the choice is about. The choice is about who absorbs variance, who captures the upside of luck, and which side of those trade-offs better matches the operator’s situation. This guide unpacks the mechanics, walks through three operator profiles where the answer flips, and lays out a decision framework that does not require a spreadsheet.
What FPPS and PPLNS actually do
Full Pay Per Share (FPPS) is the variance-smoothing scheme. The pool credits every accepted share at a fixed value calculated from the expected block subsidy plus a rolling-average share of transaction fees. The miner gets paid regardless of whether the pool finds any blocks on a given day. The pool absorbs the luck variance — short-run, a small pool running FPPS can pay out more than it earns in blocks; the pool’s fee compensates for absorbing that risk.
Pay Per Last N Shares (PPLNS) is the variance-passing scheme. The pool pays the miner only when the pool finds a block, and the per-block payout is divided among miners weighted by their share contribution over the last N shares (a rolling window typically calibrated to a multiple of the block-find interval). When the pool gets lucky and finds blocks back-to-back, miner payouts spike; when the pool goes unlucky and goes a full day without a block, miner payouts are zero for that day. Average per-share value across a long window approaches the same number FPPS pays — the difference is the path the payouts take to get there.
The variance picture matters more than the headline fee
FPPS pools typically charge a higher fee than PPLNS pools (commonly 2-4% vs 0-2%; consult each pool’s current rate card). Treating that fee delta as a pure cost is the most common analytical error miners make when choosing between schemes. The fee delta is not a cost — it is a premium paid to the pool for the variance-absorption service. Whether that premium is worth paying depends on the value of variance smoothing to the operator.
For an operator running a single rig at home with a steady electricity bill, variance is uncomfortable but not lethal — a bad luck week at a PPLNS pool means a lower payout, not insolvency. For an operator running 500 rigs on financed hardware with a fixed monthly hosting bill and a working-capital line that gets reviewed quarterly, variance is a credit-risk problem — a bad luck week at a PPLNS pool may mean a missed payment. The same fee delta represents either a small cost saving or a meaningful working-capital insurance policy depending on the operator’s situation.
Three operator profiles and the right answer for each
Profile 1: home miner, one to three rigs
A retail operator running a few rigs at residential or small-commercial power has low fixed costs, no financing covenants, and absorbs variance comfortably. PPLNS is usually the better choice on pure fee economics — the headline saving over FPPS materially exceeds the dollar value of variance smoothing at this scale. The exception is operators with monthly electricity bills tight enough that a zero-block week would cause genuine cash-flow stress; for those operators FPPS is still worth the premium.
Profile 2: small commercial farm, 20-100 rigs
This is the band where the answer is most situational. Fixed costs (rent, internet, security, sometimes a part-time technician) become non-trivial. Variance still tolerable on FPPS but PPLNS begins to feel sharper week-to-week. Operators in this band often run a hybrid — primary at FPPS, secondary slot at a PPLNS pool — and rotate based on which scheme is paying better in recent weeks. The hybrid is non-trivial to manage and the dedicated guide on switching pools mid-month covers the mechanics.
Profile 3: industrial farm, 500+ rigs on financed hardware
Cash-flow predictability dominates. FPPS is effectively mandatory because the variance premium pays for itself in the first month a PPLNS pool goes block-light during a hosting-bill due date. Public-miner customers reporting hashrate to investors via SEC filings get an additional reporting-cleanliness benefit from FPPS’s daily-settlement smoothness.
The math underneath: why expected value converges
Over a long enough window — typically a few months at any pool with material network share — FPPS and PPLNS converge to the same per-TH-per-day revenue, minus the respective fees. The mechanism is straightforward: FPPS pays a fixed value per share equal to the expected per-share contribution to block subsidy and fees; PPLNS pays nothing on dry days but disproportionately more on lucky-cluster days, and the long-run average works out to the same per-share value the FPPS pool was paying.
The convergence assumption breaks in two ways. First, on PPLNS pools that experience anomalously bad luck over the operator’s holding window — possible but increasingly improbable as the window lengthens. Second, on PPLNS pools small enough that the variance window itself is too noisy to converge over realistic operator horizons. Operators choosing PPLNS at a small pool effectively choose lottery-ticket variance even over months-long windows; the dynamics are different from PPLNS at a top-five pool.
What the FPPS fee actually covers
The pool fee on an FPPS pool covers three things: the operational cost of running the pool (servers, ops staff, payout infrastructure), the variance-insurance reserve the pool must maintain to fund FPPS payouts during cold streaks, and the pool’s profit margin. The variance-reserve component is the structurally interesting one — it sets a floor on FPPS fees because no rational pool would run FPPS at a fee that does not cover the actuarially expected reserve drawdown.
This is why FPPS fees cluster in a narrow band across major pools regardless of competition — a 0.5% FPPS pool either understands its variance exposure differently or is undercharging in a way that will not last. Operators evaluating an unusually cheap FPPS offer should look hard at the pool’s reserve disclosure and history of payout continuity.
The pool-size and pool-luck dimensions
Pool size matters more under PPLNS than FPPS. A small PPLNS pool has wider luck variance per unit time than a large one because block-find intervals are wider; an operator pointing hashrate at a small PPLNS pool effectively buys into that wider variance. A small FPPS pool insulates the miner from the same volatility on the payout side, but the underlying solvency risk to the pool itself rises with smaller size — a small FPPS pool that hits a long cold streak can run its variance reserve down faster than payments come in.
Hashrate Index’s pool distribution dashboard is a useful sanity check on any pool’s size. Anything outside the top ten or so for Bitcoin is small enough that scheme choice interacts with pool-specific variance in ways the textbook PPLNS-vs-FPPS comparison does not capture. For an explainer on the underlying network mechanics, see how an ASIC mines Bitcoin.
A simple decision framework
The decision can be reduced to three questions:
- What is the largest weekly revenue drop the operation can absorb without cash-flow stress? If the answer is “a normal-variance PPLNS week with no blocks for two days”, PPLNS is viable. If the answer is “any drop creates a missed payment somewhere”, FPPS is the answer.
- How long is the operator’s holding window for the current rigs and electricity contract? Long windows favour PPLNS because expected-value convergence is real; short windows favour FPPS because path-dependence dominates.
- How well-capitalised is the operator versus the monthly opex bill? Heavily-financed operations need the variance smoothing more than self-funded operations of equivalent size.
None of these questions require a spreadsheet. They require an honest read of the operation’s actual cash-flow constraints. For broader Bitcoin mining context including how payouts integrate with the wider economics of running rigs, the Bitcoin mining hub on Coin Web Mining consolidates the related explainers.
A worked fee-versus-variance example
Numbers make the trade-off concrete. Take an operator whose fleet earns an expected gross of roughly $1,000 a day before pool fees on a given hashprice snapshot. An FPPS pool at 3% takes $30 a day, leaving $970 with near-zero day-to-day variance — the operator can budget $970 daily and be close every day. A PPLNS pool at 1% takes $10 a day on the long-run average, leaving $990 expected, but the path is lumpy: some days pay $1,400, some days pay $400, and the $990 only emerges as an average over weeks.
The headline difference is $20 a day, or roughly $600 a month, in the PPLNS pool’s favour on expected value. The question is whether $600 a month is worth the variance. For an operator whose monthly obligations are covered with a comfortable buffer, $600 is real money and the variance is just noise — PPLNS wins. For an operator whose $970-a-day FPPS figure barely clears a fixed hosting-and-financing bill, a string of $400 PPLNS days during a billing window is a missed payment, and the $20-a-day saving is dwarfed by the cost of a covenant breach or a late fee. Same numbers, opposite decisions, driven entirely by the buffer between revenue and obligations. The illustrative figures here are not a forecast — actual revenue tracks hashprice and difficulty, which shift weekly.
How payout scheme interacts with electricity contracts
The variance question sharpens when electricity is priced on a spot or interruptible contract rather than a flat rate. An operator on a fixed all-in hosting rate has a predictable cost side, so the only variance to manage is on the revenue side — and that is exactly what FPPS smooths. An operator on a spot-electricity contract already carries cost-side variance: a cold snap or grid-stress event can spike the power price for the same hashrate. Stacking PPLNS revenue variance on top of spot-price cost variance compounds the swing, because a bad-luck low-revenue week can coincide with a high-price week.
Operators with the most volatile cost structures therefore tend to value FPPS most, not least — the intuition that a sophisticated spot-electricity trader can handle PPLNS variance gets the direction backwards. The exception is the curtailment-heavy operator who deliberately runs only during cheap-power windows; their hashrate is already intermittent by design, so the marginal variance PPLNS adds is small relative to the variance they have already chosen to accept. For those operators the PPLNS fee saving is closer to free money.
Migrating between schemes without losing money
Operators who decide to switch schemes mid-stream should understand that the transition is not symmetric. Moving from PPLNS to FPPS forfeits any in-flight share contribution still sitting in the old pool’s PPLNS window — those shares only pay if the pool finds a block before they age out, so leaving mid-window during a dry streak can mean leaving unrealised credit behind. Moving from FPPS to PPLNS has no equivalent forfeiture, because FPPS has already paid for every accepted share at the moment it was submitted.
The practical guidance is to time a PPLNS departure for a moment when the contribution window has recently paid out rather than mid-window, and to give any FPPS-to-PPLNS switch a multi-week observation period before judging the result, because the variance profile needs time to show its average. The mechanics of executing the switch on the rig — URL edits, worker-prefix changes, reconciliation — are covered in the dedicated guide on switching pools mid-month.
References
- Braiins documentation on pool payout schemes — Braiins
- Hashrate Index pool analytics and hashprice data — Hashrate Index
- F2Pool fee and payout documentation — F2Pool
- AntPool payout scheme documentation — AntPool