Max supply

A ceiling written into the protocol, where one exists

CoinMarketCap defines max supply as the theoretical maximum number of coins that can be minted, minus any verifiably burned coins, and gives Bitcoin's fixed 21 million as the canonical case.¹ Fidelity Digital Assets adds the qualifier that makes the definition useful: the ceiling holds without code changes so significant that they would require an entirely new version of the network, which is to say a hard fork.⁴

Fidelity also notes something most explanations skip. Bitcoin's supply is asymptotic and will never reach exactly 21 million, because the block subsidy halves until it falls below the smallest representable unit.⁴ The number everyone quotes is a limit the schedule approaches, not a total that gets minted.

That level of precision is available for Bitcoin because the issuance schedule is public, fixed and old. For most tokens it is not, which is where the reported figures start to diverge.

Not every token has a ceiling

CoinMarketCap states directly that not all cryptocurrencies have a predetermined fixed supply, naming Ethereum as one that does not.¹ Fidelity puts it more bluntly still: on the Ethereum network the total supply is, in theory, infinite, with practical nuances layered on top.⁴

An absent max supply is not a defect. It is a monetary policy choice, and for a network paying a perpetual security budget it is often the coherent one. What is a defect is presenting an uncapped token as capped, or letting a data provider infer a ceiling from a figure in your documentation that has no code behind it.

CoinMarketCap also distinguishes a fixed max supply from what it calls a deflationary max supply, one designed to decrease over time.¹ That second category is where the reporting gets messy, because a ceiling that moves is not really a ceiling.

Two providers, one token, 66.8 million tokens apart

On 3 August 2026 we read BNB from both providers. CoinGecko's API returned a max supply of 200,000,000 against a total supply of 133,164,946.5.² CoinMarketCap's page for the same token, on the same day, showed a max supply of 133.16 million, identical to its total supply, with circulating supply at 99.999998% of it.³

Neither provider is being careless. CoinMarketCap's own published definition subtracts verifiably burned coins from the theoretical maximum, so a token running programmatic burns has a ceiling that ratchets downward under that rule.¹ CoinGecko is reporting the protocol's original stated maximum and letting the total supply figure carry the burn history separately. Both are internally consistent. They just answer different questions with the same label.

This is the single clearest example we have found of why a supply figure needs a provider attached to it. A reader who checks one site walks away believing a third of the eventual supply has not been issued. A reader who checks the other walks away believing issuance is complete.

Why a max supply disagreement moves FDV by tens of billions

Take the CoinGecko read at face value. A market cap of $78,789,471,592 against a circulating supply of 133,164,946.5 implies a price near $591.67 per token.² Apply the common shorthand for fully diluted valuation, price multiplied by max supply, and the 200,000,000 ceiling produces roughly $118 billion.

Now apply the same shorthand using CoinMarketCap's max supply of 133.16 million and you get about $78.8 billion.³ Same token, same price, same day, a difference of roughly $39.5 billion in headline valuation, arising entirely from which provider's ceiling you used.

It gets one layer stranger. CoinGecko's own FDV field for BNB returned $78,789,462,480 on that read, within about nine thousand dollars of its market cap, which means it computed FDV from total supply rather than from its own max supply field.² The provider publishing the 200 million ceiling does not use it in its own FDV calculation. If you have ever wondered why two analysts quoting the same site disagree about a token's FDV, this is how.

A cap in code and a cap in a vote are different instruments

The question that matters at design time is not what number the cap is but what enforces it. An immutable contract with no mint function and no upgrade path is a commitment any holder can verify in an afternoon. A cap that a governance proposal can raise, or that sits behind an upgradeable proxy controlled by a multisig, is a policy the current signers happen to hold.

Both are legitimate designs. Only one of them is verifiable by a reader who does not trust you, which is the property that matters in a diligence process. What we tell founders is to state the enforcement mechanism in the same sentence as the number, every time. A cap of one billion tokens held by an immutable contract and a cap of one billion tokens held by a five of nine multisig are two different products, and investors who read carefully will price them differently.

Read the code, not the whitepaper. We have seen documented caps with a live mint function behind an upgradeable proxy more than once, and in every case nobody had lied. Nobody had checked either.

What to write down before launch

Four lines. The max supply figure, or an explicit statement that there is none, because an absent field invites providers to guess. The contract address and function that enforce it. Whether burns reduce the ceiling or only the total, since that single sentence resolves the disagreement described above before it happens. And who, if anyone, can change it, named by role and by mechanism.

Send those four lines to every data provider that lists you, then check what they published. The correction takes an email. Being quoted at the wrong FDV for two years because nobody sent the email costs considerably more than that.