Bitcoin is often described as digital scarcity. But unlike gold, land, or collectibles, Bitcoin’s scarcity is not physical, it is enforced by software. So an obvious question arises: How do we actually know there will only ever be 21 million bitcoin?Is it just a promise? A social agreement? Or something we can independently verify? Understanding this question reveals one of Bitcoin’s most important properties, and why self-custody matters: Bitcoin doesn’t rely on trust.
In traditional finance, monetary supply ultimately depends on institutions. Central banks can expand or contract the money supply. Governments can change rules. Policies evolve over time. Bitcoin works differently. Bitcoin is a distributed system where every participant verifies the rules themselves. No authority decides how many coins exist. Instead, all nodes enforce the same consensus rules.
One of these rules governs how new bitcoin are introduced: the block subsidy. New bitcoins are created exclusively when miners produce valid blocks, each new block containing a fixed reward that follows a predictable schedule. Since every node verifies this rule independently, any invalid inflation attempt is automatically rejected by the network. There is no single administrator capable of overriding this process.
Predictable by design
When Bitcoin launched in 2009, miners received 50 BTC per block. But this reward doesn’t stay constant. Every 210,000 blocks, roughly every four years, the block reward is cut in half. This event is known as the halving.
The total supply of almost 21 million is calculated by summing the issuance across all 32 halving periods. For each period, the reward is calculated by taking the initial block reward of 50 BTC and dividing it by 2i, where i is the number of halvings that have occurred. Since each period consists of 210,000 blocks, the total coins for any period is 210,000/times (50 / 2i). This means the first period (i=0) adds 210,000*50 BTC, and the second period (i=1) adds 210,000*25 BTC, and so on.The sequence looks like this:
- 0 Halvings: 50 BTC per block - 10,500,000 BTC issued this period
- 1 Halving: 25 BTC per block - 5,250,000 issued this period
- 2 Halvings: 12.5 BTC per block - 2,625,000 BTC issued this period
- 3 Halvings: 6.25 BTC per block - 1,312,500 BTC issued this period
- 4 Halvings: 3.125 BTC per block - 656,250 BTC issued this period (we are here by the way)
- …and so on
This geometric reduction means fewer new bitcoin are created over time, approaching zero asymptotically. The last fractions of bitcoin will be mined around the year 2140, but the important insight is this: The 21 million limit naturally emerges from the halving formula itself, yet it is never quite reached, because the math ensures we will always be “halfway there”.
You don’t need to trust the math, you can run it, and you can verify all the code enforcing it yourself, and not just that, you can also run a Bitcoin node to calculate the issuance yourself.
Enforcing the math
The true power of this auditable formula lies in its decentralized enforcement. Every participant running a Bitcoin node acts as an independent auditor of the monetary policy. When a miner attempts to include a block that violates the strict issuance rules, for instance, by claiming more than the permitted block subsidy, that block is instantly recognized as invalid by every node. Because these nodes will reject the invalid block and refuse to relay it, the inflation attempt fails and the block can never become part of the canonical blockchain.
This process ensures the supply cap is maintained purely through mutual, technical verification. The enforcement of Bitcoin's auditable monetary formula is achieved through decentralization. The supply cap is upheld because every full Bitcoin node functions as an independent auditor of the monetary policy. If a miner tries to create a block that breaks the strict issuance rules, such as claiming a block subsidy that exceeds the permitted amount, the node network instantly identifies the block as invalid. Consequently, all nodes reject the invalid block, refuse to relay it, and prevent the inflationary block from ever being added to the official blockchain. This mechanism ensures that the supply limit is maintained purely through a process of mutual, technical verification across the network.
Verifying the code
Now that we know how the math works and that nodes in the network enforce these rules a good next step is verifying the code that enforces them itself. On Bitcoin Core’s Github repository, Bitcoin’s reference implementation, we can find all of the client’s source code and also the consensus libraries, we will be using the latest stable version at the time of writing, 31.0.Lets start with src/validation.cpp, as this is where most of the magic happens, as you can see in the next block of code that goes from line 1835 to line 1848.
This block is composed of two sections that define the reward, the first one calculates at which halving we are at right now and then forces the block reward to be 0 after 64 halvings. int halvings = nHeight / consensusParams.nSubsidyHalvingIntervalunt calculates the current halving by dividing the current block height by the constant halving interval, the variables used in this calculation are, nHeight: The current number of blocks in the blockchain (the block height). consensusParams.nSubsidyHalvingInterval: The static parameter set to 210,000 blocks as defined in /src/kernel/chainparams.cpp, which specifies the number of blocks that must pass before a halving occurs. And int halvings: The integer result of this division, rounded down, which represents the current halving period.At the moment I’m writing this words the block height is 946227, so let’s use in our next example to help you visualize this function:
946227 / 210000 = 4,505842857
Which is rounded down to 4 instead of up to 4 as you would do conventionally.
This results in: int halvings = 4
Right after this we can find if (halvings >= 64); return 0; which might sound strange as Bitcoin is supposed to have 32 halvings. This is just a bugfix for something called a Memory Overflow, which would cause the halvings to reset to 0 after it happens 64 times, essentially making the protocol issue 21 new million coins throughout another 64 halvings, after which another 21 million coins will be issued again throughout yet another 64 halvings, indefinitely, until the end of time if unfixed.
Then we have CAmount nSubsidy = 50 * COIN, this is the 50 / 2i formula from the previous section of this article, COIN being defined as 100000000 in the /src/consensus/amount.h which is the number of satoshis, smallest divisible unit of a bitcoin, in a bitcoin. The CAmount nSubsidy value, which represents the initial block reward of 5 billion satoshis (50 * COIN), or 50 BTC, has a 33-bit binary representation: 100101010000001011111001000000000. This 33-bit length is significant because the code uses this structure for efficient bitwise shifting to perform the division during each halving event.
Every halving event nSubsidy >>= halvings; return nSubsidy; takes 100101010000001011111001000000000 and moves it one digit to the right, essentially removing its last digit, which in binary would mean, as the name of the event implies, dividing it in half.
If you have been looking at the links provided in this explainer, you might have noticed that inside /src/consensus/amount.h exists this piece of code:
You might be thinking “So that’s it, there’s the 21 million coins limit is” and you might be right, but this is not 100% true. Why so? Because this is not the main rule to set the limit, but a sanity check. What this block of code does is that it doesn’t allow the supply to go over 21 Quadrillion satoshis, or rather 21 Million bitcoins, a number we know will never be reached, in the case that somebody finds a bug that produces coins out of thin air like it was in the case of 2010’s Value Overflow Bug which allowed an attacker to print 184 Billion bitcoins, or 2018’s Duplicate Inputs Vulnerability which allowed an attacker to spend the same coin twice.
Could the rules ever change?
The obvious question that follows is whether the code, being software, could simply be updated to increase the coin supply. While anyone is technically free to modify the open-source software, practically, changing Bitcoin's monetary policy is extraordinarily difficult. Consensus rules only change if the overwhelming majority of users voluntarily adopt them. History proves this dynamic: even minor protocol adjustments demand years of coordination. An inflationary change could fundamentally undermine Bitcoin’s value proposition, meaning the market would likely refuse to run the new version. The supply cap is therefore enforced through consensus amongst market participants.
Conclusion
Bitcoin’s fixed supply is not secured by government decree, physical constraints, or institutional trust. Its guarantee rests entirely on three pillars: a transparent issuance schedule, independent verification by every node, and the ability for users to choose which rules they accept. Unlike legacy systems that rely on the decisions of central authorities, Bitcoin's policy is embedded directly into a network of mutually verifying participants, resulting in a monetary system whose supply is auditable by anyone, at any time, ensuring the supply is limited, but most importantly, ensuring users don’t need to trust that this rule will hold true, but rather, that they can verify it themselves.
FAQs
How is the 21 million Bitcoin limit enforced?
The 21 million limit is enforced by Bitcoin’s consensus rules, which every full node verifies independently. New bitcoin can only be created through the block subsidy, and that subsidy follows a fixed halving schedule. If a miner tries to create more bitcoin than allowed, their block is rejected by the network as invalid.
Can Bitcoin’s supply cap be changed?
In theory, anyone can modify Bitcoin’s open-source code. In practice, changing the supply cap would require broad adoption by users, businesses, and node operators across the network. Because Bitcoin’s fixed supply is one of its core value propositions, an inflationary change would likely be rejected by the market.
Why does verifying the supply cap matter for self-custody?
Verifying the supply cap matters because Bitcoin is designed to minimize trust. Instead of relying on institutions or promises, users can independently check the rules, the code, and the blockchain itself. Running your own node is the strongest way to verify that Bitcoin’s monetary policy is being enforced as expected.
Don’t own a BitBox yet?
Keeping your crypto secure doesn't have to be hard. The BitBox hardware wallets store the private keys for your cryptocurrencies offline. So you can manage your coins safely.
Both the BitBox02 Nova and the BitBox02 also come in a Bitcoin-only edition, featuring a radically focused firmware: less code means less attack surface, which further improves your security when only storing bitcoin.
Buy the BitBox02 Nova or grab a BitBox02 in our shop!
Shift Crypto is a privately-held company based in Zurich, Switzerland. Our team of Bitcoin contributors, crypto experts, and security engineers builds products that enable customers to enjoy a stress-free journey from novice to mastery level of cryptocurrency management. The BitBox02, our second generation hardware wallet, lets users store, protect, and transact Bitcoin and other cryptocurrencies with ease — along with its software companion, the BitBoxApp!