Supply invariant

The name is ours, the concepts are not

Supply invariant is a framing device rather than a standardised term. No canonical academic or industry source originates the compound, and anyone presenting it as established vocabulary is dressing it up. What is well documented are the things it groups together: consensus-enforced supply schedules, contract-level minting conditions, and the softer category of governance targets that look like rules until they are tested.

The framing earns its keep because it forces one question that a supply chart never asks. Not what the supply will be, but what would have to happen for the supply to be something else.

Where an invariant can actually live

The strongest place is consensus. Bitcoin's block subsidy is issued on a schedule that halves every 210,000 blocks, and a block paying more than the schedule allows is simply not a valid block to an honest node.¹ Nobody enforces that rule as a policy decision. It is enforced by every participant refusing to accept the alternative, which is why the cap is credible in a way an announcement never is.

The second place is contract code. A mint function that checks registered backing before issuing, and reverts when the check fails, enforces a one-to-one claim mechanically instead of rhetorically. The strength here is bounded by whatever the contract permits: an upgrade path, a privileged role or a pausable oracle relocates the invariant to whoever holds that key. That is why an admin-capability review belongs next to any invariant claim.

The third place is policy, and it is where most tokens actually keep their supply rules. A governance-set inflation ceiling is real until a vote moves it. That is not a criticism. Adjustability is often the correct design. It is a criticism of calling it an invariant in the documentation.

Hard caps and conditional rules are different objects

A hard cap is unconditional: this quantity, never more. A conditional rule produces a supply outcome that depends on behaviour. Ethereum after EIP-1559 is the standard illustration, since each block's base fee is burned rather than paid to the producer, so net issuance can be positive or negative depending on how much the network is used.² That is a genuine, formally specified mechanism, and it is not a cap.

The distinction matters most in a financial model. A hard cap can be assumed. A conditional rule has to be simulated across a demand range, including the range where usage disappoints, because that is the scenario where the conditional rule produces the outcome the marketing never mentioned. NIST's token design overview is a useful neutral reference for the categories of supply and management constraint a token system can carry.³

Writing one so it can be checked

Backed one-to-one is a sentence. An enforceable invariant needs five things: the quantity being constrained, the source of truth it is measured against, the update frequency of that source, the tolerance band, and the behaviour on violation. An invariant that relies on an oracle updating every 24 hours leaves a 24-hour window in which real backing can sit below circulating supply without anything reverting. That window is a design decision whether or not anyone decided it.

So the first line of a supply review is not the emission schedule. It is the list of ways supply could exceed what the documentation promises, and for each one, the specific thing that stops it. If a line on that list ends with we would not do that, it is not an invariant. Write it down as a policy, disclose it as a policy, and put the lever somewhere a holder can watch it move.