How Do ViaBTC Mining Statistics Track Mining Pool Hashrate?

ViaBTC tracks pool hashrate from mining work submitted by connected workers rather than from ASIC dashboard readings. Its real-time pool hashrate uses the previous 10-minute average, while the daily hashrate uses the previous 24-hour average. A miner can therefore report 200 TH/s locally while ViaBTC shows 185 TH/s without a hardware fault. Share timing is probabilistic, and short windows can move above or below the miner’s rated capacity. ViaBTC also separates hashrate measurement from payout rules: current pricing lists a 4% fee for the PPS component under PPS+ and 2% for PPLNS, with the payment method affecting reward accounting rather than the basic measurement of submitted work.

A pool cannot measure the electrical or chip-level output of an ASIC every second. It receives mining jobs, waits for valid shares, checks those shares against the assigned target, and uses the accepted work to estimate how much hashing power a worker contributed over a chosen period. In Bitcoin mining, this process matters because an ordinary share is much easier to produce than a full network block, so a pool can collect thousands or millions of share events without waiting for a miner to discover an actual block.

The distinction becomes visible when a machine is rated at 200 TH/s. If that miner has been running for only 3 hours after a restart, its local panel may already show close to the expected operating rate, while a pool statistic based on the previous 24 hours still contains 21 hours of earlier inactivity. A simplified uptime example gives 200 × 3 ÷ 24 = 25 TH/s as the contribution to that 24-hour average if the other 21 hours contained no work. The real statistic also reflects the actual share record, but the time-window effect is easy to see from this 12.5% uptime case.

ViaBTC states that its real-time pool hashrate is calculated from the average hashrate over the previous 10 minutes, while a mining machine may refresh its own displayed value about every 5 seconds. That creates a 120-to-1 difference in update interval. A 5-second local reading can react almost immediately to a restart, while a 10-minute pool value changes more gradually because older observations remain part of the average.

“Real-time” on a pool dashboard is therefore a rolling statistic, not an instantaneous ASIC measurement.

That 10-minute window also reduces the effect of random share arrival. Suppose a 100 TH/s worker submits unusually many valid shares during one short interval. The pool estimate may temporarily rise to 110–120 TH/s even though the hardware did not increase its physical output by 10–20%. The opposite can occur when share arrivals are sparse. Over a larger sample, such as 24 hours, random variation has less influence on the displayed average.

Share quality matters as well. A machine can complete hashing work locally but still produce results that are rejected by the pool. If a worker produces 1,000 share submissions and 30 are rejected, the nominal rejection proportion is 3%. The exact reason can differ by mining setup, but repeated rejection, stale work, communication delay, or invalid results can reduce the amount of useful work reflected in pool statistics. Looking only at the ASIC’s local hashrate can therefore miss a mismatch between computing activity and accepted pool work.

The relationship becomes more useful when several measurements are compared in the same time window. Consider a 50-machine farm with each ASIC rated at 200 TH/s. The nominal installed capacity is 10 PH/s. If the local panels average 9.8 PH/s while ViaBTC shows 9.5 PH/s over 10 minutes, the difference is about 3.1%. A small gap of this size may come from normal statistical variation, restart timing, network conditions, or different averaging methods. A persistent 15% gap over 24 hours deserves a much closer technical review.

ViaBTC also distinguishes its 24-hour hashrate from the shorter real-time figure. A daily value is based on the previous 24 hours, so downtime continues to affect the displayed average after a miner has returned online. Suppose a 200 TH/s ASIC is offline for 2 hours and runs for the other 22 hours. With a simplified constant-output assumption, the 24-hour average becomes 183.3 TH/s, which is 8.3% below its 200 TH/s operating rate. The local dashboard may return to near 200 TH/s within minutes, but the daily statistic will recover much more slowly.

The same time-window logic applies to larger pools. Pool hashrate is an aggregate estimate built from the work received from many workers. If 10,000 miners contribute around 180 TH/s each, the nominal combined capacity is 1.8 EH/s. Losing 1% of those machines would remove about 18 PH/s from nominal capacity, while losing one 180 TH/s miner would change the pool total by only 0.01%. This scale difference is why individual worker monitoring is more useful for diagnosing one ASIC than a pool-wide hashrate chart.

Network statistics add another layer. ViaBTC pool hashrate describes the computing power observed by the pool, while Bitcoin network hashrate is estimated from network-level block production and difficulty data. The two numbers can move differently over short periods. In a hypothetical 2026 snapshot, a pool holding 8% of estimated network hashrate would not be expected to find exactly 8% of blocks in every 24-hour period because block discovery follows a probability distribution rather than a fixed schedule.

Payment data uses hashrate information in another way. ViaBTC currently lists PPS+ and PPLNS. Under its published pricing, the PPS portion has a 4% fee, while PPLNS is listed at 2%; its PPLNS calculation uses a miner’s hashrate relative to pool hashrate, with the relevant share period covering the previous 5 difficulty rounds for block distribution. The pricing page also states that PPLNS rewards are paid after a block receives 6 confirmations.

Metric	Window or reference	Example reading	What it tells the miner
Local ASIC hashrate	About 5 seconds refresh	200 TH/s	Recent machine-side output
ViaBTC real-time hashrate	Previous 10 minutes	188 TH/s	Recent pool-observed work
ViaBTC daily hashrate	Previous 24 hours	176 TH/s	Sustained recent performance
Worker rejection rate	Sample of 1,000 shares	3% rejected	Quality of submitted work
Farm capacity	50 × 200 TH/s	10 PH/s	Installed nominal capacity

The table shows why one displayed number cannot replace the others. If the local rate is 200 TH/s, the 10-minute pool rate is 188 TH/s, and the 24-hour value is 176 TH/s, the three readings are describing three different time scales. The daily figure is 12% below the local number, while the 10-minute figure is 6% below it. Those percentages are more useful when the worker has been operating continuously for several hours rather than only a few minutes.

Restart behavior is another measurable source of difference. ViaBTC notes that many miners need roughly 10–15 minutes to reach normal hashrate after a reboot, while some models can take around 30 minutes. A farm with 20 machines that each require 15 minutes to recover can temporarily lose 5 machine-hours of full operation during a coordinated restart. If each machine is rated at 200 TH/s, that short event represents 1,000 TH/s-hours of unavailable capacity.

Network quality should then be checked against the hashrate record. If a worker stays near 200 TH/s locally but its ViaBTC average repeatedly falls below 170 TH/s during periods of unstable connectivity, the 15% gap is more informative than either number alone. Repeated disconnects, delayed jobs, and rejected submissions can reduce accepted work even when the ASIC keeps reporting a normal internal hashrate.

The fee setting should be read separately from the hashrate chart. Current ViaBTC pricing identifies ViaBTC Pool Fees as 4% for the PPS component under PPS+ and 2% for PPLNS. Under PPS+, the pool pays according to valid shares and assumes the pool-side risk associated with block luck, while PPLNS ties reward distribution to the miner’s share of pool hashrate across the stated 5-difficulty-round period.

For a miner reviewing daily statistics, a practical comparison is to record the local average, ViaBTC 10-minute average, ViaBTC 24-hour average, worker uptime, and rejected-share percentage at the same time each day. A 7-day sample produces 168 hours of observations and is much more useful than a single screenshot. If the local and pool values remain within roughly 2–5% for most of that period, the difference may be normal for the hardware and measurement methods; a stable 10–15% gap warrants checking configuration, network quality, hardware errors, and restart history.

Profit calculations use their own timing rules as well. ViaBTC states that profit statistics are based on UTC+8 and that its estimated daily yield is calculated from recent conditions, with difficulty and transaction fees affecting the result. Its current documentation also states that PPS+ is the default payment method and that estimated daily earnings are based on recent historical data rather than a guaranteed amount.

A worker that reports 200 TH/s for 24 hours should therefore not be expected to show exactly 200 TH/s in every ViaBTC field. The pool is measuring accepted mining work over defined statistical windows, while the ASIC is reporting a machine-side estimate at a much shorter interval. With a 10-minute pool window, a 24-hour pool window, a 3% rejection rate, and a 15-minute post-restart recovery period, small differences are normal; persistent gaps of 10% or more deserve comparison across worker status, share records, network conditions, and longer averages.