Coinbase Maturity
The 100-block waiting period before newly mined Bitcoin can be spent, protecting against chain reorganization losses.
Key Takeaways
- Coinbase maturity is a consensus rule requiring that outputs from a coinbase transaction cannot be spent until 100 additional blocks have been mined on top of the block containing the reward.
- The rule protects the network from chain reorganizations: if a block is orphaned, any transactions that spent its coinbase output would also become invalid, causing cascading failures for everyone downstream.
- Miners and pools must wait approximately 16.7 hours before they can access their block subsidy and collected transaction fees, which affects pool payout models and miner cash flow.
What Is Coinbase Maturity?
Coinbase maturity is a Bitcoin consensus rule that prevents newly created coins from being spent until 100 blocks have been confirmed on top of the block that created them. Every block in Bitcoin contains a special coinbase transaction: the first transaction in the block, which awards the miner the block subsidy (currently 3.125 BTC) plus all transaction fees collected from the block's other transactions. The outputs of this coinbase transaction are considered "immature" until 100 confirmations have passed.
The maturity requirement exists because Bitcoin's blockchain can experience temporary forks. When two miners discover valid blocks at nearly the same time, the network briefly splits. Nodes follow the chain with the most accumulated proof of work, abandoning the competing branch. If a miner had already spent their reward from the abandoned block, those coins would cease to exist, invalidating every subsequent transaction that touched them. The 100-block buffer makes such a deep reorganization effectively impossible under normal conditions.
This rule has been part of Bitcoin since Satoshi Nakamoto's original source code. The constant COINBASE_MATURITY = 100 was defined in version 0.1.0 and has never been changed.
How It Works
When a miner successfully mines a block, the coinbase transaction creates new UTXOs that represent the block reward. These UTXOs enter a special state where they exist on the blockchain but cannot be referenced as inputs in any new transaction. The lifecycle follows a strict sequence:
- A miner finds a valid block and includes a coinbase transaction with outputs paying the reward to their address
- The block is broadcast, validated, and accepted by the network
- The coinbase outputs appear in the miner's wallet as "immature" balance
- For each new block mined on top, the coinbase gains one confirmation
- At 100 confirmations, the outputs become "mature" and spendable
At the target rate of one block every 10 minutes, 100 blocks takes approximately 16 hours and 40 minutes. In practice, the actual time varies due to the stochastic nature of mining, but the difficulty adjustment keeps the average close to this target over longer periods.
Consensus Enforcement
Coinbase maturity is enforced at the consensus level, not merely as a relay policy. Bitcoin Core defines the rule in its consensus code:
// src/consensus/consensus.h
static const int COINBASE_MATURITY = 100;
// src/consensus/tx_verify.cpp
if (coin.IsCoinBase() &&
nSpendHeight - coin.nHeight < COINBASE_MATURITY) {
return state.Invalid(
TxValidationResult::TX_PREMATURE_SPEND,
"bad-txns-premature-spend-of-coinbase"
);
}If a transaction attempts to spend an immature coinbase output, it is rejected at two levels. First, the mempool refuses to accept it, returning the error bad-txns-premature-spend-of-coinbase. The transaction is never relayed to other nodes. Second, if a miner somehow included such a transaction in a block, every validating node on the network would reject that entire block as invalid.
The maturity check applies to all outputs of the coinbase transaction equally. There is no distinction between satoshis that originated from the block subsidy and those collected as transaction fees: the entire coinbase transaction is locked for 100 blocks.
Wallet-Level Display
Bitcoin Core's wallet adds an extra 20-block buffer for display purposes. The internal GetBlocksToMaturity() function returns the maximum of zero and (COINBASE_MATURITY + 20) - depth, meaning the wallet shows a coinbase as immature until 120 confirmations. This does not change the consensus rule: spending is permitted at 100 confirmations, but the wallet provides additional visual safety margin.
Why It Matters
Chain reorganizations are a natural part of Bitcoin's consensus process. Short reorgs of one or two blocks happen regularly when miners find blocks nearly simultaneously. Deeper reorgs are rarer but not impossible: the longest known Bitcoin reorg occurred during the March 2013 chain split (documented in BIP-50) and extended approximately 24 blocks due to a database compatibility issue between Bitcoin Core versions.
Without coinbase maturity, a reorganization would not only affect the miner who lost their block: it would cascade. Consider a scenario where a miner receives their reward, immediately spends it at an exchange, and the exchange credits the deposit to a trader who then withdraws. If the miner's block is later orphaned, the original coinbase output ceases to exist. The miner's spend becomes invalid, the exchange loses the deposit, and the trader's withdrawal creates a hole in the exchange's balance sheet. Every transaction that touched those coins unravels.
The 100-block maturity rule isolates this risk. By the time a coinbase output can be spent, the probability of a reorg reaching that depth is negligible. This provides a form of finality for newly minted coins, preventing contamination of the broader transaction graph.
Mining Pool Implications
For solo miners, coinbase maturity means waiting roughly 16.7 hours after finding a block before accessing any of the reward. For mining pools, which produce blocks far more frequently, the maturity rule shapes their entire payout infrastructure.
Pools display mined blocks in three stages on their dashboards:
- Immature: the block has been found but has fewer than 100 confirmations. The reward is visible but locked and cannot be distributed
- Confirmed: the block has 100+ confirmations. The pool can now spend the coinbase outputs and distribute rewards
- Paid: the pool has sent payouts to participating miners
Payout Models
Different pool payout models handle the maturity delay in distinct ways:
| Model | How Maturity Affects Payouts |
|---|---|
| FPPS (Full Pay Per Share) | Pools pay miners a predictable amount per share, including estimated fees. Large pools front the payment from reserves before the coinbase matures, absorbing the delay risk. |
| PPS (Pay Per Share) | Similar to FPPS but covers only the block subsidy portion. The pool absorbs maturity delay and variance risk. |
| PPLNS (Pay Per Last N Shares) | Miners are paid only when the pool finds blocks. The maturity delay stacks on top of the already-variable payout timing. |
Large pools with significant reserves effectively make the maturity delay invisible to their miners by paying from their own working capital and recouping when the coinbase matures. Smaller pools may pass the delay directly to miners. For a deeper look at how mining economics work, see Bitcoin Mining Economics in 2026.
Coinbase Maturity vs. Exchange Confirmations
It is common to confuse coinbase maturity with exchange deposit confirmation requirements, but they serve different purposes and operate at different scales:
| Requirement | Confirmations | Approximate Wait | Purpose |
|---|---|---|---|
| Coinbase maturity | 100 blocks | ~16.7 hours | Prevent spending coins that may cease to exist after a reorg |
| Typical exchange deposit | 3 to 6 blocks | 30 to 60 minutes | Protect against double-spend attacks on regular transactions |
Exchange confirmations protect against a sender attempting to reverse a regular transaction through a double-spend attack. The risk here is that the attacker re-mines a competing chain that excludes their deposit transaction. A few confirmations make this economically infeasible for most transaction sizes.
Coinbase maturity protects against something more fundamental: the complete disappearance of the coins themselves. If a coinbase's block is orphaned, the coins were never created in the consensus history. This requires a much higher confirmation threshold because the consequences are more severe and harder to detect downstream. For a broader discussion of confirmation security, see Zero-Conf Bitcoin Explained.
Use Cases
Coinbase maturity is not a feature that applications explicitly implement: it is a background consensus rule that affects specific workflows.
- Mining pool infrastructure: pools must track immature balances separately from spendable balances and manage payout queues that respect the maturity window
- Block explorer displays: explorers show coinbase outputs as unspendable until 100 confirmations, often with countdown indicators for miners tracking their rewards
- Wallet software: wallets that receive coinbase outputs directly (solo miners or pool operators) must distinguish between immature and mature balances to prevent users from attempting transactions that would be rejected by the network
- Exchange deposit policies: some exchanges require additional confirmations or flag deposits that originate from recently matured coinbase outputs, as these transactions have a shorter spending history
- UTXO analysis: chain analysis tools track coinbase maturity as part of UTXO lifecycle analysis, since coinbase outputs represent the only mechanism for creating new bitcoin
Risks and Considerations
Revenue Delay for Miners
The 16.7-hour maturity window creates a cash flow gap for miners, who incur real-time costs for electricity and hardware but cannot access revenue immediately. Solo miners feel this most acutely: finding a block is already rare, and the maturity delay adds further waiting before the reward becomes liquid. For large-scale mining operations, the aggregate immature balance across recently found blocks can represent significant locked capital.
Orphan Block Risk
If a block is orphaned before reaching maturity, the miner loses the entire reward: both the block subsidy and all collected transaction fees. The work spent mining that block is wasted. While short reorgs of one or two blocks are relatively common, the maturity rule means that only very deep (and correspondingly rare) reorgs affect spendable coins. The risk is real but small under normal network operation.
The 100-Block Constant
Some have questioned whether 100 blocks is the right number. It is arguably conservative: the longest known reorg in Bitcoin's history was roughly 24 blocks during the March 2013 incident (BIP-50), far shorter than 100. A lower maturity period would let miners access rewards faster. However, changing this constant would require a consensus-level hard fork, affecting every node on the network. The conservative choice provides a significant safety margin against both natural reorgs and potential adversarial scenarios, and no serious proposal to change the value has gained traction.
Impact on Bitcoin's Supply Schedule
Coinbase maturity introduces a subtle effect on Bitcoin's effective circulating supply. At any given moment, the most recently mined 100 blocks worth of rewards are locked and unspendable. At the current subsidy of 3.125 BTC per block, approximately 312.5 BTC is perpetually immature and unable to participate in the economy. While negligible relative to the total supply, this represents a small but constant buffer between mined supply and spendable supply. The Bitcoin fee market also plays a role here, as transaction fee revenue locked in immature coinbase outputs grows in significance as the block subsidy continues to halve.
This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.