Bitcoin's Supply Schedule: Subsidy, Halving and the 21 Million Limit

Two constants and a shift

The entire issuance schedule fits in a dozen lines. Bitcoin Core’s GetBlockSubsidy takes a block height and the consensus parameters, divides the height by the halving interval to get a count of halvings, and shifts a starting value of 50 BTC right by that count. A right shift by one is a division by two, so each halving halves the subsidy.

The current source reads:

CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
    int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
    // Force block reward to zero when right shift is undefined.
    if (halvings >= 64)
        return 0;

    CAmount nSubsidy = 50 * COIN;
    // Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
    nSubsidy >>= halvings;
    return nSubsidy;
}

chainparams.cpp sets consensus.nSubsidyHalvingInterval = 210000 for mainnet. The comment in the function says the cut occurs approximately every four years, and the word “approximately” is doing real work: 210,000 blocks at a ten-minute target is about 1,458 days, but block intervals vary, so the calendar date of a halving is an estimate while the height is exact.

Reading the schedule

Combining the two constants gives a table that can be computed rather than looked up:

Each row is the previous subsidy divided by two, and each range is 210,000 blocks wide. The arithmetic is the whole policy. No vote changes a row, and no parameter adjusts the curve between halvings.

The 21 million limit is a sum, not a constant

The frequently quoted cap does not appear in the source as a number. It falls out of the table. The subsidy per halving is 50 BTC, then 25, then 12.5, and so on, each paid for 210,000 blocks. The total is a geometric series:

50 + 25 + 12.5 + … = 100 BTC per block-equivalent 100 × 210,000 blocks = 21,000,000 BTC

That is where the figure comes from. It is the sum of an infinite series that the code truncates, which is why the actual total is a fraction below 21,000,000 rather than exactly at it. The difference is the final subsidy that integer division rounds down to zero, a few thousandths of a bitcoin in total.

The practical consequence is that the cap is enforced by the subsidy function rather than by a separate check. A block’s coinbase output cannot exceed the subsidy plus the fees of the transactions it contains; ConnectBlock compares the coinbase value against nFees + GetBlockSubsidy(...) and rejects the block if it pays more. The cap holds because every block’s issuance is computed from the same function.

Where the chain is now

On 2026-10-26, the mempool.space tip-height endpoint returned 973,154. Dividing by 210,000 gives 4 with a remainder, so the chain is in the fifth epoch — the one that began at height 840,000 — and the subsidy is 50 BTC shifted right four times, or 3.125 BTC.

Two numbers follow from that height:

The blocks-remaining figure is exact; the date it corresponds to is not. At a ten-minute average that is roughly 534 days, but the network has produced blocks faster and slower than the target for long stretches, so the calendar estimate moves while the height does not.

What the subsidy is and is not

The subsidy is new issuance. It is paid to the miner of a block through the coinbase transaction, and it is the only way new bitcoin enters circulation. Fees are separate: they are existing bitcoin transferred from spenders to the miner, and they do not change the supply.

Three things the subsidy is not:

• It is not a price floor. The schedule fixes how much new supply is issued, not what anyone pays for it. A halving reduces the flow of new coins; it says nothing about demand.
• It is not a difficulty adjustment. Difficulty retargets every 2,016 blocks to keep the block interval near ten minutes. The subsidy schedule is independent of it, which is why the halving height is fixed while the date is not.
• It is not a promise about miner revenue. Miner revenue is subsidy plus fees. As the subsidy halves, the fee share of that revenue grows, and the security budget becomes a question about fees rather than about issuance.

The end of the schedule

The shift is integer division, so the subsidy does not decay smoothly to a tiny positive number. It truncates. At the 32nd halving the reward is 1 satoshi per block; at the 33rd it is zero, because 5,000,000,000 satoshis shifted right 33 places is 0.58 of a satoshi, which the integer type cannot represent.

The guard in the function checks for 64 or more halvings, not 33. That is a different concern: shifting a 64-bit value by 64 or more places is undefined behavior in C++, so the function returns zero before the shift can be performed out of range. The economic end of issuance arrives at 33; the guard exists to keep the operation well defined.

After that, blocks are paid by fees alone. The schedule does not say whether that is enough to secure the chain — that is a question about demand for block space, not about the subsidy function.

Why the dates drift and the heights do not

A halving is triggered by a block height, so it happens when the 210,000th block of an epoch is mined, whatever the calendar says. The ten-minute target is maintained by the difficulty adjustment, which itself only responds every 2,016 blocks, and hash rate changes between adjustments push the actual interval above or below the target.

That is why announcements frame halvings as estimates until the height is reached. The height is the fact the protocol enforces; the date is a projection made from recent block times. Reading the schedule in heights, as the table above does, avoids the ambiguity entirely.

Risk note. The subsidy function, the halving interval and the block-reward check in this article were read from the Bitcoin Core source on 2026-10-26. The tip height was a live snapshot from mempool.space on the same date and will be stale immediately. Derived totals are arithmetic on the source constants, not quotations from a document. Nothing here is investment advice.