If you've studied Bitcoin for more than a few minutes then you're probably aware that the money supply is predictable and will never exceed 21 million bitcoin. Pedantically, the limit is 2,099,999,997,690,000 satoshis given that all accounting at the protocol level is calculated in the smallest unit.
But how is this limit defined and what prevents it from being broken?
A newbie might try to find this limit mentioned in the whitepaper... but it's not there (nor are many other aspects of the protocol!)
Did you try to find the limit defined in the Bitcoin Core implementation? If you search for "21000000" on the github repository then you'll find this MAX_MONEY constant defined, but that's not it either!
So... where is the cap enforced? It's not as straightforward as you might think.
Implicit Rather than Explicit Limits
Rather than thinking of the total number of bitcoins issued as a "point in time" check, you should view it as a geometric series that sets a moving upper limit. After all, we don't actually care about ~exactly~ how many bitcoins exist - we only care that there are fewer than the expected amount. The series that describes our desired upper bound can be described by the following equation:
This is like saying...
50 * 210000
+ 25 * 210000
+ 12.5 * 210000
+ 0.00000002 * 210000
+ 0.00000001 * 210000
Bitcoin implementations control new issuance by checking that each new block does not create more than the allowed block subsidy. This line of code is specifically summing up the total output value of the block's coinbase transaction - the first transaction in a block - which is the only transaction allowed to mint new coins.
You may note that this is also taking the transaction fees from the block into account. Why? Because those fees are not newly issued bitcoin - they already existed and were paid to the miner by people who made transactions. It would be similarly correct to check that the coinbase transaction's output value minus the block's transaction fees is less than or equal to the allowed block subsidy.
How is the bitcoin issuance curve defined in the protocol? It's a mere 5 lines of code, 2 of which are to cover an extreme edge case that won't trigger until block height 13,440,000 - some time around the year 2265. You can read all about the logic behind this check on line 1157 in BIP-042.
For any given block height we can easily calculate exactly where in the issuance curve / geometric series this block exists. All we need to know is how many halvings have occurred (line 1155) and then divide the original subsidy amount (50 BTC) in half by that many times, which is what the fancy bit shift operation on line 1162 does.
In addition to checking the block subsidy, we also need to prevent unintended inflation from occurring in non-coinbase transactions.
The first way to do this is to make sure every transaction's inputs actually exist and are spendable. You can find this check in the CheckTxInputs function in Bitcoin Core.
This, of course, is one of the most fundamental checks in the Bitcoin protocol - the prevention of double spending. If it was possible to spend the same money twice, that would be exploitable to arbitrarily inflate the money supply.
We also perform sanity checks on the input values to make sure they aren't negative and don't overflow. Either of these cases would result in the creation of new money; there was an overflow incident in Bitcoin's early days that did just that!
Another important validation for every non-coinbase transaction is to ensure the transaction's total output value is less than or equal to the input value, since a higher output would mean that new value is being created from nothing. The same validation function performs that check here.
Those are the critical checks to prevent arbitrary inflation of Bitcoin's money supply. There are additional mechanisms (difficulty adjustment) to control the issuance rate in terms of human time. If you're interested in learning more about them, check out my deep dives into Bitcoin's Timestamp Security and Bitcoin's Block Time Variance.
As noted earlier, actually summing up the total bitcoin supply every time we want to ensure that supply-related rules are being followed would be rather resource intensive. But it is possible to perform a more explicit verification - all you have to do is sum up the values of all of the unspent transaction outputs (UTXOs.)
Bitcoin Core offers a convenient utility function for performing a total money supply audit. This function is called gettxoutsetinfo.
At time of writing there are nearly 80,000,000 UTXOs in existence, so this call can take a minute or two to run depending upon your node's hardware.
My node that powers statoshi.info automatically calls this function after each new block that it processes. The number of coins that it returns is then stored in a database that is used to render this chart.
That's all there is to it! Bitcoin's monetary supply is both trivially predictable and verifiable. The previous thousand words you read were just an explanation of a dozen lines of code.
21 Million FAQs
There are several other questions that folks often have regarding Bitcoin's money supply.
Can the limit be changed?
Technically yes, though this is really a question of governance and incentives. Anyone can change the limits enforced by their own node - the hard part is convincing everyone else to do the same with their nodes. For a deep dive, check out:
Why 21 million and not ______?
What happens after all 21 million bitcoin are mined?
Miners don't only mint new coins - they also collect transaction fees. It's called a "block subsidy" for a reason - the issuance of new coins is only meant to help bootstrap the system while the transaction volume is low. As Bitcoin adoption increases, so does demand for (limited) block space and thus so do transaction fees.
How many bitcoins actually exist / are lost?
It's easy enough to count the value of all UTXOs in existence, though deeper investigation shows that some will never be created, some are provably unspendable, and some are probably (but not certainly) unspendable. Coinmetrics has a great post that analyzes the likely circulating supply.