Why Pool Comparison Requires More Than a Fee Percentage
When a mining operation reports to investors on pool selection, the discussion often collapses into a single number: the advertised fee. This framing understates the decision. Bitcoin pool shares are proofs of work submitted at a target that is easier than the network's block target; pools use these shares to measure a miner's contribution and distribute rewards under a chosen payment method, not to represent blocks themselves. Payment method and fee basis determine how the network's block subsidy and transaction fees are allocated, while settlement timing and observed connection performance affect when rewards are credited and whether submitted work is accepted. Since the April 2024 halving, the block subsidy has been 3.125 BTC per block, with transaction fees varying separately; a pool comparison that ignores which reward component a fee applies to can misrepresent the miner's actual cost of participation.
An investor-facing comparison should be built from operating and payout data that can be reconciled across sources, rather than a single marketing figure. The remainder of this article sets out what that data should include and how to present it without overstating what any single metric proves.
Payment Method and Fee Basis: What to Record
The first data point to collect is the payment method itself — PPS+, PPLNS, SOLO, or another documented scheme — because it defines who bears block-finding variance and over what period. The second is the exact fee and the reward component it applies to, since two pools quoting different headline fees may not be pricing the same thing.
ViaBTC's published profit-calculation logic is a useful illustration of why fees are not directly additive across payment methods. Under PPS+, the block-reward portion is settled under PPS logic with a 4% fee, while the transaction-fee portion is distributed under PPLNS logic with a separate 2% fee. Under PPLNS, block rewards and transaction fees are distributed together under a single 2% fee (ViaBTC Help Center). Describing PPS+ as carrying a flat "6% fee" would be inaccurate, because the two rates apply to different components of total mining income rather than to the same base.
Settlement timing should be recorded alongside the fee. ViaBTC's documentation states that the PPS-settled block-reward component is paid hourly at current difficulty, while PPLNS-distributed amounts reflect the miner's share of pool hashrate over the prior five difficulty rounds, released after the relevant block reaches six confirmations. These are pool-specific rules and should not be generalized to other PPLNS pools without checking their own documentation.
Separating Miner-Side and Pool-Side Measurements
A comparison loses accuracy when different sources of data are treated as interchangeable. Local hashrate, reported by ASIC firmware or a farm-management system, measures the mining hardware itself, including uptime, fault events, and — where instrumented — power draw. Pool-estimated hashrate, valid shares, and rejected-share counts are reported by the pool dashboard and reflect what the pool observed from submitted work. Settled BTC and account balance come from the pool's payout ledger. For withdrawals to an external blockchain address, pool withdrawal records and confirmed on-chain transactions show what has actually left the pool; internal transfers or other off-chain payout routes should instead be reconciled against the records for the specific transfer method.
These four categories should be logged separately, and none should substitute for another. Pool-estimated hashrate should not be used to calculate a machine's J/TH, since that would combine a pool-side estimate with a hardware-efficiency metric that requires a matched, measured power input. Similarly, a high count of valid shares does not by itself establish strong connection performance if rejected submissions are not also reviewed. Where a pool exposes rejection reasons, those categories should be reviewed separately because different causes require different diagnosis. The pool's own definitions should be used rather than assuming that stale, invalid, duplicate, low-difficulty, or other rejection labels form a universal taxonomy across pools and mining software.
Settlement Timing, Payout Processing, and Reconciliation
Even when income is accurately settled, it is not necessarily withdrawn on the same schedule. ViaBTC processes automatic withdrawals once per day within a defined window (10:00–18:00, UTC+8), and its payout-by-daily-earnings mode reserves mining earnings settled on the payout day and pays only earnings accumulated from previous complete natural days (ViaBTC Help Center; Auto-Withdrawal Payout Modes). An investor comparing a dashboard's real-time earnings estimate to that day's external withdrawal amount is comparing two different things: a running estimate against an amount determined by the selected withdrawal mode and completed settlement periods.
A clean reconciliation separates four fields for each period under review: settled mining reward (with the reward component identified where the payment method has more than one), account balance, withdrawal amount, and withdrawal transaction status. Mixing these fields — for example, treating an unsettled or pending balance as already-realized revenue — can overstate the pool's apparent output for the period being reported.
Pool Share and Concentration: Context, Not a Performance Score
Mempool's pool-hashrate API reports estimated average hashrate and percentage share for labeled pools over a selected trailing range; it is not a real-time census of ownership, nor a measure of uptime or payout quality. In the latest dated observation returned by the one-month hashrate-history endpoint (August 31, 2026), ViaBTC's estimated share was 7.72239% of network hashrate at an average of approximately 70.79 EH/s, while the three largest labeled pools — Foundry USA, AntPool, and F2Pool — accounted for a combined 58.6511% (Mempool pool-hashrate API). The 1m parameter defines the trailing range returned by the endpoint; this individual August 31 observation should not be described as an average over the entire month.
These figures are useful for a dated concentration chart, but two qualifications matter. First, pool attribution depends on identifying and labeling blocks, so the underlying figures are estimates rather than confirmed ownership data. Second, a larger estimated share indicates that a pool finds blocks more often, which can reduce the short-term variance an individual miner experiences under a payment method exposed to pool luck — such as PPLNS — but it does not by itself establish superior fee terms, connection reliability, or long-run expected return. Pool share should be monitored with a stated source and window, not treated as a standing ranking.
A Practical Framework for Presenting Pool Data to Investors
For a matched comparison — for example, testing two pools with the same ASIC model, firmware, site, and electricity arrangement — the following data should be reported for completed, comparable periods:
| Data field | Primary source | How to present it |
|---|---|---|
| Test group | Site or farm records | Number of machines in each group, with the same ASIC model, firmware, site, and operating conditions documented |
| Test period | Site and pool logs | Start and end timestamps aligned across both groups and covering completed settlement periods |
| Local hashrate and uptime | ASIC firmware or farm-management system | Mean local hashrate and worker uptime for each group |
| Pool-observed work | Pool dashboard | Pool-estimated hashrate, valid shares, and any rejection categories using the pool's own definitions |
| Settled BTC | Pool payout ledger | BTC settled during completed settlement periods, with reward components identified where the payment method separates them |
| Pool fees | Current pool rules | Each fee rate shown together with the reward component to which it applies |
| Withdrawals | Pool records plus blockchain or relevant platform records | BTC actually withdrawn, with withdrawal timing reported separately from settlement timing |
These fields evaluate BTC-denominated mining and payout performance. They do not by themselves establish USD profitability, which requires separate assumptions or measurements for factors such as BTC price and operating costs.
A PPLNS comparison in particular should span a period long enough to include completed settlement rounds under the pool's own window definition, since a shorter or partial period can be affected by pool luck in either direction. There is no single universal test duration that applies to every operation; the appropriate length depends on the payment method's settlement window and the variance the operator is prepared to tolerate in the comparison.
Conclusion
A pool selection is better supported by data when its payment rules are stated precisely, its reported figures can be reconciled against independent miner-side and blockchain or transfer records, and its results are compared over completed, compatible settlement periods. Presenting a single fee percentage, or a single pool-share figure, to justify a hashrate allocation decision omits most of the information an investor needs to evaluate the arrangement.
FAQ
Is the pool with the lowest advertised fee always the best choice?
Not necessarily. A fee is only comparable to another fee when both apply to the same reward component under the same payment method; a lower headline fee can still be paired with more exposure to block-finding variance or longer settlement windows.
Does a larger pool share mean better returns for an individual miner?
A larger estimated pool share generally means the pool finds blocks more frequently, which can reduce short-term payout variance under methods like PPLNS. It does not by itself indicate better fee terms, connection reliability, or higher expected long-run return.
Why might my dashboard earnings not match my daily withdrawal amount?
Because settlement and withdrawal are separate processes. Depending on the payout mode, an automatic withdrawal can be calculated from earnings settled on previous complete days rather than the current day's running estimate, so the two figures are not expected to match exactly.
Can I calculate a machine's efficiency (J/TH) from pool dashboard data alone?
No. Pool-estimated hashrate is a pool-side measurement of submitted work, not a substitute for the machine's own measured power draw. Efficiency calculations require matched, measured power input from the hardware or site infrastructure.
References
- ViaBTC Help Center, "How are profits calculated?" — https://support.viabtc.com/hc/en-us/articles/7207397084047-How-are-profits-calculated
- ViaBTC Help Center, "What Is Auto Withdrawal? How to Set Up and Manage It?" — https://support.viabtc.com/hc/en-us/articles/7207389319567-What-Is-Auto-Withdrawal-How-to-Set-Up-and-Manage-It
- ViaBTC Help Center, "How to Choose an Auto-Withdrawal Payout Mode?" — https://support.viabtc.com/hc/en-us/articles/16445070414607-How-to-Choose-an-Auto-Withdrawal-Payout-Mode
- Mempool.space, Pool Hashrate API (1-month endpoint) — https://mempool.space/api/v1/mining/hashrate/pools/1m