Two ways to check a number
Every monetary system publishes a supply figure of some kind. The difference that matters isn't whether the number exists — it's whether you can independently reproduce it, or whether you're stuck trusting whoever published it. Central banks report the money supply (M0, M1, M2 — progressively broader measures of currency and bank deposits) on a periodic schedule, compiled from data that ordinary people cannot access or recompute themselves. When the Federal Reserve reports M2, you're trusting their data collection, their methodology, and their honesty — not because they're likely lying, but because the underlying ledger genuinely isn't open for you to check.
Bitcoin's supply figure works the other way around. The entire issuance history — every coin, from the first block in 2009 to the block mined an hour ago — is recorded on a ledger anyone can download and independently recompute from scratch. Nobody has to take Bitcoin's word for how many coins exist. They can count.
The rule every node enforces, not just observes
"Counting" undersells what actually happens. A Bitcoin full node doesn't just read a total off the chain and trust it — it independently re-derives every block's legitimacy from the protocol's rules, including one rule in particular: a block's coinbase transaction (the one that pays the miner) is not allowed to create more than that era's fixed subsidy, the exact figure tracked era by era in Chapter 5's table. A miner is free to claim less than the allowed subsidy — plenty of early blocks did, by accident or design — but a block that claims more is invalid, full stop, rejected by every honest node on the network regardless of how much hashing power produced it.
This is the detail that turns "21 million" from a design intention into an enforced fact. It isn't that miners have agreed, as a courtesy, to follow the schedule. It's that a block violating the schedule doesn't propagate as a valid block at all — the software refuses it, the same way it would refuse a block that tried to spend coins twice. Chapter 5 was one column short of a claim this chapter can now make in full: the reward schedule isn't just what's supposed to happen, it's what full nodes make happen, by rejecting anything else.
This isn't a purely hypothetical mechanism — it was tested once, for real, early on. On August 15, 2010, a bug later cataloged as CVE-2010-5139 let a single transaction in block 74,638 create 184,467,440,737.09551616 BTC out of thin air for two addresses. It was a different flaw than the coinbase check diagrammed above — an integer overflow in how transaction output amounts were summed, not a subsidy violation — but the same category of threat: more coins than the rules permit. What happened next is the part that matters for this chapter's claim. A patched client shipped within about five hours, honest nodes adopted it, and the corrected chain overtook the tainted one by block 74,691 — orphaning the invalid transaction for good. No coins were permanently created and no user lost funds. The 21-million schedule held not because anyone asked nicely, but because enough independently operated nodes simply refused to build on a chain that broke it.
Counting the supply by hand
Because every era's reward and block range are fixed and public, the running total issued at any block height is pure arithmetic — no live feed required, and nothing here depends on today's date. Take the checkpoint at block 840,000, the start of era 5 (20 Apr 2024), using the reward figures from Chapter 5's table:
That figure — 19,687,500 BTC issued in the first four eras — is a real, published number that matches public record at the 2024 halving, not a rounded estimate. To extend it to today, the same method just keeps going: add (blocks completed in era 5) × 3.125 BTC. Any block explorer will tell you the current block height for free; from there, the rest is the four lines above plus one more.
Pick any block explorer, note the current height, plug it into that line, and compare the result against the explorer's own "total supply" figure. They should match — because both numbers come from the same enforced rule, not from two different sources that happen to agree.
The same arithmetic, as tested code rather than a formula on a page, is in halving-math (introduced in Chapter 5) — its totalIssuedByBlock(height) function is exactly the calculation above, runnable instead of just readable.
Nobody has to believe Bitcoin's supply is honest. They can check it — and so can the next person, and the next, forever, using nothing but public data and arithmetic anyone can run themselves.
What auditability doesn't prove
This chapter's claim is narrower than it might sound, and worth stating precisely rather than oversold. Auditability proves that the issuance rule is enforced — that no more than the scheduled number of coins can ever be created. It does not prove anything about price, about how many coins are actually in active circulation versus lost forever (a later chapter covers exactly that gap), and it does not, by itself, prove decentralization — a network where one party controlled every node could still "enforce" any rule it liked, honestly or otherwise. What makes the enforcement meaningful is that thousands of independently operated nodes run this same check with no coordination required, and a would-be cheater has to convince all of them at once, not just one.
It's also not a claim that the schedule is somehow immune to change. Bitcoin's rules are software, and software can theoretically be changed by consensus among the people running nodes — Chapter 1 already covers why that's a coordination problem approaching impossible in practice, not a mathematical impossibility. What this chapter adds is the mechanism for the half of that claim Chapter 1 took as given: the reason changing the schedule is hard isn't that anyone declared it off-limits, it's that every node is actively, continuously checking for exactly that kind of change and rejecting it on sight.