PPLNS vs PPS: which mining-pool payout method is safer for the operator?

01 What a payout method actually decides

A mining pool has one input and one output. The input is shares: partial proofs of work that each connected machine submits every few seconds, each one showing that a known amount of SHA-256 hashing was done against the pool's current block template. The output is block rewards: every so often one of those shares also meets the network target, the pool broadcasts it, and after the coinbase matures the pool holds a new block reward.

The payout method is the rule that maps the first thing to the second. It has to answer three questions. Who gets paid when a block is found? How much? And — the one that matters most and gets discussed least — what happens during the hours or days when no block is found at all? Every method is a different answer to the third question, and every answer moves the luck of mining somewhere: onto the miners, onto the operator, or into a fund that smooths it over time.

Miners usually compare methods by expected income and variance. Operators should compare them by a different measure: at any moment, does the pool owe its miners anything it has not already mined? For some methods the answer is always no. For others it is routinely yes, and that changes what the pool is.

02 The methods, side by side

The Bitcoin Wiki's comparison of mining pools remains the standard vocabulary. The definitions below follow it; the last three columns are the operator's view.

The first column that matters to a miner is "who carries luck". The two that matter to an operator are the last two, and they move together: a method that needs a reserve is a method whose payments cannot be tied to a specific mined block, because they were made before the block existed.

03 PPS: the operator becomes a creditor

Under pure PPS a share of difficulty d is worth d / D × R × (1 − fee), where D is the network difficulty and R the block subsidy. The miner is paid that amount whether the pool finds the next block in ten minutes or in three days. This is a good product: income arrives at the rate the hardware earns it, with no lumps. It is also, mechanically, a loan.

Consider the pool between blocks. Shares arrive continuously and each one creates a fixed obligation. No block reward has arrived to fund it. The operator pays from a reserve, expecting future blocks to replenish it. If the pool's luck runs at 100% the reserve is flat over time; if luck runs below 100% for long enough the reserve is gone, and the operator is either paying miners from its own pocket or defaulting. Meni Rosenfeld's 2011 analysis of pooled reward systems works through exactly how large a reserve is needed to keep the probability of that default acceptably low, and the answer scales with the reward per block and with how unlucky the operator is prepared to survive being. It is not a small number relative to a young pool's revenue.

FPPS makes the reserve larger and more volatile, because the operator is now also underwriting the transaction fees it expects each block to contain. PPS+ trims that by paying fees only when they actually arrive. SMPPS removes the reserve by refusing to pay more than the pool has earned — and replaces it with an explicit ledger of what the pool owes each miner, to be settled when luck turns. None of these changes the shape of the relationship. In every PPS variant there are moments, often long ones, when the operator has received nothing from the network and owes its miners a sum it can compute to the satoshi.

04 PPLNS: paying only what was mined

Pay-per-last-N-shares starts from the opposite end. Nothing is owed to anyone until a block is found. When one is, the pool looks back over the most recent shares — the "last N" — and splits that block's reward among them in proportion to each share's difficulty. Then the ledger is empty again until the next block.

Three details make the method work. First, N is defined in work, not in count: the window is the most recent shares whose summed difficulty reaches some target, typically a multiple of the network difficulty. That means the window covers roughly a fixed number of expected block-times regardless of how much hashrate the pool has, and a vardiff share at difficulty 500,000 counts for exactly 500,000 times a share at difficulty 1. Second, the window ignores round boundaries. A share submitted just before a block was found can still be in the window for the next block too; a share submitted long ago rolls out. Because a share's value is decided by how many blocks the pool finds while it is in the window, not by where it sits in a round, the proportional-pool exploit of mining early and leaving does not exist. Third, transaction fees are simply part of the block reward being split, so miners receive them in the same proportion as the subsidy.

The expected value over time is identical to PPS before fees: a share of difficulty d is still worth d / D × R on average. What changes is the variance and who holds it. On a lucky day the miners are paid more than PPS would have given them; on an unlucky one, less; the operator's fee is a percentage of whatever was actually found. The operator never holds anything that was not first mined, and never owes anything that has not first been earned.

05 A worked PPLNS example

Spearmint Mining proposes a window equal to twice the network difficulty at the moment a block is found. Take illustrative numbers: network difficulty D = 1,000,000 (so the window W is 2,000,000 of summed share difficulty), block subsidy 50 SPMTC, no transaction fees, pool fee 1%.

Two things follow from the window being twice the difficulty. On average the pool finds a block every D of work, so a share typically sits inside the window while about two blocks are found and is paid on each — half a full share's worth each time, summing to the same expectation as if it had been paid once in full. And the window stretches or shrinks with pool hashrate: a pool doing 1% of the network's work fills a 2D window in about 200 block-times; a pool doing 50% fills it in four. A miner who connects and leaves within a fraction of the window is paid for exactly the work they did, weighted by exactly the blocks found while their shares were live.

The same arithmetic, with Spearmint's maturity and payout-run rules applied, is walked through on the how mining rewards work page.

06 The characterisation problem

There is a reason to care about this beyond the operator's balance sheet. The regulatory treatment of a mining pool in the United States turns, in the words of FinCEN's 2019 guidance, on the pool leader claiming the total amount mined and distributing it to members "presumably in proportion to the computer processing provided, minus its own fee". The guidance describes that distribution as integral to the mining service. It describes a specific fact pattern: a block reward arrives, and it is apportioned.

Under PPLNS every payment a miner receives can be pointed at a block — height, hash, coinbase transaction — and at the set of shares inside that block's window. The record reads: this block, this work, this split. Under PPS the record reads differently: these shares, this rate, paid from reserve; blocks found later replenished it. The money still ultimately comes from mining, but the individual payment does not, and an examiner reading the ledger sees a pool paying miners amounts that were not the distribution of any particular reward. Whether that matters to a given regulator is a question for counsel, and Spearmint's own position is that it is one of the open questions on its attorney review list. But an operator choosing a method should know that the choice changes what the ledger says, and that PPLNS is the one whose ledger matches the fact pattern the guidance describes.

07 The trade-offs, honestly

• Miners carry variance under PPLNS. A small pool on a large network can go days without a block, and PPLNS miners are paid nothing in that time. PPS exists because plenty of miners will pay a higher fee to make that go away. A PPLNS pool has to be honest that it is offering lower fees in exchange for lumpier income.
• Window size is a real decision. Too short, and a miner's shares roll out before the next block, which under-pays miners with intermittent hardware and over-rewards whoever happened to be connected at the moment of discovery. Too long, and new miners wait a long time for their first full-weight payout. Twice the network difficulty is a common middle; some pools use larger multiples on very small chains where blocks are rare.
• Orphans hurt PPLNS miners directly. If the found block is orphaned, its reward never matures and the window's shares are paid nothing for it. A PPS operator absorbs that. Spearmint's payout policy says so plainly and shows orphaned blocks with their competing hash rather than quietly making them good.
• Hopping is not entirely dead. PPLNS removes round-based hopping. It does not remove hashrate that moves between chains to chase whichever is most profitable in the hour, and on a small chain that behaviour can still swing luck. That is a difficulty-adjustment problem more than a payout problem, and it is one reason Spearmint retargets every block.
• PPS is easier to explain. "You earn X per terahash per day" is a sentence. "You are paid a proportional share of blocks found while your shares are within a work-weighted window" is a paragraph. A PPLNS pool owes its miners a good explanation and exportable data to check it against.

08 What Spearmint Mining chose

PPLNS, with the window fixed at twice the network difficulty, a 1% pool fee taken from each block reward before apportionment, and no payment of any kind before the block behind it has matured. The reasoning is the one set out above: the operator should never hold anything that was not first mined, and never owe anything that has not first been earned, so that the pool's records say what the pool is — mining infrastructure distributing mining rewards — and nothing else. These values are proposed, not final, and any change will be announced on the updates page with 30 days' notice. The formal statement is the Mining Reward and Payout Policy; the reasoning is on the compliance page.

09 Key takeaways

• PPS and its variants pay for shares before a block exists; the operator carries the luck and needs a reserve to survive bad runs.
• PPLNS pays only when a block is found, splitting that block among the last N shares by difficulty; miners carry the luck and the operator needs no reserve.
• Expected income is the same under both before fees; PPS charges more for smoothing it.
• PPLNS resists pool-hopping because share value does not depend on round timing; PROP does not.
• Under PPLNS every payment traces to a specific block and share set, which matches the fact pattern FinCEN's pool guidance describes; under PPS it does not.
• Spearmint Mining proposes PPLNS with a 2 × difficulty window and a 1% fee, paying nothing before maturity.

10 Questions