Total Coins Mined: Reading Pool History Correctly

A pool's lifetime output is an honest number that answers almost none of the questions miners ask it. It is cumulative, it counts every coin the pool ever produced, and it includes the shares of every other miner who used the pool before you arrived. Your own position is a single ratio: 1000 TH/s against a network of 950.3 EH/s is 1.05 × 10^-6 of the chain, worth 0.00047353 BTC a day, roughly $40.39 at $85,294 per BTC.

What a lifetime total actually counts

Pool history pages usually carry several figures that look similar and mean different things. The largest is the pool's all-time production, a cumulative counter across every coin and every miner since the pool opened. The smallest is your current unpaid balance. Between them sit your all-time credited total and your withdrawn total, and only the last of those is money you can spend.

The confusion starts when those columns are read as a sequence. They are not. The pool total rises when anyone mines; your credited total rises when your shares are settled; your balance falls when you withdraw. A miner watching the first column for reassurance is watching someone else's contribution as much as their own.

The useful comparison is a ratio, not a level. Divide your own hashrate by the network hashrate that difficulty implies — 950.3 EH/s at 132.76 T — and multiply by 450 BTC, the daily network issuance at a 3.125 BTC subsidy across 144 blocks. That formula needs no pool figure at all, because under PPS+ the block-reward component is settled per accepted share rather than from a split of the pool's history.

One number on a history page does describe the pool's behaviour rather than its size: Pool Luck, the ratio of blocks found to blocks expected. It explains why a pool's daily output jumps around without any miner changing a setting, and it is worth reading before concluding that a quiet day on the history chart reflects anything about your own machines.

Why per-chain totals are not comparable

Historical totals also mislead across chains. A pool mining several coins accumulates numbers of very different sizes for the same amount of effort, because block subsidies and block cadences differ. Comparing a BTC total against an LTC total is comparing two issuance schedules, not two levels of activity.

Two details in that table change how a history page should be read. LTC is merged-mined with DOGE, so a single unit of work produces two outputs and the DOGE arrives as an additional merged-mining output whose value has to be treated separately. KAS blocks arrive about ten times a second, which means a KAS history page moves visibly within minutes while a BTC history page can sit unchanged for a long stretch. The same interface, two very different clocks.

Worked example: 1000 TH/s against a lifetime total

Take 1000 TH/s with PPS+. Against 950.3 EH/s the share is 1.05 × 10^-6, and against 450 BTC a day that is 0.00047353 BTC per day, about $40.39 gross or $38.77 after the listed 4% fee on the block-reward component. An hour of that is 0.00001973 BTC, near $1.68, and a 30-day month is 0.014206 BTC, roughly $1,211.68.

Now suppose the pool's history page shows a lifetime total of six figures of BTC. Your contribution to that number is not the interesting part — what matters is the monthly delta. Six months of steady operation at this size adds 0.085235 BTC to both your credited total and the pool's lifetime counter, about $7,270 at the price above. Comparing one month to the next is how a miner sees their own trend; comparing to the lifetime figure is how a miner sees nothing at all.

Credited, confirmed and paid

The state of a balance depends on the method. Under PPS+ the block-reward component is settled per accepted share at current difficulty and paid every hour, so the gap between work done and value credited is about an hour. The transaction-fee component follows PPLNS logic at a listed 2%, which is why some entries on a statement appear in uneven amounts rather than matching the hourly rhythm.

Under PPLNS there is an extra state between work and money. A distribution is created when the pool finds a block, then waits for 6 confirmations before it is allocated, and the allocation uses each miner's share of pool hashrate across the last 5 difficulty rounds. Until the pool finds a block, the work exists but no figure exists; a history page during a dry spell is not wrong, it is simply empty.

Historical totals are also where an old miner's habits show. A statement that shows regular small credits is a PPS+ account behaving normally; one that shows lumpy credits separated by quiet periods is PPLNS, or a PPS+ account whose fee-component entries are being misread as the whole payout.

Reading history without over-reading it

Three habits make the history pages useful. Read the 30-day delta rather than the lifetime figure, since only the delta belongs to you. Recompute the expectation at each difficulty change, because the +1.90% estimate on the next retarget will shift every future increment of that counter. And check the pool's own course with ViaBTC Pool Hashrate, which shows whether the pool's contribution to the network is growing in step with yours.

When a credit looks wrong, compare it against the arithmetic before comparing it against a feeling. The pool statistics pages give the pool-level view of the same period, and the multi-currency wallet shows where the coin ended up after withdrawal, complete with the zero-fee mining payout leg that sits between a credited balance and a spendable one.

Frequently asked questions

Is cumulative total coins mined a measure of my earnings?

No. It is the pool's all-time production across every miner and every coin it has supported. Your earnings are the increments in your own credited history, which is why the monthly delta is the only figure worth comparing.

Why does the total keep rising if I am not mining?

Because other miners are. The counter records the pool's output, not yours, and it never decreases — a history page is designed to accumulate rather than to reconcile.

How do confirmations delay a credited balance?

Only under PPLNS, where allocations wait for 6 confirmations and then split by share of pool hashrate over the last 5 difficulty rounds. PPS+ settles the block-reward component every hour at current difficulty, so the delay there is measured in minutes rather than blocks.

Read the delta, not the monument

A lifetime total is a monument: large, static in meaning and impossible to act on. Set a monthly routine instead — record credited BTC, hours mined and the difficulty in force, then compare the increment against the 0.00047353 BTC a day that 1000 TH/s implies. When those two agree, the history page has done its job and the next decision belongs to your power bill, not your dashboard.

Data and sources: ViaBTC fee schedule^[1], pool statistics and wallet documentation^[2][3]. Network difficulty 132.76 T, implied network hashrate 950.3 EH/s, the 3.125 BTC subsidy, 144 blocks per day, an estimated next adjustment of +1.90%, BTC at $85,294, LTC at $60.68 and KAS at $0.042829 were read from public chain data and market feeds; read 22 Sept 2026. Figures are arithmetic on those inputs and change with difficulty, price and uptime.