The 6-Confirmation Wait: What Happens Between Block Found and Paid
A block found at 14:03 is not income at 14:03. Under PPLNS, the pool distributes that reward only once the block has six confirmations — roughly an hour at the ten-minute target — and splits it using each miner's share of pool hashrate across the last five difficulty rounds. For a miner with 1.5 PH/s inside a pool holding 5% of the network, that hour covers about 0.0000938 BTC, roughly $7.92, sitting in limbo.
Key takeaways
- PPLNS distributions require 6 confirmations, about an hour at the ten-minute block target, and weight your contribution over the last 5 difficulty rounds — roughly ten weeks.
- PPS+ bypasses the wait entirely for the block-reward component: it settles per accepted share hourly at current difficulty, at a listed 4% fee, with transaction fees distributed at a listed 2% fee.
- A 5% pool expects 7.2 blocks a day, so a 1.5 PH/s miner inside it receives about 0.0000938 BTC per block — roughly $7.92 — roughly 22 times in a 72-hour window.
- Confirmations delay timing, not totals. The material risk in the window is an orphaned block, whose distribution is recomputed — a risk the miner carries under PPLNS and the pool carries under PPS+.
The core idea
Bitcoin's block interval averages ten minutes by design, and a block is only considered settled by convention once five further blocks have been built on top of it. Six confirmations is therefore not a pool policy but a widely used safety convention, and it exists because a chain can reorganise: a block that looked final can be replaced by a competing chain, taking its reward with it.
Payment methods handle that risk differently. Under PPLNS, block reward and transaction fees are distributed together at a listed 2% fee, after the block reaches six confirmations, weighted by each miner's share of pool hashrate over the last five difficulty rounds. Under PPS+, the block-reward component is settled per accepted share on an hourly cadence tied to current difficulty at a listed 4% fee, so the confirmation clock does not appear in the miner's timeline at all — the pool absorbs both pool luck and orphan risk.[1]
| Stage | Typical elapsed time | Who acts | What the miner sees |
|---|---|---|---|
| Pool finds a block | t = 0 | Pool hardware and firmware | Block appears in the pool's block record |
| Block broadcast, first confirmation | About 10 minutes | The network | "1 confirmation" on a block explorer view |
| Confirmations 2 to 5 | About 20 to 50 minutes | The network | Block buried deeper; reorg risk falling |
| Sixth confirmation reaches | About 60 minutes | Protocol convention | Distribution becomes payable |
| Share weighting | Seconds after that | The pool | Shares from the last five difficulty rounds are weighted |
| Balance credited | Per pool schedule | The pool | Withdrawable or convertible balance |
| PPS+ alternative | Every hour, independent of confirmations | The pool | Hourly credit at current difficulty |
Two rows carry more weight than they appear to. The confirmation rule means that a miner's expected income for the day is unaffected but its arrival is deferred by up to an hour per block; over a 72-hour window that is a timing shift, not a shortfall. The five-round weighting is the more consequential rule for anyone planning to change pools: shares keep contributing to distributions for about ten weeks, so a miner who leaves immediately forfeits a tail of future payments.
How it plays out at scale
Pool size determines how often the wait occurs. A pool holding 5% of network hashrate expects 7.2 blocks a day, so its miners experience the confirmation window roughly every three hours and twenty minutes. A pool holding 0.5% expects 0.72 blocks a day, which stretches the wait to about 33 hours on average, and a pool holding 10% expects 14.4 blocks a day, or one roughly every 100 minutes.
Your own hashrate then determines how much money sits inside each window. In a 50.15 EH/s pool — 5% of a 1,003 EH/s network — a 1.5 PH/s miner holds about 0.003% of the pool's hashrate. Each 3.125 BTC subsidy therefore splits into a slice of about 0.0000938 BTC for that miner, near $7.92 at the 21 September 2026 BTC/USD price of 84,692, and those slices arrive about 7.2 times a day with an hour of latency each.
The chart is also the fastest way to decide whether the confirmation rule concerns you. At 15 TH/s, 0.02 BTC takes about 2,970 days, so payment timing inside a pool is irrelevant to a hobby miner's decision. At 150 TH/s it takes about 297 days, at 1.5 PH/s about 29.7 days, and at 15 PH/s roughly 2.97 days — which is the scale at which deferred distribution and pool share start to matter for working capital.
One adjacent detail belongs in the same discussion because miners meet it while moving coins rather than earning them. If an outbound transaction sits unconfirmed during a busy period, the transaction accelerator exists for that case: free submission covers transactions of 0.5 KB or smaller at a fee rate of at least 0.0001 BTC/KB, with the free quota refreshing hourly and requests processed in submission order, and paid acceleration is settled from account assets in BTC, BCH or LTC.[2] The constraints matter: submitted requests cannot be cancelled or refunded, double-spend transactions are not supported, and a transaction whose inputs are still unconfirmed cannot be accelerated until the earlier one clears.
Two scenarios compared
Scenario one: PPLNS at 1.5 PH/s in a 5% pool. Over 72 hours the pool expects about 21.6 blocks, and the miner's slice of each is roughly 0.0000938 BTC. Total expected output across the window is about 0.002019 BTC, near $170.96, arriving in 21 or 22 lumpy credits, each about an hour after its block. Income is uneven within the window and depends on the pool's actual block count rather than on its hashrate claim alone.
Scenario two: PPS+ at the same 1.5 PH/s. Settlement is per accepted share against current difficulty, hourly, so the same 72 hours produces about 72 credits of 0.0000280 BTC each — about $2.37 — totalling the same 0.002019 BTC, near $170.96. The confirmation rule never enters the miner's timeline, and orphan risk sits with the pool, which is what the higher listed fee on the block-reward component reflects.
Both totals are equal on average, which is the useful part of the comparison: the six confirmations do not cost a PPLNS miner money, they change when the money arrives and who carries the timing risk. The distribution code recalculates for an orphaned block, and if the pool's luck is poor the miner's realised income falls below the arithmetic expectation — visible in the pool's block record long before it shows up as a smaller balance.
Common failure modes
- Reporting a pending block as income. A block found but unconfirmed is not yet a distribution. Building a cash-flow plan on it invites a surprise when it takes an hour longer than expected.
- Leaving a pool without checking the five-round tail. Because shares from the last five difficulty rounds keep counting, a departure has a payment tail measured in weeks, and its size depends on how closely you track it.
- Assuming confirmation counts are cosmetic. On a wallet or deposit view they are a risk threshold; treating one confirmation as final is how reorg exposure enters an operation.
- Sending coins rapidly in a chain. A transfer whose inputs are unconfirmed cannot be accelerated, so frequent small sweeps can strand the next transfer in the queue.
- Confusing pool reporting with pool performance. Verify block counts and share against published pool and network data instead of trusting a dashboard snapshot — the mining statistics view is the place to cross-check a ViaBTC BTC Mining Pool state reading.
Frequently asked questions
Does the payout method change my average income?
It changes the variance and the fee, not the underlying expected value: your share of network hashrate still sets the ceiling.
How often should a miner check pool statistics?
Weekly is enough for cash flow, daily if you are reconciling worker uptime or chasing a hashrate fault.
Why do mining pools wait for six confirmations?
Because a block can be replaced by a competing chain before it is buried. Waiting for six confirmations is a convention that makes a distribution safe to treat as final; under PPLNS the pool waits, and under PPS+ the pool carries that risk on the block-reward component instead.
Is there a way to skip the confirmation wait?
Only by choosing a settlement method that does not depend on it. PPS+ credits the block-reward component hourly against current difficulty, so confirmations do not gate the miner's income. There is no way to accelerate the chain itself.
Plan around the interval, not against it
Treat a found block as pending income, not cash, and choose the settlement method based on who you want to hold the timing risk: the pool, under PPS+, or your own operation, under PPLNS. Then keep an eye on the two numbers that decide when the coins actually move — the pool's block count over the last five difficulty rounds and the current difficulty itself. A working income calculator plus a weekly look at pool data covers both, and that is the whole schedule the confirmation rule demands from you.
Data and sources: ViaBTC fee schedule and settlement rules[1] and ViaBTC transaction accelerator documentation[2]. Network difficulty (132.76 T), network hashrate (1,003 EH/s), 144 blocks per day at a 3.125 BTC subsidy and the BTC/USD price of 84,692 were read from public chain data and market feeds on 21 September 2026; block counts, per-block slices, 72-hour totals and days-to-target figures are our own calculation from those inputs and are for illustration. Values change with difficulty, price and network conditions.