Read the halving from block height and explicit assumptions

1. Start with chain height and the right clock

Actual mode takes the Bitcoin mainnet tip height from the existing mempool.space network connection. Height identifies a zero-based block index; it is not a count of all blocks. The displayed source and capture time belong to that response. Other network and sentiment responses have separate clocks and are not substituted into the halving calculation.

The height endpoint supplies neither the timestamp nor the hash of that block. Reading the response therefore does not establish when the block was mined. Using capture time as an estimation anchor or entering another anchor is an explicit scenario assumption.

2. Distinguish the current block from the first block of an era

The schedule uses Bitcoin mainnet parameters: a 210,000-block interval and an initial 50 BTC subsidy. Integer division of height by the interval identifies the era. The block immediately before a boundary uses the previous subsidy; the block exactly at the boundary already uses the new one. Distance to the next boundary is measured from the input height; no future block is treated as confirmed now.

The calculation uses integer satoshis with integer halving rather than rounded decimal BTC. Fractional satoshis are discarded in later eras until the subsidy reaches a known zero. The table also includes this terminal zero era. Zero subsidy is a specific rule-based result; an unknown source height remains a different state. The method links to the pinned Bitcoin Core v30.0 implementation.

3. Apply timing assumptions as a scenario

For a timing outlook, choose a starting height, time anchor and assumed seconds per block. Faster and slower assumptions form a range from the supplied inputs. The range is neither a confidence interval, a probability nor a promised date. Actual future block timing may differ; an assumed average does not establish the time of any particular future block.

Form edits begin as a draft. Only deliberately applying valid inputs recalculates the result. Until then, chart, table, selected era and export retain the previous applied query. Invalid input does not overwrite the valid result. Refreshing network height is separate and may return the same captured input from shared cache.

4. Connect chart, table and detail without inventing history

Chart and table describe the same subsidy rules by block era. Select an era to inspect its starting and ending height, subsidy per block and theoretical issuance. Unknown actual historical times are not filled by reverse estimation. A future boundary date follows only from the applied anchor and timing scenario rather than a confirmed block that does not yet exist.

Theoretical scheduled issuance does not measure circulating or spendable supply. It totals rule-permitted subsidy rather than establishing what miners actually claimed, which coins were lost or what can be spent today. Genesis has a special spendability restriction and a theoretical total must not automatically become an available balance. Transaction fees are not new issuance and this calculation does not include them in block subsidy.

5. Export the complete applied result with provenance

Complete JSON and CSV belong to the same applied query and manifest as the chart, table and detail. They retain the era schedule, exact integer values, timing assumptions and source context. Selecting one era in detail does not change the scope of a labelled complete export. When the form has changed, apply the new inputs first if you want to export their result.