ERC standards are shared blueprints that define how tokens interact with wallets, exchanges, and DeFi protocols on Ethereum. When a token follows an established standard like ERC-20 or ERC-721, any compatible application can instantly support it without custom integration. Standards are what make the Ethereum ecosystem composable: you can swap any ERC-20 token on Uniswap, list any ERC-721 NFT on OpenSea, and deposit any ERC-4626 vault into a yield aggregator. For investors, checking whether a project follows established standards is a basic due diligence step. Non-standard tokens are harder to audit, less composable, and carry higher risk.
What Are ERC Standards?
ERC stands for Ethereum Request for Comments, a formal process through which developers propose standards for the Ethereum ecosystem. The process begins when a developer submits an EIP (Ethereum Improvement Proposal) describing a new token interface or convention. If the community reaches consensus and the proposal is finalized, it becomes an ERC standard that other developers can adopt.
At their core, ERC standards define a set of functions and events that a smart contract must implement. Think of them as an API specification. Any contract that implements the required functions correctly can call itself an ERC-20 token, an ERC-721 NFT, or whatever standard it follows. The standard does not dictate the internal logic of the contract, only its external interface.
This standardization is what makes Ethereum's ecosystem work. Without ERC-20, every new token would need custom wallet integration, custom exchange listings, and custom DeFi protocol support. With ERC-20, a wallet simply calls balanceOf(address) to check your balance of any token, and transfer(address, amount) to send it. One interface, thousands of tokens. This interoperability is Ethereum's most important property and the primary reason why the ERC system matters.
The numbering of ERC standards corresponds to the EIP number. ERC-20 was the 20th Ethereum Improvement Proposal. ERC-721 was the 721st. The numbers are not sequential in terms of importance or adoption; they simply reflect when the proposal was submitted.
ERC-20: Fungible Tokens
ERC-20, proposed by Fabian Vogelsteller in November 2015, is the foundational token standard on Ethereum and by far the most widely adopted. Every unit of an ERC-20 token is identical and interchangeable with every other unit, just like dollars or shares of stock. This property is called fungibility.
Core Functions
The ERC-20 standard requires six functions and two events:
| Function | Purpose |
|---|---|
| totalSupply() | Returns the total number of tokens in existence |
| balanceOf(address) | Returns the token balance of a specific address |
| transfer(to, amount) | Sends tokens from the caller to another address |
| approve(spender, amount) | Grants permission for another address to spend your tokens |
| allowance(owner, spender) | Returns the remaining approved spending amount |
| transferFrom(from, to, amount) | Transfers tokens using an existing approval (used by DeFi protocols) |
The approve and transferFrom pattern is what enables DeFi composability. When you use Uniswap, you first approve the Uniswap router contract to spend your tokens, then Uniswap calls transferFrom to pull the tokens during a swap. This two-step pattern is used by virtually every DeFi protocol.
Prominent ERC-20 Tokens
Thousands of tokens follow the ERC-20 standard. Among the most significant are USDC and USDT (stablecoins), WETH (wrapped Ether, since native ETH predates ERC-20), UNI (Uniswap governance), LINK (Chainlink oracle network), AAVE (Aave lending protocol), and DAI (MakerDAO's decentralized stablecoin). Even wrapped versions of non-Ethereum assets like WBTC (wrapped Bitcoin) follow ERC-20 on Ethereum.
Known Limitations
- No native ETH support: Native Ether does not conform to ERC-20. This is why WETH (Wrapped ETH) exists: it wraps native ETH into an ERC-20 compatible format. Many newer token standards and protocols have attempted to address this awkwardness.
- Approval front-running risk: The
approvefunction has a known race condition. If you change an approval from 100 to 50, a malicious spender could front-run the transaction and spend both the original 100 and the new 50. The recommended mitigation is to set the approval to zero before setting a new value. - Lost tokens: If you send ERC-20 tokens directly to a contract that does not handle them, the tokens are permanently locked. There is no built-in mechanism to reject incoming tokens, unlike ERC-721 which has a safe transfer function.
ERC-721: Non-Fungible Tokens (NFTs)
ERC-721, finalized in January 2018, introduced the concept of non-fungible tokens to Ethereum. Unlike ERC-20 where every token is identical, each ERC-721 token has a unique token ID that distinguishes it from every other token in the same contract. This uniqueness makes ERC-721 suitable for representing ownership of distinct items: digital art, collectibles, domain names, real estate records, or membership passes.
Core Functions
| Function | Purpose |
|---|---|
| ownerOf(tokenId) | Returns the current owner of a specific NFT |
| transferFrom(from, to, tokenId) | Transfers ownership of a specific NFT |
| safeTransferFrom(from, to, tokenId) | Same as transfer but checks that the recipient can handle NFTs |
| approve(to, tokenId) | Approves another address to transfer a specific NFT |
| setApprovalForAll(operator, bool) | Approves an operator to manage all of the caller's NFTs |
| tokenURI(tokenId) | Returns a URL pointing to the token's metadata (name, image, attributes) |
The safeTransferFrom function is an important improvement over ERC-20. It checks whether the receiving contract implements the onERC721Received callback, preventing tokens from being permanently locked in contracts that cannot handle them. This is why you sometimes see failed NFT transfers when sending to incompatible contracts.
Metadata and Token URI
The tokenURI function is how NFTs link to their visual and descriptive content. It returns a URL (often an IPFS link) pointing to a JSON file containing the token's name, description, image URL, and attributes. This metadata standard enables marketplaces like OpenSea to display NFT images and properties without needing custom integration for each collection. The metadata itself is not stored on-chain (it would be too expensive), only the URI pointing to it.
Notable ERC-721 Collections
Historically significant ERC-721 projects include CryptoPunks (which actually predates the standard and was later wrapped to conform), Bored Ape Yacht Club, Art Blocks generative art, ENS (Ethereum Name Service) domains, and Pudgy Penguins. ENS is a particularly interesting case: your .eth domain name is an NFT that you own, transfer, and trade like any other ERC-721 token.
ERC-1155: Multi-Token Standard
ERC-1155, created by Enjin and finalized in 2019, combines the capabilities of ERC-20 and ERC-721 into a single contract. A single ERC-1155 contract can manage multiple token types simultaneously: some fungible (like in-game currencies), some non-fungible (like unique items), and some semi-fungible (limited edition items with multiple copies).
Key Advantages
- Gas efficiency: Instead of deploying separate ERC-20 and ERC-721 contracts, one ERC-1155 contract handles everything. Batch operations allow transferring multiple token types in a single transaction, saving significant gas costs. A game that needs gold coins (fungible), unique legendary swords (non-fungible), and limited-edition armor sets (semi-fungible) can manage all of these in one contract.
- Batch transfers: The
safeBatchTransferFromfunction allows transferring multiple token IDs and amounts in a single transaction. This is dramatically more efficient than making individual ERC-20 or ERC-721 transfers for each item. - Atomic swaps: Trading multiple items between players can happen atomically in one transaction, reducing the risk of one party defaulting mid-trade.
Use Cases
ERC-1155 is particularly popular in gaming and metaverse applications. A game like Skyweaver or Gods Unchained can represent all of its cards, currencies, and items in a single contract. Each card type has its own token ID, and the supply of each ID can be set independently (one-of-one legendaries vs thousands of commons).
Beyond gaming, ERC-1155 is used for event tickets (multiple ticket tiers in one contract), loyalty rewards programs, and any scenario where an application needs to manage a diverse set of token types efficiently. The Gridlock March Madness project, for example, uses ERC-1155 for team cards where each of the 68 teams has its own token ID with configurable supply.
Use ERC-20 when every token is identical (currencies, governance tokens, utility tokens). Use ERC-721 when every token is unique and you want rich per-item metadata (art, PFPs, domain names). Use ERC-1155 when you need multiple token types in one contract (games, marketplaces) or want gas-efficient batch operations.
ERC-4626: Tokenized Vaults
ERC-4626, finalized in 2022, standardizes yield-bearing vaults on Ethereum. Before ERC-4626, every lending protocol, yield aggregator, and staking contract had its own deposit/withdraw interface. Integrating with Aave required different code than integrating with Yearn, which was different from Compound. ERC-4626 created a universal interface for any vault that accepts deposits and generates yield.
Core Functions
| Function | Purpose |
|---|---|
| deposit(assets, receiver) | Deposit underlying assets and receive vault shares |
| withdraw(assets, receiver, owner) | Withdraw a specific amount of underlying assets |
| redeem(shares, receiver, owner) | Redeem vault shares for underlying assets |
| convertToShares(assets) | Preview how many shares you would receive for a deposit |
| convertToAssets(shares) | Preview how many assets your shares are worth |
| totalAssets() | Returns total assets managed by the vault |
Why ERC-4626 Matters
The power of ERC-4626 is composability. Once a vault implements this standard, it can be integrated into any protocol that understands ERC-4626 without custom code. A yield aggregator can automatically support hundreds of vaults. A lending protocol can accept any ERC-4626 vault share as collateral. A portfolio tracker can display the value of any ERC-4626 position using the same logic.
Major protocols that have adopted ERC-4626 include Yearn V3, Morpho, Maple Finance, Balancer, and Aave V3 (via wrapper contracts). The standard has become the default interface for new yield-bearing products on Ethereum and is spreading to other EVM chains. For investors, checking whether a vault follows ERC-4626 is an indicator of design quality and integration potential. Vaults that implement the standard are easier to audit, easier to compose with other protocols, and more likely to receive broad ecosystem support.
Other Notable Standards
Beyond the four major standards, several newer ERCs address specific use cases and improve upon existing patterns.
ERC-2612: Permit (Gasless Approvals)
ERC-2612 adds a permit function to ERC-20 tokens that allows approvals via signed messages instead of on-chain transactions. Instead of sending a separate approval transaction (which costs gas), users sign an off-chain message granting permission. The spender includes this signature with the actual transfer transaction, combining approval and execution into one step. This saves users gas and improves UX. Tokens like USDC, DAI, and most modern ERC-20 tokens support ERC-2612 permits.
ERC-3643: Security Tokens
ERC-3643 (formerly T-REX) is a standard for regulated security tokens that includes built-in compliance checks. Transfer restrictions can enforce investor accreditation requirements, jurisdictional limits, holding periods, and maximum holder counts. Identity verification is handled through on-chain identity registries. This standard is used by tokenized real-world assets, regulated fund shares, and compliant security offerings. It bridges the gap between DeFi composability and regulatory requirements.
ERC-6551: Token-Bound Accounts
ERC-6551 turns NFTs into smart contract wallets. Each ERC-721 token can have its own Ethereum account (a smart contract wallet) that can hold ETH, ERC-20 tokens, and other NFTs. This means an NFT character in a game can own its own inventory of items and currency. When you transfer the NFT, all of its owned assets transfer with it. This standard enables deeply nested ownership hierarchies and dramatically expands what NFTs can represent.
ERC-7621: Basket Tokens
ERC-7621 defines a standard for tokens that represent baskets of underlying assets, similar to index funds or ETFs in traditional finance. A single ERC-7621 token could represent a weighted basket of DeFi governance tokens, a diversified crypto index, or a curated portfolio. The standard includes functions for rebalancing, fee collection, and transparent composition tracking, making on-chain index products more standardized and interoperable.
The ERC process is continuous. New standards are proposed regularly to address emerging needs. Account abstraction (ERC-4337), intent-based execution, and cross-chain token standards are active areas of development. The best way to stay current is to follow the Ethereum Magicians forum and EIP repository where proposals are discussed and refined before finalization.
Why Standards Matter for Investors
Understanding token standards is not just a technical exercise. It has direct implications for evaluating projects and managing risk in crypto portfolios.
Composability Means Utility
A token that follows ERC-20 can be listed on any DEX, used as collateral in any lending protocol, bridged to any L2, and tracked by any portfolio tool from day one. A non-standard token needs custom integration for each of these, which means fewer venues, less liquidity, and slower adoption. When evaluating a new project, checking whether its token follows established standards is a quick signal of whether the team understands Ethereum ecosystem conventions.
Auditability and Security
Standard implementations have been thoroughly audited and battle-tested. Libraries like OpenZeppelin provide reference implementations of ERC-20, ERC-721, ERC-1155, and ERC-4626 that have been used by thousands of projects and reviewed by dozens of auditing firms. When a project uses a standard implementation, its token contract inherits the security properties of that well-tested codebase. When a project writes custom token logic, it introduces novel attack surface that may not have been as rigorously examined.
Red Flags to Watch For
- Non-standard transfer functions: Tokens that add taxes, fees, or rebasing logic to the transfer function can break compatibility with DEXes and DeFi protocols. These "deflationary" or "elastic supply" tokens often cause failed transactions and locked funds.
- Missing standard functions: A token claiming to be ERC-20 but missing the
approve/transferFrompattern cannot be used in DeFi. Always verify the contract actually implements the full standard. - Proxy patterns without transparency: Upgradeable tokens using proxy contracts can have their logic changed by the admin. While this is sometimes legitimate, it means the token's behavior can change after you buy it. Check whether the proxy admin is a multisig, a timelock, or a single EOA.
- Custom approval mechanisms: Tokens that require special approval flows or have unusual permission models may trap your funds in contracts that expect standard behavior.
Do not assume a token follows a standard just because the project claims it does. Check the verified source code on Etherscan. Look for the standard's required functions. Verify that the contract uses a reputable implementation library like OpenZeppelin. If the source code is not verified or the contract contains unusual modifiers on standard functions (like transfer fees or blacklists), proceed with extra caution.
Key Takeaways
- ERC standards are shared interfaces that define how tokens interact with wallets, exchanges, and protocols on Ethereum
- ERC-20 is the fungible token standard used by USDC, UNI, LINK, and thousands of other tokens; every unit is identical
- ERC-721 is the NFT standard where each token has a unique ID; used for digital art, ENS domains, and collectibles
- ERC-1155 combines fungible and non-fungible tokens in one contract with efficient batch operations; ideal for games
- ERC-4626 standardizes yield-bearing vaults, enabling composability across lending, yield, and portfolio protocols
- ERC-2612 (permit) enables gasless approvals via signed messages, improving UX and reducing costs
- ERC-6551 gives NFTs their own smart contract wallets, allowing them to own assets
- Standard compliance is a due diligence signal: tokens following established ERCs are more auditable, composable, and broadly supported than non-standard tokens