What is the difference between fixed and mintable token supply?
A fixed-supply token mints its entire supply once, in the constructor, at deploy, and the contract contains no function that can ever create more. A mintable token keeps a mint function on the contract, callable later by the owner or a designated minter role, that creates new tokens on demand. Both are legitimate designs; they just optimize for opposite things.
Neither choice comes from the ERC-20 standard itself. The standard, formalized as EIP-20 and proposed by Fabian Vogelsteller with Vitalik Buterin in November 2015, finalized in 2017, only defines how balances, transfers and allowances work. It says nothing about whether supply is fixed or mintable, that decision lives entirely in the constructor and the mint function you choose to include, or leave out, of your own contract. You can read the full EIP-20 specification on ethereum.org if you want the underlying interface.
Why can't you change this decision after deploy?
You can't change it because the contract's code is fixed the moment it is deployed. Whether a mint function exists, what the cap is, who can call it, all of that is baked into the bytecode that goes on-chain. A standard, non-upgradeable token contract, which is what most launches use because it is simpler to trust, has no mechanism to add or remove functions later.
That means the choice is not a setting you revisit next quarter. If you launch fixed supply and later discover you need to mint rewards, your only path is a brand-new contract, a new deploy, and a migration that asks every holder to move their balance over. That is disruptive, costly in gas and trust, and it resets any liquidity or exchange listings built around the original token. Get this decision right before you deploy, not after.
Fixed supply: what do you gain and give up?
Fixed supply gives you a promise that cannot be broken: the total number of tokens that exist today is the total number that will ever exist. There is no dilution, no future mint that can quietly reduce every holder's share, and nothing for anyone to abuse because the capability to create more tokens simply does not exist in the contract.
The trade-off is flexibility. If your project ever needs new tokens, for staking rewards, a liquidity incentive, a grants program, or an unforeseen use case years down the line, a fixed-supply token cannot provide them. Everything must come from the original allocation, split up front. That works well for a token whose value proposition is scarcity itself, but it forces you to solve every future funding need at launch, when you know the least about what you will actually need.
Mintable supply: what do you gain and give up?
Mintable supply gives you a mint function that lets you create new tokens after launch, which is genuinely useful for staking reward emissions, ongoing incentive programs, or grants that pay out over years rather than being pre-allocated in one shot. You are not locked into guessing your entire multi-year token economy on day one.
What you give up is the trustless guarantee. Every mintable token asks holders to trust whoever controls the minter or owner key, because that party can, technically, create more tokens at any time the contract allows. A responsible team caps the mint, uses a multisig for the owner key, and is transparent about mint events. But the trust assumption itself does not go away, it just gets managed. Be honest with your holders about who holds that key and what limits, if any, constrain it.
Fixed vs mintable supply: side by side
Here is the comparison, stripped to the trade-offs that actually decide which one fits your project.
| Fixed supply | Mintable supply | |
|---|---|---|
| Future issuance | None, total supply is locked at deploy | Owner or minter role can create more later, up to any cap you set |
| Inflation risk | None from the contract itself | Real, scales with how much and how often new tokens are minted |
| Trust assumption | Trustless after deploy, nothing left to abuse | Depends on who holds the minter or owner key |
| Best for | Scarcity-driven tokens, simple utility or community tokens | Staking rewards, incentive programs, ecosystem grants paid out over time |
Neither column is the "correct" answer. A token that will never need new emissions gains nothing from mintability and only adds a trust assumption it does not need. A token funding years of staking rewards cannot function on a fixed supply set on day one.
What does a maximum supply cap actually do?
A maximum supply cap is a hard ceiling written into the mint function itself, so that even if mintable supply is enabled, total tokens can never exceed a number you fix at deploy. OpenZeppelin's ERC20Capped extension implements this by checking the cap on every mint call and reverting any mint that would push total supply past it, whether the owner intended to or not.
A cap is how you get some of the benefit of both models: the flexibility to mint over time, without an open-ended promise that supply could grow forever. If you are choosing mintable supply mainly to fund a known program, staking rewards over four years, for example, setting a cap equal to what that program actually needs is a way to bound the trust assumption instead of leaving it unlimited. See OpenZeppelin's ERC20Capped documentation for the exact mechanics.
Should your token be burnable?
A burnable token lets holders permanently destroy their own tokens, which reduces total supply and cannot be reversed. OpenZeppelin's ERC20Burnable extension is the standard implementation: it adds a burn function that sends tokens to an unspendable state rather than to any address that could recover them.
Burnable makes sense when your token model depends on supply shrinking over time, buyback-and-burn programs, fee-burning on transactions, or simply giving holders a way to voluntarily reduce circulating supply. It is a one-way door in the truest sense: a burned token is gone, not paused, not recoverable, gone. That permanence is the entire point, but it means a burn function should never be added casually or triggered by a bug. Review OpenZeppelin's ERC20Burnable reference before wiring burn logic into anything automated.
Should your token be pausable?
A pausable token lets a designated role freeze every transfer across the entire token, instantly, until it is unpaused. OpenZeppelin's ERC20Pausable extension is built for exactly one scenario: something has gone wrong, an exploit, a compromised contract elsewhere in your stack, a legal or compliance requirement, and you need to stop movement while you respond.
Be honest about what this means: a pause function is centralization by design. Whoever holds that role can freeze your holders' tokens, including tokens they have every right to move, for as long as the pause is active. That is a real safety net, and plenty of serious projects ship with one. But it is also a real power over other people's assets, and it belongs in the hands of a multisig, not a single key, with clear public rules for when it gets used. Read OpenZeppelin's ERC20Pausable documentation to see exactly what the pause role can and cannot do.
How does Saleium's Token Creator handle these choices?
Saleium's Token Creator lets you choose fixed or mintable supply at the moment you create your token, and that choice is set once and immutable from then on, exactly like any other ERC-20 deploy. You can add an optional maximum supply cap alongside a mintable setup, and turn on burnable and pausable controls independently, so you are not forced into an all-or-nothing bundle.
Under the hood it builds on OpenZeppelin's audited base: ERC20, plus ERC20Burnable, ERC20Pausable and ERC20Permit for gasless approvals, with two-step ownership transfer so an ownership handoff cannot be sent to the wrong address by mistake. Token Creator is BNB Chain only for now. If you have not gone through the deploy flow itself, the no-code token creation walkthrough covers the full process, and unfamiliar terms along the way are covered in the glossary.
Which supply model fits your project?
Work through this before you open the deploy flow, not after:
- Do you know, today, every future use for new tokens? If yes, fixed supply is simpler and removes a trust assumption you do not need.
- Will you need to fund staking rewards, incentive campaigns or grants over months or years? Mintable supply, with a cap sized to that program, is the more honest fit.
- Who will hold the minter or owner key if you go mintable? A single hot wallet is a liability; a multisig is the baseline expectation from serious holders.
- Does your model depend on supply shrinking, not just staying flat? If so, add burnable regardless of your fixed-or-mintable choice.
- Do you need an emergency stop for compliance or incident response? Pausable buys you that, at the cost of a centralization point holders will ask about.
If your project pairs mintable emissions with reward pools, it is worth reading how on-chain staking rewards actually get funded and released, since that is the most common reason teams choose mintable supply in the first place. Get the fixed-or-mintable call right once, and the rest of your token's supply story stays simple to explain and impossible to walk back.