A token standard is a published contract interface: the function names, arguments and events a token must expose so wallets, exchanges and other contracts can work with it without custom integration. It describes behaviour at the boundary. It says almost nothing about who controls the token, whether supply can grow, or whether transfers can be stopped, which is why standard compliance and safety are different questions.
A token can be fully ERC-20 compliant and still be mintable without limit, pausable by one address, upgradeable, and able to move balances without the holder's consent. The standard was never designed to prevent any of that. It was designed so a wallet can display a balance.
Scroll to see the full diagram
A standard is an interface, not a rulebook
EIP-20 is roughly one page of required behaviour. Six functions: totalSupply, balanceOf, transfer, transferFrom, approve and allowance. Two events: Transfer and Approval. Three optional metadata methods, name, symbol and decimals, which the specification explicitly marks as optional and tells other contracts not to assume are present.1
That is the whole contract between a token and the ecosystem around it. Implement those functions correctly and every wallet can read a balance, every exchange can build a pair, every lending market can hold the asset. Composability is the economic value of a standard, and it exists before your token does, which is the single strongest argument against inventing your own interface.
It is also the entire scope of the promise. A standard is a language, not a set of rules about what may be said in it.
What ERC-20 does not say
The specification is silent on supply caps, mint authority, burning, pausing, upgradeability, blocklists and forced transfers. A token that lets one address mint arbitrarily, freeze any holder and upgrade the logic next week violates nothing in EIP-20, because none of those behaviours appear in the standard to violate.1
Work the arithmetic on that. A project deploys an ERC-20, mints 100,000,000 tokens at deployment and publishes a fixed supply figure of 100,000,000. The deployer keeps a mint role. In month eight they mint 25,000,000 more. Total supply is now 125,000,000, and a holder who owned 1,000,000 tokens has gone from 1.0% of supply to 0.8%, a 20% dilution. Every step of that was standard-compliant. The Transfer event even fired on the mint exactly as EIP-20 specifies.
This is why we read the deployed contract rather than the documentation. The interface name on a project's front page tells you how the token talks. The admin roles in the implementation tell you what can be done to the people holding it.
The powers come from extensions, and each one is a decision
OpenZeppelin's ERC-20 documentation is the clearest inventory of what sits outside the base standard, because it lists each capability as a separate optional module: ERC20Capped enforces a cap on total supply when minting, ERC20Pausable adds the ability to pause transfers, ERC20Burnable allows destruction of held tokens, ERC20Permit adds gasless approval by signature, ERC20Votes stores past balances for governance, and ERC20FlashMint adds flash loan support.6
Read that list as a menu rather than a feature set. A supply cap is not something ERC-20 gives you; it is something you add and then have to prove you added. A pause function is not a safety feature by default; it is a power, and whether it reads as prudent or as a risk depends entirely on who holds the key and what the timelock is.
The practical version for a founder: write the capability list before the standard choice. Which of mint, burn, cap, pause, blocklist, forced transfer and upgrade does this design genuinely need, who can call each one, and behind what delay. That document is worth more in diligence than the standard name.
Fungible, non-fungible, and the multi-token case
ERC-721 covers assets where each unit is distinct: one owner per token ID, one transfer at a time, and an optional metadata extension where tokenURI returns a pointer per token.2 ERC-1155 covers the middle ground, specifying an interface for contracts that manage multiple token types in one deployment, in any combination of fungible, non-fungible and semi-fungible, with batch balance reads and batch transfers.3
The choice follows the shape of what you are issuing, not the marketing category. Ten thousand genuinely distinct items with per-token approvals belong on ERC-721. Forty item types with hundreds of copies each, which is what game inventories, tickets and open editions really are, belong on ERC-1155, where one call moves the lot. A fungible unit of account belongs on ERC-20 and nothing is gained by dressing it up.
Getting this wrong is not usually a compliance failure. It is a gas and integration failure that surfaces at scale, when a mint of 5,000 items costs several times what it should and every marketplace integration needs a special case.
Compliance standards move the rules out of the token
ERC-3643, the T-REX standard, is the clearest example of a standard that does carry rules. Its requirements state that it must be ERC-20 compatible, must be used in combination with an onchain identity system, must be able to apply any rule of compliance required by the regulator or the token issuer, and must expose an interface to pre-check whether a transfer will pass before it is attempted.4
The architectural move is worth understanding even if you never issue a permissioned asset. The rules do not live in the token contract. They live in an identity registry and a compliance contract that the token calls out to on every transfer, which is what lets an issuer change a holder cap or a country restriction without redeploying the asset. It also means those two contracts, not the token, are the real object of diligence.
The cost is distribution. A token that reverts on a transfer to an unverified address cannot sit in a permissionless pool, cannot be posted as collateral in a lending market that knows nothing about your registry, and cannot cross a generic bridge. You are choosing your venue list at the same moment you choose your standard, and that decision is easier to make with the venue list written down first.
Standards stack, and the higher ones assume the lower
Not every standard is a base token type. ERC-4626 specifies an API for tokenized vaults representing shares of a single underlying ERC-20 token, and describes itself as an extension on ERC-20 providing deposit, withdrawal and balance-reading functionality.5 It is share accounting with a common interface, sitting one level above the asset it wraps.
That layering is the healthy pattern and it explains why the ERC registry keeps growing without ERC-20 changing. Base interfaces stay small and stable. Application-level standards get built on top, and integrators pick which levels they support. A protocol that supports ERC-4626 gets every compliant vault at once, which is the same network effect that made ERC-20 worth adopting in the first place.
For a design team the reading is simple. If a capability you need already has a standard one level up, implementing it correctly buys you integrations you did not have to negotiate. If it does not, inventing a private interface means every integration is a bilateral conversation.
Choosing one, in the right order
Four things, in order. What the token legally is, because a permissioned instrument and an open utility unit have incompatible requirements and this is settled with counsel, not in a contract review. What venues the token must reach, written as an actual list of exchanges, lending markets and bridges. Which admin capabilities the design requires, each with a named holder and a delay. And only then the standard and its extensions, with a written note on why each rejected alternative did not fit.
The failure mode we see most is the reverse: a standard chosen because it was familiar, then a compliance requirement discovered afterwards, then transfer restrictions bolted on that break the venues the model assumed. That sequence costs a redeploy and a migration, and holders remember migrations.
One caution on the legal end. Whether a specific token is a security or a regulated instrument in a specific jurisdiction is fact-specific and belongs with your legal team. A standard cannot make that determination and no standard has ever made a token compliant. It only decides how cleanly the answer gets enforced once somebody else has made the call.
Common questions
What is a token standard?
A token standard is a published contract interface defining the functions and events a token exposes so wallets, exchanges and other contracts can integrate it without custom work. EIP-20, for example, requires six functions and two events and marks name, symbol and decimals as optional.1 The standard governs behaviour at the boundary; it does not govern supply, admin powers or upgradeability.
What is the difference between ERC-20 and ERC-721?
ERC-20 describes interchangeable units, where a balance is a single number and one token is identical to another.1 ERC-721 describes unique assets, where each token has its own ID, its own owner and its own metadata pointer.2 ERC-1155 sits between them, letting one contract manage fungible, non-fungible and semi-fungible types at once with batch transfers. The shape of what you are issuing decides which fits.
Does ERC-20 cap token supply?
No. EIP-20 says nothing about supply caps or mint authority, so a token can be fully compliant and still mintable without limit by whoever holds the mint role.1 A cap is added separately, for example through an extension such as ERC20Capped, which enforces a maximum total supply when minting.6 Check the deployed contract for a mint function and its access control rather than trusting a published supply figure.
Can a token standard enforce compliance rules?
Some can. ERC-3643 requires an onchain identity system and the ability to apply any compliance rule required by a regulator or issuer, checking every transfer before it settles.4 The rules live in an identity registry and a compliance contract rather than in the token, so they can change without a redeploy. The cost is distribution, since permissioned tokens cannot sit in permissionless pools or cross generic bridges.
Which token standard should a new project use?
Decide the instrument, the venues and the admin capabilities first, then the standard follows almost automatically. An open fungible unit with no holder restrictions points at ERC-20 plus whichever extensions the capability list genuinely requires. A permissioned instrument with eligibility rules points at a compliance standard such as ERC-3643. Unique items point at ERC-721, and editions or inventories point at ERC-1155.
See Tokenomics Design Services for how this applies in practice.
Sources
- EIP-20: Token Standard
Ethereum Improvement Proposals, 2015
Required functions totalSupply, balanceOf, transfer, transferFrom, approve and allowance, plus Transfer and Approval events. Name, symbol and decimals are marked optional and other contracts are told not to expect them. - EIP-721: Non-Fungible Token Standard
Ethereum Improvement Proposals, 2018
One owner per token ID, with an optional metadata extension where tokenURI returns a per-token pointer. - EIP-1155: Multi Token Standard
Ethereum Improvement Proposals, 2018
An interface for contracts managing multiple token types in one deployment, covering fungible, non-fungible and semi-fungible balances, with batch reads and batch transfers. - EIP-3643: T-REX, Token for Regulated EXchanges
Ethereum Improvement Proposals, 2021
Requires ERC-20 compatibility, an onchain identity system, the ability to apply any compliance rule required by regulator or issuer, and a pre-check interface for transfers. - EIP-4626: Tokenized Vault Standard
Ethereum Improvement Proposals, 2022
An API for tokenized vaults representing shares of a single underlying ERC-20 token, described as an extension on ERC-20 for deposits, withdrawals and balance reads. - ERC20 API documentation, Contracts 4.x
OpenZeppelin, 2026
Lists supply cap, pausing, burning, signed approvals, governance snapshots and flash minting as separate optional extensions rather than base standard behaviour.
Last reviewed 2026-08
Know the terms but not sure how they apply to your project? That is what an engagement is for. We design, document, and stress-test the whole token economy inside the Tokenomics Data Room.
100+ projects advised. Complete tokenomics in 4 to 6 weeks.