Token standards are agreed-upon sets of rules — written as interface specifications in smart contract code — that define how a token behaves and communicates with other software. They are the reason a token minted by one team can be automatically listed on an exchange, stored in any compatible wallet, and read by any block explorer without those developers ever speaking to each other.
Think of a token standard as a power socket specification. Once the shape is agreed upon, every plug and every device that follows the spec works together. Without standards, each new token would be its own bespoke protocol, and the composable ecosystem that defines decentralized finance and NFTs could not exist.
Why standards matter
Smart contracts on networks like Ethereum are programs that run on a shared virtual machine — the EVM. When one contract wants to interact with a token contract, it needs to know which functions to call and what to expect back. A standard guarantees that answer.
Without this guarantee, a decentralized exchange would need custom integration code for every single token. Wallets would need to be updated every time a new project launched. The whole point of a programmable blockchain — open, permissionless composability — would collapse into a pile of one-off integrations.
Standards on Ethereum are published as ERCs (Ethereum Request for Comments), a community process similar to how internet protocols are proposed and ratified. Once widely adopted, an ERC becomes part of the shared vocabulary every developer can rely on.
ERC-20: the fungible token standard
ERC-20 is the standard for fungible tokens — tokens where every unit is identical and interchangeable. One ERC-20 token is exactly equal to any other token of the same type, just as one dollar bill is interchangeable with any other.
The standard defines a small, elegant set of functions:
| Function | What it does |
|---|---|
totalSupply() | Returns how many tokens exist |
balanceOf(address) | Returns the token balance of an address |
transfer(to, amount) | Sends tokens from the caller to another address |
approve(spender, amount) | Authorises a third-party contract to spend tokens on your behalf |
transferFrom(from, to, amount) | Executes a spend that was previously approved |
allowance(owner, spender) | Returns how much a spender is still allowed to use |
The approve / transferFrom pair is especially important for DeFi. When you deposit tokens into a lending protocol or a liquidity pool, you first approve the protocol’s contract to move your tokens, then the protocol calls transferFrom to actually take them. This two-step handshake keeps you in control while enabling programmable finance.
Almost every token you encounter in the crypto ecosystem — stablecoins, governance tokens, wrapped assets — is an ERC-20. Understanding this standard is foundational to understanding what coins and tokens actually are.
ERC-721: the non-fungible token standard
ERC-721 introduced non-fungibility. Where ERC-20 tracks balances, ERC-721 tracks individual ownership of distinct items. Each token has a unique integer ID, and ownership of that specific ID is what you hold in your wallet.
The core addition over ERC-20 is ownerOf(tokenId), which returns the address that owns a particular token ID. Combined with transferFrom, this gives every NFT a provable, on-chain chain of custody.
Key insight: The ERC-721 standard does not store images or metadata on-chain. It stores a
tokenURI— a pointer to a JSON file that describes the token’s attributes and links to the artwork. What you are actually buying is the on-chain record of ownership of a particular ID; the media itself typically lives off-chain (often on IPFS or a centralised server).
This architecture means that ERC-721 is lightweight and flexible, but it also means the media can disappear if the hosting goes away. Understanding this distinction is important when evaluating the durability of any NFT.
ERC-721 powered the first major wave of NFT projects — digital art, profile pictures, and collectibles — and remains the dominant standard for unique digital assets.
ERC-1155: the multi-token standard
ERC-1155 was designed to handle a limitation that became obvious in gaming and large-scale NFT projects: deploying a separate contract for every token type is expensive and inefficient.
ERC-1155 allows a single contract to manage many token types simultaneously — some fungible, some non-fungible, some semi-fungible. A game might use one ERC-1155 contract to track gold coins (fungible), health potions (fungible), unique swords (non-fungible), and limited-edition armour sets (semi-fungible — there are 500, but each is fungible within that edition).
The headline improvement is batch transfers: you can move multiple token types to multiple addresses in a single transaction, which dramatically reduces the gas cost compared to firing off many individual ERC-721 transfers. For a game that needs to distribute hundreds of items to thousands of players, this difference is substantial. See understanding gas and fees for why transaction cost matters at scale.
Semi-fungibility
Semi-fungibility deserves a moment of attention. A concert ticket for seat C14 is fungible with another ticket for seat C14 (before the show), but it is not fungible with a ticket for seat D22. ERC-1155 can represent this naturally — 500 identical tokens sharing one ID, each interchangeable with the others, but distinct from tokens with a different ID.
This makes ERC-1155 the standard of choice for crypto gaming, digital trading cards, and any application that mixes large quantities of identical items with rarer unique ones.
How standards evolve
Ethereum’s token standards did not appear fully formed. ERC-20 was proposed in 2015 and formalised gradually as the ecosystem grew. ERC-721 emerged from early NFT experiments. ERC-1155 came later, shaped by hard-won lessons from deploying ERC-721 at scale.
Other networks have their own equivalent standards — often inspired by Ethereum’s but adapted for different virtual machines and fee structures. The concept, however, is universal: shared interfaces enable composability, and composability is what makes an open blockchain ecosystem more valuable than the sum of its parts.
It is also worth noting that standards can have gaps and vulnerabilities. Several significant exploits in DeFi history have involved edge cases in how token standards were implemented or extended. Standards provide a baseline of safety, not a guarantee of it.
Key takeaways
- Token standards are interface specifications that let contracts, wallets, and apps interact with tokens without custom integration per project.
- ERC-20 covers fungible tokens — every unit is identical, and the
approve/transferFrompattern enables DeFi composability. - ERC-721 covers non-fungible tokens — each has a unique ID and provable on-chain ownership, though media is usually stored off-chain.
- ERC-1155 covers multiple token types in a single contract, supporting fungible, non-fungible, and semi-fungible assets with efficient batch transfers.
- The
tokenURIin ERC-721 is a pointer, not the asset itself — NFT media can disappear if the hosting fails. - Standards evolve through community proposals; other blockchains have their own equivalents, but the composability principle is universal.
Next up: Stablecoins Explained