Bitcoin's supply follows a schedule written into its software rather than a policy decision made by anyone. The rate of new issuance falls at predetermined points.
New coins are created as a block reward
Each block added to the chain includes a transaction that creates new coins and assigns them to whoever produced the block.
This is the only mechanism by which new units enter circulation, so issuance is tied directly to block production rather than to demand or price.
Because the protocol targets a steady interval between blocks, issuance proceeds at a predictable pace between adjustments.
The reward halves at fixed intervals
After a set number of blocks, the protocol cuts the block reward in half, and this repeats indefinitely at the same interval.
Each halving reduces the rate at which new supply is created, without affecting coins already in circulation.
Because the interval is measured in blocks rather than calendar time, the dates are approximate and depend on how quickly blocks are actually produced.
Repeated halving produces a cap
A series of halvings is a geometric sequence, and its sum converges, which is where the frequently cited maximum supply comes from.
The reward eventually becomes too small to represent in the smallest unit the protocol recognizes, at which point issuance ends entirely.
The cap is therefore a consequence of the halving schedule rather than a separate rule imposed on top of it.
Fees are designed to replace the subsidy
Miners are paid by the block reward and by transaction fees, and as the reward declines, fees are intended to become the dominant compensation.
Whether fee revenue proves sufficient to sustain the security budget is an open design question that has been debated since the mechanism was described.
This piece describes the mechanism rather than predicting outcomes, and nothing here suggests how any asset's price will behave.
Changing the schedule would require consensus
The issuance rules are enforced by every node validating blocks, so a block violating them is rejected regardless of who produced it.
Altering the schedule would require the participants running that software to adopt an incompatible change, which is a coordination problem rather than a technical one.
That difficulty is the point of the design: predictability comes from the cost of changing the rule, not from a promise that it will not be changed.