Section 01 · What an ERC Standard Is
ERC standards are interface contracts
An ERC standard is not code you download. It is a published agreement about which Solidity functions a contract must expose so that other code on chain can talk to it without surprises.
Quick answer
What is an ERC standard? An ERC (Ethereum Request for Comments) is a public specification that defines the function signatures, events, and behavior a smart contract must implement to be a particular kind of token or wallet. Any contract on Ethereum (or any EVM chain) can claim to implement an ERC standard. Wallets, exchanges, and other contracts then trust that claim and call the standardized functions, which is what makes interoperability possible.
The reason this matters is composition. A wallet that supports ERC20 can display the balance of any token on any EVM chain without anyone teaching it about that token specifically. A DEX that supports ERC20 can list a brand new token a few minutes after it is deployed. An auction contract that supports ERC721 can sell any NFT, from any project, without modification. The standards are what make Ethereum a programmable money network rather than a collection of incompatible silos. If you want a deployable starting point for either standard, the ERC-20 / ERC-721 Token Generator outputs OpenZeppelin based Solidity with the features you toggle.
The five standards in this guide cover most of what people interact with in 2026. ERC20 for fungible tokens, ERC721 for NFTs, ERC1155 for multi token contracts, ERC4626 for tokenized vaults, and ERC4337 for smart contract wallets. There are dozens of others (ERC2981 royalties, ERC777 advanced fungibles, ERC4884 metadata, ERC6900 modular accounts) but these five are the load bearing ones.
Section 02 · ERC20
The fungible token standard
ERC20 is the oldest and most used token standard on Ethereum. Every token where one unit is identical to every other unit is an ERC20.
Fungible means interchangeable. One USDC is exactly one USDC. One UNI is one UNI. The contract maintains a mapping from address to balance and exposes a small set of functions to read and move those balances.
totalSupply, balanceOf, transfer
totalSupply returns how many tokens exist in total. balanceOf reads the balance at any address. transfer moves tokens from your address to a recipient. These three functions plus a name, symbol, and decimals are enough for a wallet to display the token and for one user to send it to another.
approve, allowance, transferFrom
These three functions enable contracts to spend your tokens on your behalf. You call approve(spender, amount) to authorize a contract. The contract later calls transferFrom(you, recipient, amount) to actually move tokens. This is why every DEX and DeFi action starts with an Approve transaction before the real one. allowance(owner, spender) reads the remaining authorized amount.
Transfer and Approval events
Every successful transfer and approval emits an event with the from address, the to address, and the value. Wallets, indexers, and analytics platforms watch these events to update balance histories without having to read storage directly. The whole UX of seeing tokens land in your wallet is powered by these events.
The most common production examples in 2026 are USDC and USDT (stablecoins backed by reserves), DAI (a crypto collateralized stablecoin), UNI and AAVE (governance tokens), LINK (oracle service token), and the wrapped native tokens like WETH and WBTC that let ETH and BTC participate in DeFi protocols built around the ERC20 interface.
Section 03 · ERC721
NFTs and unique digital assets
ERC721 is the standard you use when each token is supposed to be one of a kind. Every token has a unique id and its own metadata.
Where ERC20 has a balance per address, ERC721 has an owner per token id. The contract's storage is a mapping from token id to owner. There is no notion of decimals or fractional balances. You either own token 47 or you do not.
Each token id is associated with a metadata URI through the tokenURI(uint256) function. The URI usually points to a JSON file (often on IPFS) that describes the token: name, image, attributes, animation. Marketplaces fetch this metadata to display the NFT visually. The image itself is not on chain in most cases, only its URL.
ownerOf, balanceOf, tokenURI
ownerOf(tokenId) returns who currently owns a specific token. balanceOf(owner) returns how many NFTs the address holds in this collection. tokenURI(tokenId) returns the metadata URL. These three calls are enough for any marketplace to display the NFT and verify the listing is real.
transferFrom, safeTransferFrom
transferFrom moves a token from one owner to another (assuming the caller is approved). safeTransferFrom adds a check that the recipient contract knows how to handle ERC721 tokens, preventing the common failure mode of NFTs being sent to a contract that has no way to move them again.
approve and setApprovalForAll
approve(spender, tokenId) authorizes one address to move one specific token. setApprovalForAll(operator, true) authorizes an operator (typically a marketplace contract) to move every token you own in this collection. The second is what marketplaces use, which is why a single approval is often enough to list an entire collection.
Production examples in 2026 include CryptoPunks and Bored Apes (the original profile picture collections), Art Blocks (generative art), ENS (human readable Ethereum names like vitalik.eth), Uniswap V3 LP positions (each liquidity position is an NFT), and a long tail of game items, certificates, tickets, and identity tokens.
Section 04 · ERC1155
One contract, many token types
ERC1155 lets a single contract host both fungible and non fungible tokens. It is the right choice when a project has many related tokens that should share infrastructure.
Where ERC20 stores one balance per address, and ERC721 stores one owner per token id, ERC1155 stores a balance per (address, token id) pair. Token id 1 might be 1,000,000 fungible gold coins. Token id 2 might be 10,000 fungible health potions. Token id 3 might be a single legendary sword. All in one contract.
The big practical wins are gas efficiency and batch operations. Instead of deploying one contract per item type (which would be ruinously expensive for a game with hundreds of asset types), the project deploys one contract and reads or writes many items per transaction. balanceOfBatch reads many balances at once. safeBatchTransferFrom moves many tokens at once.
When to choose ERC1155 over ERC20 or ERC721
If your project has dozens of asset types that share rules and live in the same economy, ERC1155 is right. Web3 games (Axie, Sky Mavis, Star Atlas), edition based art (Manifold, Foundation), in app currencies, batch issued tickets, and protocol level NFT systems with many sub assets all use it. If you only have one fungible token, stick to ERC20. If you only have unique assets and need broad marketplace support, stick to ERC721.
One small subtlety. ERC1155 uses safeTransferFrom rather than transferFrom by default, which means contracts that receive these tokens must implement the IERC1155Receiver interface or the transfer reverts. This is a deliberate safety check; it prevents the common ERC721 footgun of sending a token to a contract that has no way to ever move it again.
Section 05 · ERC4626
Tokenized vaults for DeFi
ERC4626 standardizes how a vault accepts an asset, gives the depositor a share, and lets them later redeem the share for the asset plus any yield.
Before ERC4626, every yield protocol invented its own deposit and withdraw interface. Aave called them aTokens, Compound called them cTokens, Yearn called them yvTokens, and each one behaved slightly differently. Aggregators that wanted to route capital across protocols had to write per protocol adapters and keep them in sync.
ERC4626 fixed this by defining a small interface: deposit, mint, withdraw, redeem, totalAssets, convertToShares, convertToAssets. Any vault that implements it looks the same to any caller. A user deposits USDC, receives shares that represent their stake, and redeems those shares later for USDC plus yield. The vault is free to do anything with the deposited capital between deposit and redemption.
deposit and mint
deposit(assets, receiver) takes a specific amount of the underlying asset and mints however many shares correspond to it at the current exchange rate. mint(shares, receiver) is the inverse: you say how many shares you want and the vault tells you how many assets that requires. Both are common entry points; pick whichever shape your application prefers.
withdraw and redeem
withdraw(assets, receiver, owner) burns enough shares to release a specific amount of assets. redeem(shares, receiver, owner) burns a specific amount of shares and releases whatever assets they correspond to. Vaults that earn yield will redeem more assets than were originally deposited, which is the depositor's profit.
totalAssets and conversions
totalAssets returns the vault's total holdings (including any yield earned but not yet realized). convertToShares and convertToAssets are pure read functions that let callers preview the rate before committing capital. Auto compounding strategies use them to compute the right number of shares to mint per deposit even as the underlying value drifts.
Examples in 2026 include Aave V4 lending pools (each pool is an ERC4626 vault), Yearn V3 strategies, Morpho Blue's optimized lending markets, and most new yield aggregators built since 2024. The standardization is also what made vault dashboards like DeFiLlama Vaults possible at all.
Section 06 · ERC4337
Account abstraction and smart wallets
ERC4337 is the most architecturally significant standard in this list. It lets the wallet itself be a smart contract, which unlocks gas sponsorship, social recovery, batch actions, and session keys.
Traditional Ethereum accounts are externally owned accounts (EOAs). They are controlled by a private key and have no on chain logic. They cannot enforce rules ("never spend more than 1,000 USDC per day"), they cannot recover from a lost key without a separate seed phrase, and they cannot pay gas in anything other than ETH. ERC4337 fixes all three.
Under ERC4337, the wallet is a smart contract you deploy once. Instead of signing a transaction, you sign a UserOperation: an intent that includes the calls you want to make, the gas you are willing to pay, and a signature that the wallet's own validation logic decides whether to accept. A bundler picks up your UserOperation and submits it as a regular transaction, which the EntryPoint contract dispatches to your wallet's executeUserOp function.
UserOperation
A pseudo transaction object that describes what the user wants to do. It carries the call data, the gas parameters, the nonce, the signature, and optional paymaster data. Crucially, it is not yet a real transaction. It needs a bundler to wrap it.
Bundler
An off chain service that watches a UserOperation mempool, validates submitted operations, and bundles many of them into one regular Ethereum transaction. The bundler pays the on chain gas in ETH and is reimbursed by the wallets it served. Bundlers compete on fees and reliability the way validators compete for transactions in the regular mempool.
EntryPoint contract
A single canonical contract deployed at the same address on every EVM chain. The bundler sends the bundled UserOperations to the EntryPoint, which dispatches each one to the right wallet contract for validation and execution. The EntryPoint also enforces gas refund accounting between bundlers, paymasters, and wallets.
Paymaster
An optional contract that pays for a UserOperation's gas instead of the wallet itself. This is how gas sponsorship works (a dApp pays for its users' first ten transactions) and how paying gas in tokens works (the paymaster accepts USDC from the user and reimburses the bundler in ETH).
What this enables in practice: a consumer app can let users sign up with email, get a smart wallet provisioned automatically, and pay zero gas for their first interactions. A treasury can require multiple signers for any transaction over a threshold. A game can issue session keys that let a player make moves for an hour without re signing each one. A user who loses their primary device can recover the wallet through trusted contacts. None of these are possible with a plain EOA.
Section 07 · Side by Side
How the five standards compare
A quick reference for picking the right standard when you are designing or integrating with a token.
| Standard | What it is | Typical use | Example |
|---|---|---|---|
| ERC20 | Fungible token | Stablecoins, governance, DeFi | USDC, UNI, AAVE |
| ERC721 | Unique token (NFT) | Art, collectibles, names | ENS, CryptoPunks |
| ERC1155 | Multi token contract | Games, editions, batch assets | Axie, Foundation |
| ERC4626 | Tokenized vault | DeFi yield, lending, strategies | Aave V4, Morpho |
| ERC4337 | Smart wallet account | Gas sponsorship, social recovery | Safe, Argent |
The standards layer cleanly. A typical 2026 application might use ERC4337 wallets for end users, hold ERC20 stablecoins, deposit them into an ERC4626 yield vault, and reward users with an ERC1155 collection of access passes. Each standard handles its piece without knowing about the others.
Section 08 · FAQ
Frequently asked questions
What is the difference between ERC and EIP?
An EIP (Ethereum Improvement Proposal) is the broad category of design proposals for the Ethereum protocol and ecosystem. ERC (Ethereum Request for Comments) is one track within EIPs, specifically for application level standards like tokens and wallet interfaces. So ERC20 is technically EIP 20, and the two names refer to the same document. Tokens are ERCs by convention; protocol changes (like EIP 1559 for fee markets) are EIPs.
Do ERC standards work on chains other than Ethereum?
Yes. Any EVM compatible chain can run the same contracts and so the same standards apply. Polygon, Arbitrum, Optimism, Base, BNB Chain, Avalanche C Chain, and most other EVM networks all support the full set of ERC standards. The contract you deploy on Ethereum mainnet works without modification on any of them, only at different gas costs.
Why are most stablecoins ERC20 and not something newer?
ERC20 is the most widely supported standard on every wallet, exchange, and DeFi protocol in existence. A stablecoin's value comes from how easy it is to use anywhere, and switching to a newer standard would mean rebuilding integrations across thousands of applications. The cost outweighs any technical benefit. The few exceptions (like USDC on Solana, which uses Solana's SPL Token standard) are deployed in addition to the ERC20 version, not as a replacement.
What does ERC4337 mean for normal users?
Better wallets. The user does not need to understand the standard. They will see apps that let them sign up with email, pay gas in stablecoins instead of ETH, recover access if they lose their phone, and sign once for a session of game moves. The complexity moves into the wallet contract; the user experience moves closer to a regular fintech app.
Can a contract implement multiple ERC standards at once?
Yes, and many do. A staking contract is often both an ERC20 (the share token) and an ERC4626 (the vault interface). A game inventory contract can be ERC1155 plus several extensions. The standards are interface contracts, not exclusive categories. As long as the function signatures do not conflict, a single contract can satisfy several at once.
Where do I read the actual ERC specifications?
On eips.ethereum.org. Every accepted ERC has a number, a title, an author list, and a full specification document. The most useful sections are usually the Specification (the exact function signatures) and the Rationale (why each design choice was made). Reference implementations are linked from the EIP itself, often pointing to OpenZeppelin's audited Solidity libraries which are what most production contracts inherit from.