Bitcoin's coinbase maturity rule means that an output created by a coinbase transaction at block height N can first be spent in block N+100. A mining pool can credit a miner's account before that point because internal accounting does not spend the coinbase output. If the pool makes an on-chain payout before that output can be spent, it must use other spendable funds.

These are separate processes: Bitcoin consensus governs when a particular coinbase output can be spent, while the pool's payment method and withdrawal rules govern account credits and payouts. Their timelines do not need to match.

What a coinbase transaction is

Every Bitcoin block contains exactly one coinbase transaction, and it is always the first transaction listed in the block. Unlike an ordinary transaction, a coinbase transaction has no real previous output as its input; it is the mechanism through which new bitcoin is created and through which the miner or pool that produced the block claims that block's reward.

The reward claimed by a coinbase transaction has two components. The first is the block subsidy, a fixed amount set by Bitcoin's issuance schedule that halves approximately every four years. Following the fourth halving at block height 840,000 in April 2024, the subsidy is 3.125 BTC per block. The second component is the sum of transaction fees paid by all other transactions included in that block. The combined total is often referred to as the block reward, but the subsidy and the fee total are governed by different logic and should not be treated as a single fixed number — fee income varies block by block depending on network congestion.

The subsidy represents newly issued BTC; transaction fees come from existing BTC. Both can be claimed through coinbase outputs, and those outputs are subject to the same maturity restriction under Bitcoin's consensus rules. The restriction does not apply only to the subsidy portion (Bitcoin Developer Guide).

Maturity and confirmations

A Bitcoin node rejects a transaction spending a coinbase output if the height of the block containing that spending transaction is less than 100 blocks above the height where the coinbase was created. In other words, an output created in block N can first be spent by a transaction included in block N+100. It does not have to wait until block N+100 has already been mined before a spending transaction can be included in a block (Bitcoin Core consensus validation, maturity constant).

This rule exists because a freshly mined block can, in principle, be displaced by a chain reorganization — a competing chain with more accumulated proof of work that removes the original block and its coinbase transaction from the active chain. Requiring this gap before a coinbase output can be spent reduces the risk of subsequent transactions depending on a reward that disappears in a reorganization.

It is important not to conflate this maturity requirement with a receiving service's confirmation policy. For a transaction included in the active chain, its confirmation count is the current chain-tip height minus its block height, plus one. When the tip is N+99, the coinbase in block N has 100 confirmations, and a transaction spending it can first be included in the next block, N+100.

A regular Bitcoin transaction is often considered settled after some number of confirmations chosen by the receiving party or service — commonly six, though the appropriate number depends on the transaction value and the receiver's own risk tolerance. Coinbase maturity, by contrast, is a fixed, protocol-enforced restriction on spending coinbase outputs, not a configurable acceptance policy.

Pool accounting vs on-chain reward

In the custodial pool payout model discussed here, the coinbase transaction pays the subsidy and fees to outputs controlled by the pool, and miners receive separate payouts. From that point, the coinbase output and the pool's accounting are governed by different rules.

On the protocol layer, the pool cannot spend its new coinbase output before the permitted block height, regardless of its size or infrastructure.

On the pool-accounting layer, the pool applies its payment method to determine what each contributing miner is owed. Under ViaBTC's documented rules, this works differently depending on the payment method. Under PPS+, the subsidy-derived portion of earnings is settled hourly using PPS logic based on submitted shares and current network difficulty. These credits do not require the pool to first find a corresponding block. The transaction-fee portion uses PPLNS logic: it is calculated once a found block completes six confirmations, based on each miner's share of hashrate contributed over the preceding five difficulty rounds. Under PPLNS, that calculation applies to both the subsidy and transaction fees (ViaBTC Help Center).

The six-confirmation condition determines when the relevant pool earnings are calculated; it does not make the coinbase output spendable. Crediting an account balance is an accounting entry, not a spend of that output. Waiting for confirmations generally reduces exposure to short chain reorganizations, but this is separate from Bitcoin's mandatory maturity rule.

When the pool subsequently sends BTC to a miner's external wallet through a separate, ordinary Bitcoin transaction, the miner receives a regular transaction output without the coinbase maturity restriction. If that payout occurs before a particular coinbase output can be spent, the payout must use other spendable funds — for example, previously matured mining revenue. This follows from Bitcoin's spending rules; it is not a claim about ViaBTC's specific treasury practices or a one-to-one link between each account credit and a found block.

Why timing differs

Three separate sets of conditions govern reward maturity, account credits, and external payouts. They do not form a universal sequence in which the pool must first find a block before a miner can earn an account credit.

• Coinbase maturity: Bitcoin consensus determines the earliest block in which a particular coinbase output can be spent. The pool cannot shorten this requirement.
• Pool settlement: The payment method determines how earnings are calculated and credited. ViaBTC's PPS component is settled hourly without requiring a corresponding found block; its PPLNS calculations depend on actual blocks and the documented confirmation condition.
• Withdrawal processing: The selected payout mode, applicable minimum payment, and processing schedule determine when an eligible amount is sent out.

For example, ViaBTC's documented minimum for BTC auto-withdrawals to an external address is 0.001 BTC, but the applicable threshold also depends on the minimum payment configured for the account. In account-balance mode, the balance must meet the applicable payment conditions. ViaBTC also offers a daily-earnings mode, which applies its conditions to the previous day's earnings. Auto-withdrawals are processed once daily between 10:00 and 18:00 (GMT+8); reaching 0.001 BTC alone should not be treated as a guarantee of immediate payment (auto-withdrawal rules, minimum payment settings). These product rules were checked on October 14, 2026.

A credited balance therefore does not prove that a particular block reward has matured, and a withdrawal threshold is not a maturity requirement.

Questions before expecting a payout

Does coinbase maturity delay my pool account balance?

Not necessarily. Coinbase maturity restricts spending a specific output on-chain. A pool can record an internal account credit before that output can be spent. Under PPS, earnings also do not require the pool to first find a corresponding block.

If my balance updates quickly, does that mean the pool bypassed the 100-block rule?

No. An account update is an accounting entry. If an on-chain payout is made while a particular coinbase output is still immature, the transaction must use other spendable funds.

Why does my pool wait for several confirmations before crediting a found block?

Waiting for confirmations generally reduces the risk that a short chain reorganization removes a found block before its reward is allocated. ViaBTC documents a six-confirmation condition for its PPLNS calculations, including the transaction-fee component of PPS+. That settlement condition is separate from coinbase maturity.

Is a withdrawal minimum the same thing as a maturity requirement?

No. A withdrawal minimum is a condition for a pool payout. For ViaBTC's BTC auto-withdrawals to an external address, the documented minimum is 0.001 BTC, with eligibility also depending on the configured threshold and selected payout mode. None of these settings changes when a coinbase output can be spent.

How can I verify when a specific block reward can first be spent?

Find the coinbase transaction's block height N on a block explorer and confirm that the block remains in the active chain. The earliest block that can contain a transaction spending its output is N+100. If the current tip is N+99, the coinbase has 100 confirmations, and its output can be spent in the next block. This checks the maturity requirement; the output must also remain unspent and satisfy its other spending conditions.

References

• Bitcoin Developer Guide, Block Chain
• Bitcoin Core, Transaction Input Validation
• Bitcoin Core, Consensus Constants
• ViaBTC Help Center, How Are Profits Calculated?
• ViaBTC Help Center, How to Set Up Auto-Withdrawal
• ViaBTC Help Center, How to Set Min. Payment for Auto Withdrawal?