How Mining Pools Measure Work and Distribute Block Rewards
Mining pools exist because finding Proof-of-Work blocks is unpredictable at the individual miner level.
A Bitcoin ASIC can run continuously and perform trillions of hashes every second without finding a block for a very long time. The machine is still doing useful work, but unless it discovers a hash that satisfies the network's block target, a solo miner receives no block reward.
Mining pools solve this problem by combining the hashrate of many miners and measuring each participant's contribution. When the pool earns mining rewards, those rewards are distributed according to the pool's accounting and payout method.
The result is not necessarily higher theoretical mining revenue. The main advantage is more regular payouts and lower income variance.
Miners can compare available operators through the ZU Mining Pools Directory.
Why Mining Pools Use Shares
A mining pool cannot wait for every individual worker to find a real blockchain block before measuring its contribution.
Actual blocks are too rare.
Instead, the pool gives connected miners an easier target known as a share difficulty.
When a miner produces a hash that satisfies the pool's share target, it submits that result as a share. Most valid shares are not difficult enough to become blockchain blocks, but they provide evidence that the miner is performing the expected amount of computational work.
Over time, a miner submitting more valid difficulty-adjusted work receives a larger share of the pool's accounting credit.
A simple conceptual relationship is:
Miner Contribution ≈ Miner Valid Difficulty Shares ÷ Total Pool Difficulty Shares
The exact payout calculation depends on the pool's reward method.
Share Difficulty and Vardiff
Mining hardware varies enormously in performance.
A small CPU miner and a modern ASIC should not necessarily receive identical share-difficulty targets. If difficulty were too low for a powerful ASIC, it could submit an unnecessarily large number of shares. If it were too high for a slow worker, the pool might receive too few submissions to estimate the worker's hashrate accurately.
Many pools therefore use variable difficulty, commonly called vardiff.
Vardiff adjusts the worker's share difficulty so that submissions arrive at a practical rate.
A high-performance ASIC may receive a much harder share target than a slower worker. That does not automatically reduce the ASIC's reward. Higher-difficulty shares represent proportionally more work.
What Happens When a Share Is Also a Valid Block?
Occasionally, a miner submits a share whose hash satisfies not only the pool's easier target but also the blockchain's full network target.
That share is a valid block candidate.
The pool broadcasts the block to the network. If the network accepts it, the pool becomes entitled to the applicable block subsidy and transaction fees according to the rules of that blockchain.
How much each participating miner receives then depends on the pool's payout system.
FPPS: Full Pay Per Share
Full Pay Per Share is designed to provide highly predictable mining income.
Under an FPPS system, the pool assigns a theoretical value to submitted work and pays miners according to valid shares rather than making each miner wait for the pool's actual block discoveries.
FPPS generally accounts for the block subsidy and an estimated or calculated transaction-fee component according to the pool's own methodology.
This shifts much of the short-term luck risk from the miner to the pool operator.
If the pool experiences an unlucky period and discovers fewer blocks than statistically expected, miners can still receive share-based payments according to the FPPS terms.
The reverse is also important. If the pool experiences unusually good luck, an FPPS miner normally does not receive the entire upside that would have occurred under a luck-dependent payout model.
Because the operator absorbs more variance, FPPS services may charge higher fees than some PPLNS pools.
Always verify the actual fee schedule rather than assuming a standard percentage.
PPS+: Pay Per Share Plus
PPS+ combines characteristics of PPS and PPLNS-style accounting.
The block subsidy portion is generally paid according to submitted shares, giving miners relatively predictable base income.
Transaction-fee revenue can then be distributed using a separate calculation based on blocks actually discovered by the pool.
The precise implementation varies between operators.
For that reason, two pools advertising "PPS+" should not automatically be assumed to calculate every component identically.
Read the pool's payout documentation before comparing its advertised fee with another service.
PPLNS: Pay Per Last N Shares
PPLNS takes a different approach.
When a pool discovers a block, it examines a defined window of recent mining work. Rewards are allocated according to the valid work contributed during that window.
This means short-term income depends more directly on the pool's actual block discoveries.
If the pool has an unlucky period, payouts can fall below statistical expectations.
If it has a lucky period, they can rise.
Over sufficiently long periods, results may move toward statistical expectations, but individual days or weeks can vary substantially.
PPLNS is therefore often more suitable for miners who intend to remain connected consistently rather than frequently switching between pools.
Proportional Pool Mining
Traditional proportional, or PROP, systems divide rewards among miners according to the work submitted during a mining round.
A round begins after the previous block and ends when the pool finds another valid block.
If you contributed 5% of the credited work during that round, you would generally receive approximately 5% of the distributable reward after applicable pool fees and adjustments.
The simplicity of proportional accounting made it common in early mining pools, although many modern pools now use other payout systems.
Solo Pools
A solo pool is fundamentally different from ordinary pooled reward sharing.
The pool provides mining infrastructure, block templates, connectivity, and submission services, but miners are generally competing to find their own full block.
If your worker finds the valid block, you receive the block reward according to the solo pool's terms after its service fee.
If another miner finds it, your previous work does not normally earn a proportional part of that miner's block.
This creates extremely high payout variance.
Solo pool mining should therefore not be confused with conventional pooled mining simply because both use pool infrastructure.
FPPS vs PPS+ vs PPLNS
There is no payout method that is automatically best for every miner.
| Payout Method | Income Stability | Exposure to Pool Luck | Transaction Fee Treatment | Often Suitable For |
|---|---|---|---|---|
| FPPS | High | Low for miner | Included using pool's FPPS methodology | Miners prioritizing predictable cash flow |
| PPS+ | High to moderate | Limited | Often separated from subsidy accounting | Miners wanting predictable base rewards |
| PPLNS | Variable | Higher | Based on actual pool block rewards | Consistent long-term miners |
| PROP | Variable | Higher | Based on actual discovered blocks | Simple round-based accounting |
| SOLO | Extremely variable | Miner bears most variance | Goes with successfully found block | Very large hashrate or high-risk solo mining |
The advertised pool fee should therefore never be the only factor in choosing a pool.
A lower-fee pool can still produce a worse practical result if it has poor connectivity, frequent downtime, unfavorable payout rules, or high stale/rejected-share rates.
How Stratum Connects Your Miner to the Pool
Most modern mining equipment communicates with pools using a mining protocol from the Stratum family or a network-specific implementation.
The pool sends mining jobs to connected workers.
Your ASIC, GPU, or CPU searches the assigned work for valid hashes and submits qualifying shares back to the pool.
The pool then checks whether each submission is valid and records the accepted work.
Mining software and firmware configuration therefore matters.
You can compare compatible applications through the ZU Mining Software & Firmware Directory.
Accepted, Rejected and Stale Shares
Not every submitted share earns credit.
An accepted share is valid work received and recognized by the pool.
A rejected share is a submission the pool refuses. Rejections can occur for several reasons, including invalid work, configuration problems, duplicate submissions, or work that is no longer valid.
A stale share generally refers to otherwise valid work associated with an outdated mining job.
For example, the network may discover a new block while your miner is still working on the previous job.
If the updated job reaches your machine too late, some work may become stale before it reaches the pool.
Does Higher Ping Always Mean a Specific Stale Rate?
No.
Network latency can contribute to stale shares, but there is no universal formula that reliably converts a particular ping value directly into a precise stale-share percentage across every Proof-of-Work network and mining pool.
The relationship depends on several factors:
Network block or job frequency
Pool infrastructure
Stratum implementation
Geographic routing
Miner firmware
Server load
Connection stability
How quickly new jobs are propagated
Network-specific consensus behavior
This is why measured pool statistics are more useful than estimating stale shares from ping alone.
If one regional endpoint consistently produces more stale or rejected shares than another, changing servers can improve effective mining revenue.
Choosing the Closest Reliable Stratum Server
Many large pools operate servers in multiple regions.
A miner in Asia, for example, may have different routes available than a miner in Europe or North America.
Do not select a server solely because its label appears geographically closest.
Test the actual connection.
A slightly more distant endpoint with stable routing can perform better than a theoretically closer server experiencing packet loss or congestion.
Where supported, encrypted Stratum connections can also protect pool credentials and mining traffic while in transit.
Why Stale Shares Affect Profitability
Your ASIC may display its full local hashrate even when the pool is not crediting all of that work.
Suppose a machine reports 200 TH/s locally but repeatedly submits stale or rejected work.
The economically important measurement is the effective work accepted by the pool.
This is one reason actual pool-side hashrate should be compared with the miner's local dashboard over a sufficiently long measurement period.
When estimating hardware economics with the ZU Mining Profitability Calculator, remember that excessive rejected work can make real revenue lower than an ideal theoretical calculation.
Understanding Pool Luck
Block discovery is probabilistic.
A pool can find more blocks than statistically expected during one period and fewer during another.
This is commonly described as pool luck.
PPLNS and proportional miners can feel these variations directly because rewards depend on blocks the pool actually discovers.
FPPS operators largely smooth this variance for miners by paying according to expected share value under their published payout rules.
This distinction matters when comparing daily pool earnings.
A single day's result is rarely enough to determine which pool is performing better.
Minimum Payout Thresholds
Pools normally set a minimum balance that must be reached before funds are sent to a miner's wallet.
For example, a pool may accumulate earnings until the account reaches its configured payout threshold.
Higher thresholds can reduce the frequency of on-chain transactions, while lower thresholds allow smaller miners to receive funds more frequently.
Before connecting hardware, check:
Minimum payout amount
Payout frequency
Withdrawal or network fees
Supported payout currencies
Whether manual payouts are available
Whether the payout address can be changed safely
Whether additional verification is required
These details can be especially important for smaller miners whose daily earnings are relatively low.
What Is Merged Mining?
Merged mining allows compatible Proof-of-Work networks to use the same underlying mining work.
Auxiliary Proof-of-Work, usually abbreviated AuxPoW, is one mechanism used to implement this.
The best-known example is Litecoin and Dogecoin.
Compatible Scrypt mining work can contribute toward securing both networks without requiring the ASIC to split its hashrate into two separate workloads.
This does not mean every Litecoin pool automatically pays Dogecoin rewards.
The pool must support merged mining and specify how auxiliary-chain rewards are distributed.
Before connecting a Scrypt ASIC, verify whether the operator credits all supported merged-mined assets and how those rewards are paid.
You can compare compatible coins through the Mineable Coins Directory and evaluate Scrypt hardware through the Mining Hardware Directory.
Should You Mine Directly to an Exchange Address?
Sending mining payouts directly to an exchange deposit address can be convenient, but it introduces additional dependencies.
Exchange deposit policies can change. Networks can be temporarily disabled. Deposit addresses or supported networks may change, and some services impose minimum deposit requirements.
For long-term mining operations, a wallet you control can provide greater flexibility.
If you intend to sell mined coins regularly, compare supported markets and deposit networks through the Crypto Exchanges Directory.
What to Check Before Choosing a Mining Pool
Start with the payout model, but do not stop there.
Check the published pool fee and understand exactly what it covers.
Review the minimum payout threshold and payment schedule.
Confirm that servers are available near your mining location and test their stability.
Check whether your hardware and mining software support the required connection method.
For merged-mined networks, verify which auxiliary rewards are credited.
Monitor accepted, rejected, and stale shares after connecting.
Finally, compare the pool-side effective hashrate with your miner's local performance over time.
Final Takeaway
A mining pool is more than a server that receives hashrate.
It is an accounting system that measures submitted work, determines how block rewards are allocated, manages payout variance, and connects miners to the underlying blockchain.
FPPS prioritizes predictable income. PPS+ combines share-based subsidy payments with separate transaction-fee accounting. PPLNS exposes miners more directly to pool luck in exchange for a different risk and fee structure. Solo pools provide infrastructure without eliminating the fundamental variance of solo block discovery.
The best pool is therefore not automatically the one advertising the lowest fee.
For most miners, the more useful comparison includes payout methodology, effective accepted hashrate, stale and rejected shares, server reliability, payout thresholds, merged-mining support, and the operator's track record.
Those factors ultimately determine how much of your hardware's theoretical mining output becomes cryptocurrency in your wallet.