To verify mining pool payout accuracy, align the coin, account, and review period; check the accepted work and applicable reward rules; reconcile credited income with account movements; and match each external withdrawal to the payment recorded on the blockchain. Check the amount paid to your destination address, not the total value of the transaction. This guide uses BTC mining and ViaBTC's documented rules as its main example.

Why a Single Hashrate-to-BTC Comparison Is Not a Valid Check

A common but flawed approach to payout verification is comparing one ASIC's displayed hashrate with one day of BTC credited and concluding that the pool "underpaid." This comparison fails because local hashrate, pool-estimated hashrate, accepted shares, credited rewards, and withdrawn BTC are related but distinct measurements, each produced over a different window and for a different purpose.

A more useful question is: did the pool credit the correct reward under the selected payout method, for the valid shares and settlement period that apply to this account? Answering that question requires separating four layers of data: miner-side operation, pool-side accounting, pool balance and withdrawal records, and blockchain settlement.

Layer 1: Miner-Side Operation

The starting point is the ASIC itself. Local hashrate, uptime, hardware error counts, and firmware logs describe what the device is doing, not what the pool has recorded. A miner review should confirm the worker was connected to the correct pool URL and worker name, remained active during the period under review, and did not experience abnormal restarts or connectivity drops. If a worker's results differ materially from comparable units on the same site, the miner-side logs are the first place to look before questioning the pool's accounting.

Layer 2: Pool-Side Accounting

The pool records accepted shares, rejected shares, and a pool-estimated hashrate derived from share submissions over a stated window. Bitcoin's developer documentation explains that a pool sets a share target that is numerically higher—and therefore less difficult—than the Bitcoin network's block target, so that miners submit shares frequently enough for the pool to measure contributed work; only a small fraction of shares will also satisfy the much harder network target (Bitcoin Developer Guide, Mining). Shares are accounting evidence, not a direct record of payable BTC. When shares have different assigned difficulties, their raw count is not enough to compare contributed work: each accepted share must be weighted by its assigned difficulty. Share difficulty determines the work represented by a submission; Bitcoin network difficulty determines the expected work needed to find a block (Analysis of Bitcoin Pooled Mining Reward Systems, Section 7.5).

Rejected shares are the umbrella category; stale, invalid, duplicate, or low-difficulty submissions may appear as separate reasons depending on the dashboard and miner firmware. ViaBTC's documentation states that a rejection rate within 3% falls within its normal range and lists network latency, hardware settings, and firmware as common causes of a higher rate (ViaBTC, rejection-rate guidance). This figure describes ViaBTC's own stated range and should not be treated as a universal industry threshold. A persistently elevated rejection rate warrants investigation of the specific rejection reasons and miner logs before it is treated as a payout discrepancy.

Layer 3: Pool Balance and Withdrawal Records

Credited mining income, unpaid balance, and an on-chain withdrawal are three separate events, and conflating them is a frequent source of confusion. Reward settlement adds income to the pool account; withdrawal eligibility depends on the account meeting the applicable payout conditions; and the on-chain payment occurs only when the pool broadcasts a transaction to the configured address.

ViaBTC's current documentation specifies a minimum external BTC auto-withdrawal amount of 0.001 BTC, while withdrawals to the user's own ViaBTC main or sub-account have no minimum, provided the amount is greater than zero (ViaBTC, Auto Withdrawal). A credited balance that remains below the relevant threshold is not evidence of a missing or incorrect payout; it simply has not yet met the withdrawal condition. The same documentation distinguishes Payout by Account Balance from Payout by Daily Earnings, noting that the daily-earnings mode excludes income settled on the withdrawal day itself and instead distributes earnings from previously completed days. A reader comparing a given day's dashboard credit with that same day's withdrawal amount, without accounting for this exclusion, may incorrectly conclude that income is missing.

For the same BTC account and review period, reconcile the balance using the actual account records:

Opening BTC balance + BTC credits during the period − BTC debits during the period = Closing BTC balance.

Include mining income and any deposits, transfers, conversions, revenue-sharing deductions, or withdrawals only where they actually affected this account's BTC balance. Count each movement once; if mining income is already shown net of pool fees, do not deduct those fees again. ViaBTC's History page provides billing details and withdrawal, deposit, and conversion records (ViaBTC, Assets and Bills). A matching balance confirms that the recorded movements reconcile; it does not independently establish that the pool calculated the mining reward correctly.

Layer 4: Blockchain Settlement

The final layer is the on-chain transaction. For an external BTC withdrawal that has been broadcast, obtain the transaction ID and destination address from the withdrawal record. In a block explorer, find the transaction output or outputs paying that address and compare their combined value with the amount recorded for that withdrawal. Check the confirmation status as well. A Bitcoin transaction can contain multiple outputs, so neither its total output value nor its transaction fee represents your individual payment (Esplora, Transaction Format). Mempool.space provides public explorer data and REST APIs covering blocks, transactions, and confirmation status that can serve as an independent reference point (mempool.space API documentation). It is important to keep the pool's credited-income period separate from the withdrawal transaction amount, since a single withdrawal may combine a prior balance or exclude earnings not yet eligible under the selected withdrawal mode.

The on-chain check verifies that the recorded payment was sent to the expected address and whether it has been confirmed. It does not establish whether the shares and mining rewards were calculated correctly; those checks depend on the pool's accounting records and reward rules.

Matching Time Windows Before Comparing Figures

Many apparent discrepancies result from comparing figures measured over incompatible windows rather than from an actual calculation error. ViaBTC documents that its real-time pool hashrate reflects the preceding 10 minutes, while its daily hashrate statistic reflects the preceding 24 hours (ViaBTC, hashrate discrepancy explanation). An ASIC's own display may refresh every few seconds, but that refresh interval is not necessarily its hashrate averaging window. Depending on the device and selected metric, the local figure may represent a short interval or an average over the device's running period. Comparing a short-window local reading with a 24-hour pool average can therefore show a difference caused by measurement timing rather than a payout error.

Similarly, ViaBTC's Profit Detail records are reported on a UTC+8 basis, while miner logs may use local time or UTC. Before reconciling any figures, align the time zone and the measurement window: compare a 24-hour local operating period with a 24-hour pool-reported period, not a short device snapshot with a daily or settlement-period total.

Payout Method Matters: PPS+ and PPLNS

The expected pattern of earnings depends entirely on the selected payout method, and it is not valid to evaluate one method's output as though it followed another method's logic.

Under ViaBTC's documented BTC PPS+ model, the block-subsidy component is calculated using PPS logic—based on difficulty-weighted accepted work, the Bitcoin network difficulty applicable to that work, and the current block subsidy—with a 4% fee, while the transaction-fee component follows PPLNS logic, allocated according to the miner's share of hashrate during the last five difficulty rounds after a found block reaches six confirmations, with a 2% fee (ViaBTC, payout calculation rules). The block subsidy is 3.125 BTC per block following the April 2024 halving; transaction fees are additional and variable, so the subsidy is not the total block reward (Bitcoin Core, Subsidy and Block Reward Calculation). A PPS+ miner should reconcile the subsidy and transaction-fee components separately. For comparable accepted work and unchanged network difficulty, the PPS subsidy component is comparatively steady, while the PPLNS transaction-fee component varies with the pool's actual block results and the fees those blocks contain.

Under ViaBTC's documented BTC PPLNS model, the block subsidy and transaction fees are both distributed under PPLNS logic, again using the last five difficulty rounds after six confirmations, with a 2% fee applied to the combined reward. Because PPLNS payouts depend on actual blocks found by the pool and the miner's contribution during the relevant accounting window, short-period PPLNS earnings can show more variation than a simple hashrate-based estimate would suggest. This is an expected property of the reward model, not necessarily evidence of miscalculation.

These figures describe ViaBTC's current published terms and may be subject to change; readers should confirm live fee and settlement terms in the pool's official documentation before relying on them for precise reconciliation.

A Practical Verification Checklist

The following steps provide a structured way to review a payout before escalating a concern to pool support.

First, confirm the mined coin, the specific pool account or sub-account, the worker name, and the payout method in effect during the review period, and record the time zone used for comparison.

Second, review worker uptime, difficulty-weighted accepted work, and rejected-share reasons over a window that matches the pool's reporting period. Do not use raw share counts to compare work submitted at different share difficulties. Check miner logs for connection interruptions or firmware issues if rejections increased.

Third, review the settlement logic for the applicable payout method: for PPS+, check the block-subsidy and transaction-fee components separately; for PPLNS, check the applicable accounting window and the pool's confirmed blocks during that period.

Fourth, identify the mining-income credits for the period in Profit Detail or the equivalent settlement record, then reconcile the opening balance, all recorded BTC credits and debits, and the closing balance. Confirm the auto-withdrawal mode and threshold, any applicable revenue-sharing deduction, and whether a withdrawal includes a prior unpaid balance. A reconciled balance checks account movements; the reward calculation must still be assessed against accepted work and the selected payout method.

Fifth, match each broadcast external withdrawal record to its transaction ID. In a block explorer, verify the output or outputs paying the configured destination address, compare their value with that withdrawal record, and check confirmation status. Keep this payment check separate from verifying the mining reward calculation.

When Exact Reconstruction Is Not Possible

A miner can generally confirm whether results are consistent with the pool's documented rules and the account's own records, but may not be able to independently recreate every unit of credited income from public data alone. Exact reconciliation of a PPLNS or PPS+ payment typically requires account-level information that is not exposed through a public dashboard, including eligible share-difficulty data, the specific five-difficulty-round window applied, confirmed-block status, and settlement timestamps. When a discrepancy cannot be resolved through the checks above, the appropriate next step is to request the relevant account records from the pool's support channel rather than attempting to reverse-engineer the exact figure from hashrate alone.

FAQ

Why does my ASIC's hashrate differ from the hashrate shown in the pool dashboard?

They may be measured over different windows and by different methods. The ASIC's local averaging window depends on the device and the selected display metric; a display that refreshes every few seconds may still show an average over a longer period. The pool estimates hashrate from accepted shares over a stated window—for example, ViaBTC's real-time figure reflects the preceding 10 minutes and its daily figure reflects the preceding 24 hours. Mismatched windows are a common cause of an apparent gap, so check the actual averaging periods before treating a difference as an accounting error.

Does a high rejection rate mean I lost that percentage of my mining income?

Not directly. A rejection rate describes the share of submitted shares the pool did not accept; it does not translate one-to-one into a percentage of lost BTC income, since payout calculations depend on the specific payout method and its underlying formula. A persistently elevated rejection rate is still worth investigating, since it may indicate network, firmware, or hardware issues worth correcting.

If my wallet hasn't received a deposit yet, does that mean the pool underpaid me?

Not necessarily. A missing deposit can reflect a balance that has not yet reached the applicable withdrawal threshold, a selected withdrawal mode that excludes same-day earnings, pending processing, or normal blockchain confirmation time, rather than an incorrect reward calculation.

Can I calculate my exact PPLNS payout myself from public pool statistics?

Full reconstruction is often difficult because PPLNS settlement depends on account-level data, such as the applicable difficulty-round window and confirmed-block status, that is not fully exposed on a public dashboard. Readers can check whether their results are consistent with the pool's documented rules and account records, but an exact independent reproduction from hashrate figures alone is generally not possible.

References

• Bitcoin Developer Guide — Mining
• ViaBTC Help Center — How are profits calculated?
• ViaBTC Help Center — Why is the Hashrate Shown in the Mining Pool Lower than that of the Mining Machine?
• ViaBTC Help Center — What if the Rejection Rate is High?
• ViaBTC Help Center — What Is Auto Withdrawal? How to Set Up and Manage It?
• Mempool.space REST API Documentation
• Analysis of Bitcoin Pooled Mining Reward Systems — Section 7.5, Variable Difficulty Shares
• Bitcoin Core — Subsidy and Block Reward Calculation
• ViaBTC Help Center — How to View My Assets and Bills?
• Esplora HTTP API — Transaction Format