Tokenomics: what a supply schedule actually commits to

Tokenomics is usually used to mean the numbers on a token’s page: a maximum supply, a circulating supply, an emissions rate, a vesting chart. As a list of figures it is a description. As a list of commitments it is more useful, because the commitments are not equally binding — some are enforced by the protocol, some by a contract that can be replaced, and some only by a document that nothing on-chain refers to.

The question to put to every figure is the same: enforced by what?

Supply: fixed, capped, or merely stated

Three different things get called a cap, and they differ in who could change them.

A cap enforced by consensus. Bitcoin’s is the clean case, though the 21 million does not appear in the whitepaper. The whitepaper says only that new coins are added at a steady rate and that, once “a predetermined number of coins have entered circulation”, the reward can move entirely to transaction fees.

The figure comes from the software. In Bitcoin Core, GetBlockSubsidy starts the subsidy at 50 coins and halves it by a bit shift every 210,000 blocks (the interval is set here) until it rounds down to zero at the 33rd halving, and a block whose first transaction pays out more than the subsidy plus fees is invalid. The 21 million is the sum of that schedule, not a separate rule — in whole satoshis it comes to 20,999,999.9769 coins (computed from the schedule) — and the MAX_MONEY constant, as its own comment says, is a sanity check on amounts and not the money supply. Nobody can issue more by deciding to; the only route is persuading node operators to run different rules.

A cap enforced by a contract. A token on a smart-contract chain has no consensus rule of its own; its supply is whatever its contract allows. The ERC-20 standard defines totalSupply but sets no rule about who may create more tokens or when. OpenZeppelin’s ERC20Capped fixes a cap once, at construction, and reverts any mint beyond it — a genuine constraint, but only as fixed as the code around it.

OpenZeppelin’s guide to creating supply calls the internal _mint function “the key building block” for extensions that implement a supply mechanism, so who may call it is a design choice. And a contract behind a proxy can be replaced altogether: in OpenZeppelin’s upgrade pattern the logic contract is swapped while the address stays the same, under the control of “a multi-sig wallet, a simple address or a complex DAO”. A cap in replaceable logic lasts until the upgrade key says otherwise.

A cap that is only stated. A maximum supply printed in a whitepaper, a documentation page or a token page binds nothing the chain checks. The contract may agree with it today, but the statement and the code are separate objects, and only the code runs.

So the answers to “enforced by what?” are consensus, a contract (with the question of who can change it), or nothing. A reserve-backed stablecoin is a different object again: its supply follows deposits and redemptions rather than a schedule, because what holds its peg is a reserve and a redemption right.

Emissions and who receives them

Emission is new supply created by a rule and paid to someone: block rewards to the miners or validators who produce blocks, staking rewards to those who lock tokens to secure a network, liquidity incentives to whoever a project pays to provide trading liquidity. The recipients differ; the accounting does not. Each emission is a transfer of share. If supply grows by a tenth and a holder’s balance does not, that holder owns a smaller fraction of the supply and the recipients a larger one. That is arithmetic about proportions, not a statement about price, and it means a reward paid in newly issued tokens is not income from outside the system: the supply rule is moving share towards participants and away from holders who do not take part.

Ethereum is the worked example, because it runs an issuance and a burn at once, set by different mechanisms. Ethereum.org’s account of supply after the Merge says new ETH is issued as rewards to validators who attest to and propose blocks, and that staking issuance fluctuates with the total amount of ETH staked. EIP-1559 splits a transaction fee into a base fee, set by a protocol formula that moves with how full the previous block was, and a priority fee. The base fee is “always burned (i.e. it is destroyed by the protocol)”, and only the priority fee goes to the block’s producer. Fee burning went live with the London upgrade in August 2021 and, according to ethereum.org, is unchanged since the Merge.

Net issuance is the difference, and the EIP is explicit that its sign was left open. Its section “ETH Burn Precludes Fixed Supply” says that if more is burned as base fee than is generated in rewards, ETH will be deflationary, and if more is generated than burned, inflationary; and that since its authors cannot control user demand for block space, they could not say which it would be.

That text was written for proof-of-work and speaks of mining rewards, but the logic carried over: ethereum.org describes the balance between issuance and burn as what determines the rate, and says that when fees are high enough net issuance is zero or less “for that day”. The sign is a property of a period, set by two unrelated inputs — a reward rule tied to the amount staked, and demand for block space. No current figure is quoted here, because it would be out of date within days.

Allocation and unlocks

Supply has to start somewhere, and the initial distribution is a list: a team, investors, a treasury or foundation, ecosystem incentives, perhaps a public sale. Each line has a quantity, a recipient and, where the tokens are locked, a vesting schedule saying when the recipient can first move them. A cliff releases nothing until a date; linear vesting releases in proportion to elapsed time; and designs differ on what happens where the two meet. In OpenZeppelin’s VestingWallet the curve is linear from the start date, and its cliff extension returns zero until the cliff, when everything accrued since the start becomes releasable at once. The schedule, not its label, is what needs reading.

It is the most consequential document in a token’s design because it decides when supply that already exists, and is already counted in the totals, becomes movable by the people who received it. It also sits underneath the headline figure. CoinGecko’s methodology says its circulating supply figures are obtained from the token teams and verified by CoinGecko, and that for tokens on smart-contract platforms they are calculated by deducting locked tokens — foundation, investor and team allocations — from total supply, using the balances of locked addresses from block explorers where available. CoinGecko’s circulating figure therefore rests on a list of locked addresses that the project supplies.

Where the schedule lives decides how far it can be trusted. Published as a table in a whitepaper or a PDF, it is a statement of intent: nothing connects the document to the contract, and a reader cannot tell from it whether any tokens are locked, only that someone says so. Implemented as vesting contracts, it can be checked — balance, start, cliff and end are public data on a block explorer, and the chain does the enforcing. The comparison is the check: does the contract holding the team allocation hold the amount the document states, and release it on the dates the document gives?

A vesting contract does not settle the question either. A treasury in an ordinary wallet or a multisig is locked by nothing but the intentions of whoever controls it; a vesting contract behind a proxy is only as locked as its upgrade key; and OpenZeppelin’s own documentation warns that, because the vesting wallet is ownable and ownership can be transferred, “it is possible to sell unvested tokens”. A lock controls when tokens can move, not who ends up owning them.

Burns, buybacks and the word “deflationary”

A burn reduces supply, and what that means depends on what was burned. At the contract level it is a specific operation: in OpenZeppelin’s ERC-20 implementation minting raises the total supply and burning lowers it, and a holder burns through a dedicated function such as the one in ERC20Burnable. An ordinary transfer, even to an address nobody can use, moves a balance and leaves totalSupply untouched, so “burned” on a token page can describe either, and totalSupply alone shows only the first. A buyback is a different act: the project buys its own token on the market, and what happens next decides the effect. The tokens can sit in a treasury, be redistributed, or be burned; only the last reduces supply. Which buybacks and fee burns count as a protocol’s fees reaching its token, and which do not, is set out in what protocol fees and revenue tell you. The fee and total-value-locked figures themselves, as of the latest snapshot, are in the DeFi protocols table.

What was burned matters as much as whether anything was. Fees paid by users, like Ethereum’s base fee, are tokens that were circulating and counted; burning them removes them from what holders and the market had. Burning treasury or locked allocation removes tokens that CoinGecko’s methodology above already excludes from circulating supply: it lowers the total, and where those tokens were already classed as locked the circulating figure stays where it was.

Then there is the rest of the ledger. A token that burns a little each day while a reward rule mints more has a growing supply with a burn mechanism attached. The figure that matters is net supply change over a stated period, issued minus burned, and the Ethereum case above shows why the period has to be stated. “Deflationary” as a property of a token therefore carries no information. As a description of the sign of net issuance over a period it can be true one week and false the next, and as an adjective it names a direction of travel and says nothing about who holds the supply, how much remains to be unlocked, or what the token is for.

What a reader can check in ten minutes

Most of the above can be checked on a block explorer. These steps describe tokens on Ethereum-compatible chains, where explorers such as Etherscan expose them; other chains present the same facts differently.

1. totalSupply. On the token’s contract page, the Read Contract tab shows the public data the contract exposes without a transaction or gas. Compare totalSupply with the token page and the document.
2. The mint path. In the source on the Contract tab, look for any function that creates tokens after deployment and what restricts the caller: an owner, a role, or nothing. A contract with no path to mint and no way to be replaced has a supply that cannot grow, whatever its page says; one with an owner-callable mint has a supply that one key controls.
3. Replaceability. Whether the contract is a proxy. Etherscan shows “Read as Proxy” and “Write as Proxy” sections once it has identified an implementation contract, though its own page says detection works from bytecode patterns and can be inaccurate. If it is a proxy, ask who controls the upgrade.
4. The vesting contracts. Take the addresses the document names for the team, investor and treasury allocations. Are they contracts or ordinary wallets, and do they hold the stated amounts? In OpenZeppelin’s design the schedule is readable as start(), cliff() and duration(); custom contracts name these differently.
5. Who holds the keys. For the token and each vesting contract, the owner or admin address. A single address, a multi-signature wallet and a governance contract are three different assurances, and a multisig’s signers and threshold can themselves be changed — the Pepe coin piece looks at what a multisig does and does not guarantee.
6. Burn claims. If a project says it burned tokens, check which kind it was: a fall in totalSupply, or a balance sitting at an address nobody controls.

Ten minutes audits nothing. Etherscan’s own guidance is that a “verified” contract means the published source matches what is deployed, not that it is safe or has been audited. What the steps do is turn each figure on a token page into a claim with an answer to “enforced by what?”. That matters because the inputs to a supply figure, like those behind a volume figure, start with the party they describe: the token team supplies the locked addresses behind a circulating supply, and the venue reports its own volume. Verification downstream helps, and it is limited by what it is given to verify.

None of this says anything about what a token is worth. It says what each of its numbers is bound by.