A freshly mined Litecoin reward can be visible in a wallet without being available to spend. Coinbase maturity is a consensus restriction on newly created mining outputs. It is different from an exchange's deposit-confirmation requirement, a pool's payout threshold and the wallet's own available-balance calculation.
This guide checks Litecoin Core 0.21.5.8 source and uses synthetic heights to show the boundary. It does not mine a new block, spend a live reward or promise an exact waiting time. Here “coinbase” means the block's special reward transaction, not the company with that name.
A block reward creates a special kind of output
The coinbase is the first transaction in a conventional block and has a special input rather than consuming an ordinary previous output. Its permitted value is bounded by subsidy plus applicable transaction fees. A miner can create more than one reward output, but splitting the value does not remove their coinbase origin.
The transaction definitions distinguish this form, and block validation limits the reward. The maturity restriction covers coinbase outputs, including value derived from transaction fees; it is not limited to the newly issued subsidy component.
Contrast this with a normal wallet payment. An ordinary output is governed by its own spending conditions and wallet policy. It does not acquire a 100-block coinbase restriction merely because its sender is a miner or a pool.
The consensus check is a height difference
In the pinned version, COINBASE_MATURITY is 100. The input validator rejects a coinbase spend when:
candidate spend height − reward creation height < 100For a reward created at hypothetical height H, the earliest candidate block satisfying this particular check is H+100. This is a statement about the spend's block height. Other checks, including signatures, unspent status, locks and transaction policy, still have to pass.
Confirmation depth answers a different question. If the reward block is in the active chain, depth equals current tip minus creation height plus one. The creation block itself therefore counts as confirmation one. Mixing “100 subsequent blocks” with “100 confirmations” without stating the starting point creates an off-by-one error.
Why Core's wallet can still show one block remaining
The pinned wallet's GetBlocksToMaturity implementation calculates coinbase blocks remaining as max(0, 101 − current depth). Its available-balance handling can therefore be more conservative than the earliest next-block consensus boundary.
| Current tip and reward depth | Next candidate block | Age check / Core wallet blocks remaining |
|---|---|---|
| 3,000,098; depth 99 | 3,000,099; age 99 | Not eligible / 2 remaining |
| 3,000,099; depth 100 | 3,000,100; age 100 | Eligible / 1 remaining |
| 3,000,100; depth 101 | 3,000,101; age 101 | Eligible / 0 remaining |
Thus “the constant is 100” and “Core's wallet becomes mature at depth 101” can both be correct descriptions of different code paths. This guide is not advice to bypass the wallet's checks or manually force a boundary spend. Diagnose the actual transaction type and software version first.
The boundary CSV preserves seven synthetic tip states, and the offline script reproduces these conditions. It encodes source rules; it is not a fresh node experiment or validation of an actual transaction.
Pool credit is not necessarily a coinbase output
A pool can credit work in its own accounting before paying your wallet. The balance displayed on the account is a claim under the operator's rules, not a UTXO you can directly spend. Its settlement policy can include thresholds, schedules, holds or block-maturity conditions.
When the pool sends a normal payout transaction from its funds, the resulting output is an ordinary receipt. It does not inherit the origin restrictions of every earlier reward the pool earned. If a mining arrangement instead pays your destination directly in a coinbase, that specific output does have coinbase maturity.
Inspect the actual transaction type instead of inferring it from a familiar sender label. The pool accounting guide separates credits, payout debits, wallet receipts and unpaid balances. It also explains why PPS accounting is not an unconditional payment guarantee.
MWEB peg-outs have a separate maturity rule
The same pinned consensus constants set PEGOUT_MATURITY to six. Input validation applies a separate height-difference check to an output identified as a peg-out. Do not apply the coinbase's 100-block constant to every MWEB exit, or apply six as a universal confirmation policy for ordinary LTC receipts.
The wallet's corresponding HogEx path uses max(0, 6 − depth), while its coinbase path uses 101 minus depth. These formulas are deliberately shown separately. A transparent transaction containing or associated with MWEB activity needs correct classification before a balance or waiting-period explanation is useful.
For route support and confidentiality, see the privacy guide and address-format guide. Maturity concerns spend availability; it does not, by itself, describe privacy or a custodian's crediting decision.
Inspect the state without creating another payment
Start with your own wallet and node's current chain state. These read-only examples inspect help and transaction information; replace placeholders only with the transaction you intend to inspect:
litecoin-cli help gettransaction
litecoin-cli gettransaction "<wallet-transaction-id>"
litecoin-cli gettxout "<transaction-id>" 0 true
litecoin-cli getbalancesgettransaction concerns transactions known to the selected wallet. gettxout checks an output against the node's view and can expose whether it is coinbase; the output index must be the actual one, not always zero. A null result can mean it is spent or unavailable in that view. It is not a universal statement that the payment never existed.
Check node synchronization, active-chain block hash, inclusion height, confirmations, output type and wallet categories. The blockchain RPC implementation and wallet RPC implementation define the relevant fields. If the issue is an ordinary balance that cannot fund a send, use the wallet-balance diagnosis as well.
A block count is not an exact wall-clock timer
At a hypothetical constant target rate of one block per 150 seconds, 100 future blocks have a mean arrival time of 250 minutes, or four hours ten minutes. Actual arrivals vary. A display estimating time remaining is not a scheduled unlock appointment.
A reorganization can change depth, remove a reward from the active chain or invalidate a dependent spend. Maturity is one protection around reward spendability; it does not guarantee that an output survives every reorganization. The block-interval guide explains why mean waits and irreversible finality must remain separate.
Retain the transaction ID, output index, current block reference, software version and observation time when asking for help. Do not supply a seed, private key or full wallet backup. A support record needs evidence of state, not signing authority.
Frequently asked questions
Is coinbase maturity a rule from the Coinbase exchange?
No. Coinbase here means the special block-reward transaction. The maturity rule belongs to Litecoin validation.
Is the consensus constant 100 or 101?
The pinned constant is 100, applied to spend height minus creation height. Core's wallet separately calculates coinbase blocks remaining as max(0, 101 minus depth).
Do mining fees in a reward mature immediately?
No. Outputs of the coinbase transaction are subject to coinbase maturity, including reward value derived from transaction fees.
Does every pool payout need another 100 blocks?
No. A normal pool payout is an ordinary transaction. A destination paid directly in a coinbase has different restrictions. Inspect the actual output's origin.
Are MWEB peg-outs governed by the same constant?
No. Core 0.21.5.8 defines a separate six-block peg-out maturity rule. Wallet handling and service credit policies must also be distinguished.
Will my reward unlock exactly four hours ten minutes later?
No. That is a mean for 100 future blocks at a declared 150-second rate. Block arrivals, chain state and wallet policy determine actual availability.
