Audit Bitcoin Issuance With a Height-Based Supply Ledger

Bitcoin issuance can be checked rather than accepted from a dashboard. Start with block height, apply the subsidy allowed in each era, and compare that maximum with the coinbase transactions in accepted blocks. This ledger explains new supply while keeping transaction fees, lost keys, and spendable balances in their proper categories.

Define the quantity you want to audit

The overview of how Bitcoin units enter circulation explains that mining distributes new BTC under protocol rules rather than through a central issuer. An audit should turn that statement into measurable fields.

Issued supply is the subsidy actually claimed in accepted blocks. The theoretical maximum is what miners could have claimed under the schedule. Spendable supply is smaller when outputs are destroyed, inaccessible, or otherwise unavailable. Market supply estimates may apply still more assumptions.

Write the definition beside every total. Two sites can show different numbers because one counts theoretical issuance while another estimates liquid or circulating coins.

Use block height instead of a calendar estimate

Bitcoin began with a subsidy of 50 BTC per block. The permitted amount halves every 210,000 blocks. This creates successive eras of 50, 25, 12.5, 6.25, and 3.125 BTC, followed by smaller amounts in future eras.

A halving happens when the relevant height is reached, not when a scheduled date arrives. Average block intervals make future dates useful forecasts, but a supply calculation should use actual heights.

For a simple maximum, count the blocks in each completed era, multiply by that era's subsidy, and add the partial current era. Use the smallest protocol unit, the satoshi, to avoid floating-point rounding errors.

Read the consensus calculation

The Bitcoin developer block-chain documentation describes the coinbase transaction and block reward. The implementation determines the allowed subsidy from height and rejects a block whose coinbase outputs exceed subsidy plus collected fees.

Researchers who need exact behavior should inspect the maintained Bitcoin Core validation source and the referenced subsidy function for the software version being studied. Record the commit or release so another person can repeat the result.

Consensus arithmetic matters near the far end of the schedule. Repeated integer division eventually reduces the subsidy to zero; it does not continue as infinitely divisible fractions.

Separate subsidy from transaction fees

A block producer may claim the permitted subsidy and the fees paid by transactions included in that block. A block explorer often combines them under “reward,” but only one component increases issued supply.

Calculate fees by comparing the value of ordinary transaction inputs with their outputs, using validated transaction data. Do not add those fees to the monetary issuance column because the satoshis already existed before the block.

Pool payouts create another accounting layer. A pool can distribute previous earnings to participants through later transactions. Those payments move existing BTC and should never be counted as new coins merely because recipients call them mining revenue.

Account for rewards below the maximum

The rule places a ceiling on the coinbase amount; it does not force miners to claim every permitted satoshi. Historical blocks can contain underclaimed rewards. Therefore, summing the schedule gives a maximum, while reading every accepted coinbase gives actual issuance.

An overclaim makes the block invalid. An underclaim permanently leaves the difference unissued. The network does not add the missed amount to a later block.

Keep provably unspendable outputs and suspected lost keys separate from underclaims. An unspendable coin may have been validly issued first, whereas an omitted subsidy never entered the ledger.

Choose the accepted chain and snapshot

A block observed briefly can lose the chain-selection competition. Its coinbase output then does not belong to the eventual accepted history. Build the audit from the best chain recognized by the validating node at a stated snapshot height and block hash.

Coinbase outputs also require maturity before spending. Maturity delays use of a recent reward, but it does not change the permitted issuance calculation for a block that remains accepted.

Save the network name. Mainnet, test networks, and private regtest chains follow different histories and must not be mixed in one supply table.

Build a reproducible audit table

Create columns for height, block hash, era, allowed subsidy, claimed subsidy, transaction fees, coinbase output total, chain status, and maturity status. Add source-node version and observation time to the file metadata.

Check three boundaries carefully: the genesis block, every halving transition, and the current tip. Randomly sample ordinary heights, then reconcile the sum against an independently implemented script or node query.

If totals differ, test for off-by-one handling at era boundaries, fee inclusion, decimal rounding, stale blocks, missing data, and network selection before assuming a monetary-rule failure.

Interpret the result precisely

The audit demonstrates how much BTC the accepted ledger issued under the observed rules and data. It cannot reveal how many private keys are lost, how coins are divided among beneficial owners, or how much supply is offered for sale.

A reproducible supply statement should name the snapshot block, method, software version, and category being reported. This turns “miners make bitcoins” into a verifiable claim: accepted blocks can contain no more new value than their height permits, and each full node can enforce that ceiling independently.