Coinbase is a consensus transaction type, not Coinbase the company and not a normal payment. Its null outpoint, BIP34 height, reward ceiling, position at index zero, maturity and—when applicable—SegWit witness commitment are validated with the block. It is never accepted into the mempool on its own.
A block must contain at least one transaction, and only its first transaction may be coinbase. Bitcoin Core recognizes it structurally: exactly one input whose previous-output hash is 32 zero bytes and whose output index is 0xffffffff. That input does not unlock an existing UTXO, so it carries no ordinary signature or prevout value. The transaction can have several outputs, normal version and locktime fields, and a txid like any other transaction; the special input and block position give it its role. [Bitcoin Developer Reference — Coinbase input] [Bitcoin Developer Reference — Block chain] [Bitcoin Core — transaction.h (IsCoinBase)]
The miner may set total coinbase outputs no higher than GetBlockSubsidy(block height) plus the fees of all other valid transactions in that block. Only the subsidy creates new satoshis; fees transfer already existing satoshis from transaction inputs. A miner may deliberately claim less, making the omitted value permanently unspendable, but any overclaim makes the entire block invalid. The protocol does not require a fixed split between a pool, miners, a treasury or several payout scripts. [Bitcoin Core — validation.cpp] [Bitcoin Core — miner.cpp]
Since BIP34, the coinbase scriptSig must begin with the current block height encoded as a minimally encoded CScript number. The complete scriptSig is constrained to 2–100 bytes. Space after the height may hold an extra nonce, mining-pool tag, merged-mining commitment or other pushed data, but it is not a free consensus bypass: a wrong height or invalid length rejects the block, and embedded signature-check opcodes can count toward the block's sigop limit even though this input does not execute as an ordinary spending script. [Bitcoin Developer Reference — Coinbase input] [BIP 34 — Block height in coinbase]
ASICs vary the block-header nonce, but that 32-bit field is quickly exhausted. Mining software therefore changes an extra nonce in the coinbase scriptSig or another permitted coinbase field. This changes the coinbase txid, the transaction Merkle root and consequently the block header, opening a fresh header search space. In pooled mining, job protocols divide this variable space among workers so their candidate shares do not collide; the extra nonce is mining coordination data, not additional monetary issuance. [Bitcoin Core — miner.cpp] [BIP 22 — getblocktemplate] [Stratum V2 — Mining Protocol specification]
Coinbase outputs use ordinary locking scripts and may be split across multiple addresses or policies. A pool can pay one aggregation address, divide revenue immediately, reserve an output for an operator or use a transparent payout construction. None of those labels is inferred by consensus: nodes verify scripts and amounts, not the pool's contracts or beneficial owners. Pool dashboards, payout thresholds, FPPS/PPS/PPLNS accounting and later withdrawals are off-chain business rules distinct from the on-chain coinbase transaction. [Bitcoin Core — miner.cpp] [BIP 22 — getblocktemplate]
For a block containing witness transactions, BIP141 requires a witness commitment in a coinbase output: an OP_RETURN script beginning 6a24aa21a9ed followed by a 32-byte commitment. The coinbase input's witness must contain one 32-byte reserved value used in that commitment. Multiple matching outputs are possible, but consensus selects the one with the highest output index. This commits the block to the witness Merkle root while leaving the legacy block header committed through the coinbase txid; it is not a miner payout. [BIP 141 — Segregated Witness commitment]
A coinbase output is marked coinbase in the UTXO set and cannot be spent until the spending block's height minus the creating block's height is at least COINBASE_MATURITY, currently 100. Thus a reward created at height H may first be spent in a valid block at H+100; wallet wording in confirmations can look off by one because the creating block itself is confirmation one. Maturity is a consensus rule for the created outputs, not a promise that a block cannot later be reorganized. [Bitcoin Core — consensus.h (COINBASE_MATURITY)]
If a mined block leaves the active most-work chain, its coinbase outputs disappear from the active UTXO set. Any descendant transaction that spent a now-mature reward can also become invalid or return to a state that depends on the replacement chain. The 100-block delay limits short-reorganization damage and prevents newly created rewards from immediately propagating through long spend chains, but it is not finality. Miners and pools must track active-chain status, maturity and payout liabilities separately. [Bitcoin Core — validation.cpp] [Bitcoin Core — consensus.h (COINBASE_MATURITY)]
During block validation, full nodes require one coinbase at position zero, reject any additional coinbase transaction, check its scriptSig length and BIP34 height, calculate fees from the block's non-coinbase transactions, and reject a reward above subsidy plus fees. They also validate output value ranges, transaction weight, witness commitment and later maturity of spends. A standalone coinbase has no meaningful relay path: without a candidate block height and reward context it is not a valid mempool transaction. [Bitcoin Core — transaction.h (IsCoinBase)] [Bitcoin Core — validation.cpp] [BIP 141 — Segregated Witness commitment]
Early blocks could produce duplicate coinbase txids because miners were not yet required to encode height; BIP30 prevents overwriting unspent outputs of an earlier transaction, and BIP34 made modern coinbases height-distinct in normal construction. The genesis block is a historical special case: its coinbase transaction is present in the serialized block, but its output was never inserted into the spendable UTXO database by Bitcoin's initialization path. That is why the famous 50 BTC genesis output cannot be spent, not because every coinbase is permanently locked. [BIP 30 — Duplicate transactions] [BIP 34 — Block height in coinbase] [Bitcoin Core — chainparams.cpp (genesis construction)]
For the clearest picture, read this entry together with Block, Block Subsidy, Transaction fees, Mining, Block Template, Bitcoin. The reverse links also lead from Block Subsidy, Confirmation, Nonce.