Mining Pools: Payout Schemes and Centralization Concerns

Cryptocurrency mining pools aggregate the computational power of individual machines to stabilize income in an increasingly competitive industry. By combining their hash rate, or computing power, participants solve cryptographic puzzles more frequently than they could alone, distributing the resulting block rewards according to specific mathematical formulas. However, this cooperative model introduces significant trade-offs regarding payout structures, operator fees, and systemic centralization.

Understanding how these pools operate is essential for analyzing the security architecture of proof-of-work networks like Bitcoin. While pools democratize access to mining yields for smaller operators, they also concentrate decision-making power over transaction selection, raising censorship and censorship-resistance concerns across the industry.

How Mining Pools Function

In a proof-of-work network, miners compete to find a valid block hash that meets the target difficulty set by the protocol ¹. For an individual miner, the probability of finding a block is proportional to their share of the total network hash rate. As the total network hash rate rises, the time between successful blocks for an isolated miner can span several decades, making solo mining highly impractical for all but the largest industrial operations.

To smooth out this variance, miners connect their hardware to a centralized server known as a pool operator. The operator coordinates the collective effort by assigning different search spaces, or ranges of potential solutions, to each participant. These individual contributions are measured using pool shares.

A pool share is a cryptographic proof of work that is easier to find than a valid network block. The pool operator sets a share difficulty target that is significantly lower than the network's actual difficulty. When a miner's hardware finds a hash that meets this lower pool target, they submit it to the operator as proof of computational effort. If a submitted share happens to also meet the higher network difficulty target, the pool operator broadcasts the completed block to the blockchain network, secures the block reward, and distributes it to the participants based on their accumulated shares.

Payout Schemes: PPS vs. FPPS vs. PPLNS

Pool operators use different payout schemes to distribute rewards and allocate risk. The three most common models are Pay-Per-Share (PPS), Full Pay-Per-Share (FPPS), and Pay-Per-Last-N-Shares (PPLNS).

Pay-Per-Share (PPS)

Under the Pay-Per-Share model, the pool operator pays the miner a flat rate for every valid share submitted, regardless of whether the pool actually finds a block during that period. The payout per share is calculated by dividing the standard block subsidy by the current network difficulty.

In this model, the pool operator absorbs all the variance risk. If the pool goes through a period of bad luck and finds fewer blocks than statistically expected, the operator must still pay the miners out of their own reserves. Conversely, if the pool experiences good luck, the operator retains the surplus. Because the operator carries the financial risk of variance, PPS pools typically charge higher administrative fees, which vary over time depending on market conditions and operator policies.

Full Pay-Per-Share (FPPS)

As transaction fees became a larger portion of total block rewards, the standard PPS model became less attractive to miners because it only distributed the base block subsidy. The Full Pay-Per-Share model addresses this by distributing both the block subsidy and the transaction fees accumulated within a block.

To calculate the transaction fee payout, the operator averages the transaction fees included in recent blocks over a specific timeframe and adds this value to the standard block subsidy before calculating the share value. This ensures miners receive a share of the transaction fee revenue while still enjoying the zero-variance benefits of the traditional PPS model.

Pay-Per-Last-N-Shares (PPLNS)

Unlike PPS-based models, the Pay-Per-Last-N-Shares model does not pay for shares as they are submitted. Instead, payouts are only triggered when the pool successfully finds a block on the network.

When a block is found, the operator looks backward at the history of submitted shares. The reward is distributed among miners based on the proportion of shares they contributed within a specific window, defined as "N" shares. The value of N is typically set to a multiple of the pool's difficulty, often representing twice the difficulty level.

Under PPLNS, the variance risk is borne entirely by the miners. If the pool goes hours without finding a block, miners earn nothing during that window, even if their machines have been running continuously. However, because the operator does not absorb variance risk, PPLNS pools charge significantly lower fees than PPS pools. PPLNS also discourages "pool hopping," a practice where miners switch between pools to harvest early shares when a pool is deemed lucky.

A Mathematical Example of Payout Calculations

To understand how these models differ in practice, consider a simplified scenario.

Assume a mining pool has a total hash rate of 100 petahashes per second (PH/s), representing 10% of a hypothetical network's total hash rate of 1,000 PH/s. The network block subsidy is 6.25 $BTC, and the average transaction fees per block equal 0.75 BTC, making the total block reward 7.00 BTC.

An individual miner, Miner A, contributes 10 PH/s to this pool, which is 10% of the pool's capacity and 1% of the total network capacity. Over a 24-hour period, the network expects to produce 144 blocks.

• Under a PPS Model: Miner A is paid based on their statistical expectation of finding blocks, independent of the pool's actual luck. Miner A's expected daily revenue is 1% of the total network block subsidies produced in a day: $$\text{Daily Revenue} = 144 \times 6.25 \text{ BTC} \times 0.01 = 9.00 \text{ BTC}$$ The pool operator deducts their fee (e.g., 2.5%) from this amount, leaving Miner A with 8.775 BTC. Transaction fees are retained by the operator.

• Under an FPPS Model: Miner A's payout includes the transaction fees. The expected daily revenue is based on the total block reward: $$\text{Daily Revenue} = 144 \times 7.00 \text{ BTC} \times 0.01 = 10.08 \text{ BTC}$$ After deducting a typical 2.5% fee, Miner A receives 9.828 BTC.

• Under a PPLNS Model: The payout depends entirely on how many blocks the pool actually finds.

  • Scenario 1 (Average Luck): The pool finds exactly 14 blocks (roughly 10% of the network's 144 blocks). Miner A receives 10% of the pool's total earned rewards of 98.00 BTC (14 blocks $\times$ 7.00 BTC), which equals 9.80 BTC. After a lower PPLNS fee of 1%, Miner A receives 9.702 BTC.
  • Scenario 2 (Bad Luck): The pool only finds 10 blocks. The total earned reward is 70.00 BTC. Miner A's 10% share is 7.00 BTC. After the 1% fee, they receive 6.93 BTC, significantly less than the PPS expectation.

Centralization Risks and the Role of Pool Operators

While mining pools prevent payout volatility, they introduce structural centralization risks to decentralized networks. In a standard pool configuration, the pool operator holds the private keys to the addresses where block rewards are sent. This means the operator has custody of the funds before they are distributed to individual miners.

More critically, the pool operator constructs the blocks. The operator decides which transactions to include from the Bitcoin mempool and determines the order in which they are executed ¹. Individual miners merely provide raw hashing power to solve the headers sent to them by the operator.

If a small number of pool operators control more than 50% of the network's hash rate, they could theoretically coordinate to censor specific transactions, reorganize the blockchain, or execute double-spend attacks. Even without malicious intent, this concentration of block construction power makes the network more vulnerable to regulatory pressure, as governments can target a handful of pool operators to enforce transaction filtering at the block level.

Stratum V2: Decentralizing Block Construction

To mitigate these centralization risks, developers and miners have designed new communication protocols, most notably Stratum V2.

The original Stratum protocol, which has governed pool communication for years, requires the pool operator to build the block template and distribute it to miners. Stratum V2 changes this dynamic by allowing individual miners to negotiate and select their own transactions to include in the blocks they are mining.

Under Stratum V2, the miner constructs the block template locally, selecting transactions directly from their own local node. They then send this template to the pool operator. The operator verifies that the block does not contain double-spends and that the pool's payout address is correct, but they cannot alter the transaction selection without the miner's consent. This shifts the power of transaction selection back to the edge of the network, significantly improving the network's censorship resistance while allowing miners to continue pooling their hash rate to reduce payout variance.

Additionally, Stratum V2 introduces cryptographic encryption to the communication channel between miners and pools, preventing internet service providers or other third parties from eavesdropping on mining traffic or hijacking shares.

Common Misconceptions

• Misconception: Joining a mining pool increases a miner's long-term profitability. In the long run, mining in a pool does not increase total revenue compared to solo mining; mathematically, it yields the same or slightly less due to pool fees. Pooling simply reduces the variance of payouts, turning highly volatile, infrequent rewards into a predictable stream of income. For a detailed look at how hardware efficiency affects these margins, see our guide on ASIC miners and profitability.

• Misconception: Pool operators can steal a miner's hashing power without detection. Miners monitor their hardware's hash rate and compare it to the active hash rate reported by the pool interface. If an operator attempts to underreport submitted shares or divert hashing power to other tasks, the discrepancy becomes visible immediately in the miner's local logs. Miners can easily configure their software to automatically failover to a different pool if a discrepancy is detected.

• Misconception: A pool with 51% of the network hash rate can instantly steal existing coins from any wallet. Even if a single pool controls over 51% of the network's hash rate, they cannot steal coins from arbitrary addresses because they do not possess the private keys required to sign those transactions. A 51% attack only allows the dominant entity to rewrite recent transaction history (enabling double-spending of their own coins) or censor new transactions from entering the blockchain.

How Pool Dynamics Connect to the Market

Pool dynamics directly influence the security and economics of proof-of-work blockchains. When network difficulty increases, the capital requirements for solo mining rise, forcing more miners into pools to maintain cash flow. This relationship is explored further in our analysis of mining difficulty and hashrate.

Furthermore, the distribution of hash rate across different pools is a key metric monitored by institutional investors and network analysts. High concentration in a single geographic region or under a small number of legal entities increases the regulatory risk profile of the asset. Conversely, the adoption of decentralized protocols like Stratum V2 serves as a positive indicator of a network's long-term resilience against censorship and regulatory capture.