The Halving Schedule

Reading the table

Four columns, each doing one job. Era counts which 210,000-block period a reward belongs to. Block height is the exact, unambiguous trigger — the one figure in this whole table that isn't an estimate. Date is either historical record (for eras that already happened) or a projection built from recent average block time (for eras still ahead — see Chapter 4 on why that date can drift). Reward is the block subsidy paid during that era, halving each time.

The current era (5, highlighted) is the one this site's homepage countdown tool is tracking toward era 6. Eras beyond the next couple are shown only to decade-level precision here on purpose — the further out an estimate reaches, the more its calendar date can drift from small, compounding differences in average block time, even though the block height itself never moves.

Only one column in this table is a fact. The rest are arithmetic performed on that fact.

Why the block-height column never changes and the date column does

This is worth dwelling on, because it's easy to skim a table like this and treat every cell as equally solid. Block height 840,000 was always going to be era 5's starting line — that number was fixed the moment Bitcoin launched in 2009, and nothing that happened in between (mining booms, mining bans, exchange collapses, any of it) could move it by a single block. The date "20 Apr 2024" attached to it, by contrast, was a moving target right up until the block actually arrived: earlier in that era, estimates for the halving date shifted by days depending on how fast hash rate happened to be growing that month.

The same is true, right now, of the "est. 17 Apr 2028" row. Block 1,050,000 is exactly 210,000 blocks past 840,000 — that part is arithmetic, not prediction. Whether the calendar lands on that specific April day depends on average block time holding close to 10 minutes for four more years, which Chapter 4 already showed is a target the network continuously corrects toward but never guarantees block-by-block.

What the table doesn't show

Two honest gaps. First, the reward column here is the block subsidy only — the newly created coins. Miners also collect transaction fees on top of the subsidy, and as the subsidy keeps halving, fees are generally expected to make up a larger share of miner revenue over time; this table isn't a forecast of miner income, just the fixed issuance rule. Second, this table numbers eras from 1, while the halving count starts at 0. Era 33 begins after 32 halvings and still allows one satoshi per block, through height 6,929,999. The subsidy first becomes zero at height 6,930,000: era 34, after 33 halvings. That boundary follows integer-satoshi truncation, not a guaranteed calendar date. Chapter 3 covers why satoshis, not bitcoins, are the unit that actually matters; this is the table where that unit choice determines exactly when issuance stops rather than just how it's described.

Reproduce the boundary using Bitcoin Core v29.0 GetBlockSubsidy and its 210,000-block mainnet interval: 5,000,000,000 >> 32 = 1 satoshi; 5,000,000,000 >> 33 = 0. The complete reproducible subsidy schedule and CSV show every nonzero era. These are scheduled subsidy limits, not measured spendable supply.

That fee point isn't hypothetical — it already happened, on the exact block this table highlights as "current era." Block 840,000 itself, mined 20 April 2024, carried the new 3.125 BTC subsidy alongside 37.6256 BTC in transaction fees — fees alone over twelve times the newly issued coins, driven by a surge of Runes-protocol token mints timed deliberately to land on the halving block. The pool that mined it collected more than 40 BTC total from that one block. It didn't last: fees were back to ordinary levels within a day. But for that single block, the subsidy column in this table — the number that gets all the attention — was the smaller part of what the miner actually earned.

The one row that matters today

Everything above era 6 in this table is useful context, not useful planning material — nobody needs to act on a projected date decades out. The table earns its place in this book for one reason: it makes visible, in a single glance, that the arithmetic from Chapter 1 (a geometric series) and the arithmetic from Chapter 4 (blocks-to-years) are the same mechanism viewed from two directions. The series says the supply approaches 21 million. The block count says exactly when each step of that approach happens. Neither chapter needed the other to be true, but put together, they're the whole schedule.

If you'd rather run this arithmetic than read it — every function in this table is implemented, tested, and open source: halving-math on GitHub (MIT licensed, zero dependencies). Don't want to install anything at all? There's also a free, no-key hosted JSON API for the same arithmetic.