This equation is the most commonly seen equation to explain bitcoin’s issuance schedule. This equation is often sited as the reason why Bitcoin has a 21Million issuance cap, which is Bitcoin’s main value proposition.
But did you know, that this equation is:
A) not in the white paper.
B) not exactly how it is implemented in the code.
When I started to dig into it —to better understand it myself, I came across these two realizations, and was surprised by them.
In the White Paper
I recently went back and read through the Bitcoin white paper. I was surprised to see that this supply issuance equation does not appear anywhere in it. In fact, there is no mention of the 21Million supply cap either. In fact, there is very little math or code referenced in the white paper. But here’s why: The only math included was a probability equation that Satoshi included to demonstrate how difficult it would be for an attacker to “double-spend” or cheat the system – and how that probability decreases quickly. The White Paper is a high-level discussion / announcement of the Bitcoin Network as a System. It doesn’t include any implementation details. So this issuance equation is never mentioned in the white paper, but instead was actually derived from the code itself. And yet, it is not exactly how it is implemented in the code, either.
The Math
If we analyze this equation, we see that it is what is known as a geometric series. The symbol is shorthand for representing a series, or a loop. The series starts with the number set at the bottom (zero) - and goes up until the number at the top (32). We've all heard that Bitcoin has a 21 million supply cap, and if you actually calculate this equation, you'll see that it does produce the sum of 21 million.
Each term is half the previous one (50, 25, 12.5, 6.25...). This halving series, when summed to infinity, converges to exactly 2× the first term — a classic property of geometric series with ratio ½. The 210,000 × 50 = 10.5M, doubled = 21M.
But you may have heard that the true supply is actually a little bit less than 21 million. In fact it is 2,099,999,997,690,000 sats. So this left me with the question: Why is this slightly less than 21M?
This equation we are all so familiar with is reverse engineered from the code. But it is actually a little bit of a simplification of the way the bitcoin supply is issued because it shows 50 BTC, but a more accurate representative equation would show this calculation in SATS. (5,000,000,000 / 2^n).
What's the difference? Does this nerdy little detail even matter? Trying to wrap my brain around the math led me to a deeper understanding of the implementation -- and that revealed an extremely important and clever mechanism that actually is at the core of how Bitcoin actually works - and enforces consensus.
How it is implemented in the code
In the code, the calculations are derived using satoshis. The bitcoin code works in whole satoshis, and Satoshi chose to only use integer math. There are no decimals or fractions of a satoshi. If you calculate the block subsidy using BTC (Bitcoins) - even by the third epoch you would arrive at a fractional number (12.5) - and the fractions get even smaller from there. 6.125, 3.0625, etc. These fractions require floating point math to calculate. And Satoshi very intentionally chose to avoid using floating point math. Satoshi intentionally chose to avoid using floating point math because different computer systems notoriously calculate floating point math differently, so Satoshi chose to simplify the calculations using integer math only — in order to guarantee consensus among a broad distributed network.
So the starting subsidy (block reward) was 50 BTC - but in the code it is calculated in sats -- which is 5,000,000,000 (5 Billion) sats per block. So using the satoshi math, 210,000×5,000,000,000×2=2,100,000,000,000,000 sats. In other words we still arrive at 21 million. But the true supply is: 2,099,999,997,690,000 sats. Why is this slightly less than 21 million?
Because of the way the >>= operator works in code.
In the code, it looks like this:
• COIN = 100,000,000 (100 million sats)
• subsidy = 50 * COIN
• subsidy >>= halvings
CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
// Force block reward to zero when right shift is undefined.
if (halvings >= 64)
return 0;
CAmount nSubsidy = 50 * COIN; // 50 BTC in satoshis = 5,000,000,000
// Subsidy is cut in half every 210,000 blocks (≈ 4 years)
nSubsidy >>= halvings; // Right bit-shift = divide by 2^halvings
return nSubsidy;
}
Here's the crux of the magic:
nSubsidy >>= halvingsWhat this effectively means is that the subsidy is calculated by taking the math-floor of the max-subsidy divided by 2^halvings.
What this is saying in plain English: take the max block subsidy (5B satoshis), and then divide it by 2 raised to the number of halvings that have occurred, and round down to the nearest integer. This means that some of the satoshis get lost. The fractions of satoshis after epoch 10 get clipped. This was a trade-off that Satoshi made, that reveals his genius engineering.
So concretely:
At launch, nSubsidy = 5,000,000,000 satoshis (50 BTC), halvings = 0
After halving 1, halvings = 1 → ⌊50 / 2¹⌋ = 2,500,000,000 sats ( 25 BTC )
After halving 2, halvings = 2 → ⌊50 / 2²⌋ = 1,250,000,000 sats ( 12.5 BTC )
After halving 3, halvings = 3 → ⌊50 / 2³⌋ = 625,000,000 sats (6.25 BTC)
The floor function matters because after 10 halvings the division produces a fraction of a satoshi — which can't exist — so it gets truncated. Eventually, around halving 33, the result floors all the way to zero, which is when Bitcoin's issuance permanently stops.
So there aren’t any decimals. Ever. The >> in C++ code is a “bit-wise” CPU instruction, that guarantees an integer result (and never produces a floating point value). This is “guaranteed flooring” because bitshift truncates down. This flooring at each division is the reason the supply ends slightly below 21M. And this was a very intentional choice that Satoshi made – because different CPUs can produce different floating-point results. So having these values computed as integers using the bit-wise CPU instruction is a huge part of what makes it possible for a globally distributed network of computers to have consensus.
The elegegance of Satoshi's code implementation is what makes Bitcoin's consensus mechanism work
If the code used floating point numbers and therefore derived conflicting values on different machines, the consensus mechanism of the system wouldn’t work. This flooring function removes any amount of satoshis that are less than one whole satoshi. This first happens at Epoch 10 – 9765625 (the subsidy from Epoch 9) / 2 = 4882812.5 – but the .5 gets removed by the flooring function. The next 22 epochs all have fractional satoshis in their subsidy amount which gets removed by the flooring function. If you add up all of these lost fractional satoshis, you get 2,310,000 sats lost which is the same as the difference between 21M and the true supply of: 2,099,999,997,690,000 sats That is the real, provable, exact total supply of Bitcoin as implemented in the code.
Engineering Genius
This level of sophistication and experience in Satoshi's thinking is what I find so fascinating. It seems to reveal that Satoshi had a deep understanding of how financial transactions have been handled by computer systems and how this has evolved over decades. Satoshi’s avoidance of floating point math wasn’t just clever — it was essential. His choices ensured deterministic consensus, reproducible integer math, identical behavior on all CPUs, no rounding errors. All of this leads to a secure, predictable monetary policy. The >> operator is actually a perfect example of the type of thinking needed to create a decentralized system where nodes must agree exactly, down to the last satoshi.
