Why the Advertised Fee Is Not the Full Comparison

When miners choose a Bitcoin mining pool, the advertised fee percentage is often the first — and sometimes the only — number compared. This is insufficient. A fee percentage only has meaning once you know which part of miner revenue it applies to, how the pool allocates that revenue, when the resulting balance becomes withdrawable, and whether the pool's infrastructure and support can be relied on from your mining location.

A Bitcoin block provides miners with two main sources of revenue: the block subsidy and the transaction fees included in that block. Since the April 2024 halving at block 840,000, the block subsidy has been 3.125 BTC. As the subsidy declines across halving epochs, transaction fees become increasingly important to miner revenue [1]. Because pools can treat the subsidy and transaction-fee components differently, comparing pools on a single blended fee number can be misleading.

This article sets out a framework — fees, payout method, uptime, and support — for evaluating a pool on terms that affect what a mining operation receives and when.

Compare Fees by Reward Component, Not by Headline Percentage

Before comparing fee percentages across pools, identify three things: which reward component the fee applies to, which payout method governs that component, and whether any separate withdrawal or transaction charges exist.

ViaBTC's current pricing documentation illustrates why this matters. Under its PPS+ method, the block-subsidy component is settled under PPS logic with a 4% fee, while transaction fees are distributed separately under PPLNS logic with a 2% fee. These are two fees applied to two distinct reward components, not a combined 6% deduction from total mining revenue. Under ViaBTC's PPLNS method, by contrast, a single 2% fee applies to the combined distribution of block subsidy and transaction fees [2].

This distinction is a useful general model for evaluating any pool: ask what exact reward components a stated fee covers and under which payment method. A lower headline fee does not automatically mean a lower overall deduction if the pools being compared apply fees to different reward components or use different settlement rules.

Read the Payout Rules Before Connecting Hashrate

The payout method determines how variance, timing, and transaction-fee treatment affect what a miner actually receives.

PPS and PPS+. Under Pay Per Share, the pool pays for valid shares according to its published formula, which reduces a miner's direct exposure to short-term pool luck for the component settled under PPS. PPS+ extends this structure by applying PPS-style settlement to the block subsidy while distributing transaction fees separately under PPLNS logic. It is therefore more accurate to describe the subsidy component as more predictable under PPS+ than to describe the entire payout as fixed, since the transaction-fee portion still depends on the pool's PPLNS rule and prevailing network fee conditions.

PPLNS. Pay Per Last N Shares allocates rewards based on a miner's contribution within a defined recent-share window when the pool finds a block. This leaves miners more exposed to block-timing variance than PPS-style settlement. ViaBTC states that its PPLNS distribution is calculated after a block receives six confirmations and uses each user's share of pool hashrate over what its pricing documentation calls the past five "difficulty rounds" [2]. The size of N, the exact window definition, and confirmation requirements are not standardized industry-wide, so each pool's rule should be checked individually.

Other named schemes. Pools may also use labels such as FPPS or other variants. The label alone should not be treated as proof that two pools calculate rewards in exactly the same way. Before comparing them, confirm how each pool defines the scheme, which reward components are included, and how transaction fees are handled.

Beyond the payout method itself, check settlement frequency, minimum payout thresholds, and withdrawal schedules, and treat these as separate stages. A settled reward credited to a dashboard, an account balance available for withdrawal, and a completed on-chain transfer to an external wallet are not the same thing.

ViaBTC, for example, distinguishes between "Payout by Account Balance" and "Payout by Daily Earnings" for automatic withdrawals. Auto-withdrawals are processed once daily between 10:00 and 18:00 GMT+8. Minimum-payout rules depend on the withdrawal destination and settings: ViaBTC states that the minimum payment amount does not apply when withdrawing to a ViaBTC account as long as the withdrawal amount is greater than zero [3]. When comparing pools, confirm current settlement and withdrawal rules directly from each pool's own documentation rather than assuming a shared standard.

Measure Uptime From the Miner's Perspective

There is no single public metric that fully captures a pool's reliability as experienced by a specific mining operation. A pool's website and API can remain available while a particular Stratum connection path or account service experiences problems; conversely, a brief interruption may have little operational effect if configured failover works as intended. Uptime should therefore be assessed through operational evidence rather than a marketing claim alone.

Practical steps include:

• Test supported primary and backup connection URLs or ports from the mining site. ViaBTC's BTC mining setup guide recommends configuring multiple ports so a miner can switch automatically if one becomes inactive [4].
• Compare local miner logs against the pool dashboard over matching measurement windows. The ASIC's local hashrate reading and the pool's estimated hashrate are related but distinct measurements; a difference between them, on its own, is not proof of a pool-side fault.
• Review rejected-share rates and, where available, the breakdown of rejection reasons. Rejected shares are a broad category that can include stale, invalid, and duplicate submissions. A rising rejection rate can result from network latency, unstable connectivity, firmware or tuning settings, or a pool-side issue. It is a signal to investigate, not conclusive evidence against the pool.
• Verify that failover actually works. This can be checked through a controlled failover test or observed during an interruption rather than waiting for a major real-world outage.
• Record interruptions and recovery behavior over a defined observation period. A single low-hashrate reading, especially from a rolling dashboard estimate, is not enough to conclude that downtime occurred.

Public pool-hashrate estimates can provide useful context about pool size and recent block-production history, but they are not measurements of Stratum uptime, connection stability, payout accuracy, or support quality. They should not be used as substitutes for site-level testing.

Treat Support and Documentation as Operating Tools

Support quality matters most when something has gone wrong with worker configuration, share submission, or a payout. Evaluating support as an operational feature means checking whether the pool provides current setup and payout documentation, useful troubleshooting guidance, clearly identified support channels, and practical next steps when a problem cannot be resolved locally.

For a mining operation, useful support should cover common issues such as incorrect worker naming, Stratum connection failures, persistent invalid-share warnings, delayed or missing earnings, withdrawal-address or minimum-payout problems, and account-access issues. It is also worth checking whether documentation and support are available in the languages and time zones relevant to the operation and whether the pool has a clear channel for communicating service incidents.

ViaBTC's BTC mining setup documentation, for example, instructs users to check worker status and earnings after a miner stabilizes and to submit a support ticket if invalid-share warnings persist after local settings have been checked [4]. There is no universal response-time or support-hours requirement that applies to every miner; the appropriate level depends on the scale, redundancy, and staffing of the operation.

A Practical Pool-Comparison Checklist

When comparing pools, work through the same questions for each candidate:

• What reward components does the stated fee apply to, and under which payout method?
• Are transaction fees distributed separately, combined with the block subsidy, or excluded?
• What settlement schedule, confirmation requirement, and minimum payout threshold apply?
• Are settled earnings, account balance, and completed withdrawals clearly distinguished in the pool's reporting?
• Does the pool publish supported backup connection URLs or ports, and does failover work when tested?
• How do local miner logs compare with the pool's dashboard hashrate over matching measurement windows?
• What is the rejected-share rate, and can the rejection reasons be identified?
• Can the pool's documentation and support resolve connection, share, or payout problems effectively?

Conclusion: Compare Like With Like

A mining pool comparison built on a single fee figure or one day of observed revenue will rarely reflect the actual experience of directing hashrate to that pool. Fees only become comparable once the reward base and payout method are known. Payout methods only become comparable once settlement timing and withdrawal rules are accounted for. Uptime and support are best assessed through operational evidence from the mining site.

Reviewing each pool's current official documentation for payout formulas, settlement schedules, connection options, and withdrawal rules before committing hashrate remains the most reliable way to make the comparison accurate.

FAQ

Is a lower pool fee always better for miners?

Not necessarily. A fee percentage only reflects part of the picture unless you know which reward component it applies to and which payout method is used. Two pools with different fee percentages may also apply those fees to different components of miner revenue, so the headline percentage alone is not enough to determine which arrangement results in a lower overall deduction.

What is the difference between PPS+ and PPLNS?

PPS+ applies PPS-style settlement to the block subsidy, reducing exposure to short-term pool luck for that component, while transaction fees are distributed separately under PPLNS logic. PPLNS distributes rewards according to a defined recent-share window and leaves miners more exposed to variance tied to when the pool actually finds blocks. Exact PPLNS window and confirmation rules vary by pool.

How can I check a pool's uptime before committing hashrate?

Test the pool's supported primary and backup connection URLs or ports from your mining location, verify failover through a controlled test or observed interruption, and compare local miner logs with pool-side data over matching measurement windows. A marketing uptime claim can provide context but does not replace site-level testing.

Does a higher publicly reported pool hashrate mean better reliability?

No. Publicly reported pool hashrate generally reflects estimated mining power based on observed block production or other pool statistics. It does not directly measure connection stability, payout accuracy, service availability, or support quality.

Are settled earnings the same as a completed withdrawal?

No. Settled or credited earnings are amounts recorded under the pool's payout formula. They may remain in an account balance before withdrawal. Automatic or manual withdrawals are then processed according to the pool's own schedule, destination rules, and minimum payout requirements.

References

1. Bitcoin.org, "Bitcoin Halving," accessed September 2026: https://bitcoin.org/en/halving
2. ViaBTC, "Pricing," accessed September 2026: https://www.viabtc.com/en/pricing
3. ViaBTC Help Center, "What Is Auto Withdrawal? How to Set Up and Manage It?," updated June 2026: https://support.viabtc.com/hc/en-us/articles/7207389319567-What-Is-Auto-Withdrawal-How-to-Set-Up-and-Manage-It
4. ViaBTC Help Center, "BTC Mining," accessed September 2026: https://support.viabtc.com/hc/en-us/articles/7207401012879-BTC-Mining