TWENTY-ONE MILLION ₿

Reproduce Bitcoin's subsidy schedule, one satoshi at a time

This resource calculates a scheduled ceiling under Bitcoin Core v29.0 mainnet rules. It does not measure current issuance, circulating supply, spendable coins or lost Bitcoin. No blockchain download or external service is required.

The result

The complete nonzero schedule sums to 20,999,999.97690000 BTC, or 2,099,999,997,690,000 satoshis, including the scheduled reward at genesis height 0. It falls 2,310,000 satoshis (0.02310000 BTC) short of exactly 21 million BTC because the subsidy is an integer number of satoshis. Fractional satoshis are discarded at halving boundaries, not carried into later blocks.

This small arithmetic difference is not a measurement of lost coins. The calculation also includes the genesis schedule even though the genesis coinbase is unspendable. Subtracting genesis alone would still not produce an observed spendable-supply total.

How the calculation works

  1. Start at 5,000,000,000 satoshis per block (50 BTC).
  2. Divide block height by 210,000, rounding down, to determine the zero-based subsidy era.
  3. Right-shift the initial integer reward by that many bits. For nonnegative integers this is division by a power of two with the remainder discarded. Core explicitly returns zero when the era is at least 64.
  4. Each complete era spans 210,000 heights, including both endpoints. Multiply its subsidy by that count and accumulate the results.

There are 33 eras with a nonzero subsidy. Era 32 covers heights 6,720,000–6,929,999 and allows one satoshi per block. At height 6,930,000 the scheduled subsidy becomes zero. These are heights, not guaranteed calendar dates; no assumed future block timestamps enter this dataset.

Worked boundary example

Height 839,999 allows 625,000,000 subsidy satoshis. Height 840,000 allows 312,500,000. The inclusive scheduled ceiling through height 839,999 is 1,968,750,000,000,000 satoshis; including height 840,000 makes it 1,968,750,312,500,000. The increment is one new block's subsidy, not an entire era's allowance.

Calculate the scheduled ceiling through any height

For an integer height h >= 0, set e = h // 210000 and first_height = e * 210000. Let prior be the sum of era_ceiling_sats for all complete eras before e (zero when e = 0). Use the current era's integer subsidy_sats: 5000000000 >> e for e < 64, otherwise zero. The inclusive ceiling in satoshis is prior + (h - first_height + 1) * subsidy_sats.

The +1 includes the first height of the partial era: at h = first_height there is already one scheduled block, not zero. Count genesis height 0 in this schedule, without treating its coinbase as spendable. The CSV contains only nonzero eras; omitted zero-subsidy eras add nothing to prior.

This remains a scheduled ceiling, not actual issuance or spendable supply; fees are not added.

A halving changes the flow, not halves the stock

A stock is an accumulated quantity at a point in time; a flow is an addition over an interval. Here, the cumulative scheduled ceiling is a stock measured in BTC at a specified height. The subsidy is a flow measured in BTC per block, not BTC per year. Converting it to an annual rate would require an assumption about how many blocks occur in that year.

At the height-840,000 boundary, the subsidy falls from 6.25 to 3.125 BTC per block. But the cumulative scheduled ceiling increases from 19,687,500 BTC through height 839,999 to 19,687,503.125 BTC through height 840,000. The rule changes the allowance for new coins; it does not halve existing balances. These figures follow the pinned subsidy rule and the inclusive-height calculation above, not a measurement of spendable supply.

Check your reasoning: two graphs, two different units

Using the CSV, sketch subsidy against block height on one graph and cumulative scheduled ceiling against block height on another. Label the vertical axes satoshis per block and satoshis, respectively. At a halving boundary, which graph steps downward? Does the other graph fall, stay flat, or keep rising more slowly? Then repeat the question at height 6,930,000.

Answer: the subsidy graph steps downward at a halving; the cumulative graph keeps rising, with a smaller addition per block. At height 6,930,000 the subsidy reaches zero and the cumulative scheduled ceiling stops rising. Plot CSV cumulative totals at each row's last_height, not its first_height; use the partial-era formula above for the boundary itself. A graph of this schedule alone cannot establish a future market price: it contains neither demand nor the quantity holders offer for sale.

Reproduce the CSV without dependencies

Save the following as reproduce_subsidy.py and run python reproduce_subsidy.py > subsidy-eras.csv with Python 3. It reads no files, makes no network requests and writes CSV to standard output. All calculations use integers. In a spreadsheet, import the columns as integers; do not round them to abbreviated millions of BTC.

import csv
import sys

fields = ["era", "first_height", "last_height", "blocks", "subsidy_sats",
          "era_ceiling_sats", "cumulative_ceiling_sats"]
writer = csv.writer(sys.stdout, lineterminator="\n")
writer.writerow(fields)
cumulative = 0
for era in range(64):
    reward = 5_000_000_000 // (2 ** era)
    if reward == 0:
        break
    first = era * 210_000
    total = reward * 210_000
    cumulative += total
    writer.writerow([era, first, first + 209_999, 210_000,
                     reward, total, cumulative])

Download subsidy-eras.csv, summary.json, or the exact Python reproducer. The summary records units, source URLs and exclusions. Downloads contain no visitor tracking.

CSV dictionary

Column Meaning
era Zero-based halving era; only nonzero-subsidy eras are exported.
first_height First included mainnet block height.
last_height Last included height, inclusive.
blocks Number of scheduled heights in the complete era, not observed blocks mined.
subsidy_sats Maximum new subsidy per block, excluding transaction fees.
era_ceiling_sats Complete-era scheduled subsidy in satoshis.
cumulative_ceiling_sats Sum through this era's last height, including the genesis schedule.

What this cannot tell you

Fees transfer existing coins; they are not newly created subsidy. Do not add fees to this issuance ceiling or subtract overlapping loss estimates from it to label the remainder “liquid.”

Why a coinbase can exceed the subsidy without extra issuance

When checking a block explorer, do not compare the entire coinbase transaction's output value with this CSV's subsidy_sats and assume the difference breaks the supply rule. The coinbase transaction is the block's reward transaction, not the exchange of the same name. Core limits its total output value to subsidy plus the block's transaction fees; it does not require the miner to claim that whole allowance.[1]

Worked example, not an observed block: take a block in the 3.125 BTC subsidy era with one ordinary transaction spending 10 BTC of inputs and creating 9.8 BTC of outputs. Its fee is 0.2 BTC, the difference between inputs and outputs.[2] The maximum coinbase output total is therefore 3.325 BTC, not 3.125 BTC.[1]

For this accounting, net addition = coinbase output total − total transaction fees. Do not sum all coinbase outputs and call that newly issued subsidy. Nor does this value calculation establish spendable supply: it does not check output spendability, lost keys or the special treatment of genesis.

Check your reasoning

With the same 3.125 BTC subsidy and 0.2 BTC in fees, would a coinbase output total of 3.4 BTC pass the value-limit check? No: it exceeds the 3.325 BTC allowance by 0.075 BTC. Core rejects a coinbase that pays more than subsidy plus fees.[1] A reward larger than the subsidy alone is not the violation; exceeding the combined allowance is.

Primary sources for this example (pinned for reproducibility, not claimed as the latest release):

  1. Bitcoin Core v29.0 validation.cpp: GetBlockSubsidy, transaction-fee accumulation and the bad-cb-amount upper-bound check.
  2. Bitcoin Core v29.0 tx_verify.cpp: CheckTxInputs calculates fees as input value minus output value.

Primary-source method references

Try it yourself

Use the CSV to answer: Which row first has a one-satoshi subsidy? How many scheduled heights does it cover? Why does the sum stop below 21 million? Then explain why none of these answers establishes how many bitcoins are currently spendable.

Check: era 32; 210,000 heights; integer truncation. Spendability requires different evidence from a subsidy rule.

For a different question, see what evidence can and cannot establish about lost Bitcoin.