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 seven 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, ERC1400 for security tokens, ERC4626 for tokenized vaults, ERC4337 for smart contract wallets, and ERC6551 for token bound accounts. There are dozens of others (ERC2981 royalties, ERC777 advanced fungibles, ERC4884 metadata, ERC6900 modular accounts) but these seven 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 · ERC1400
ERC1400: the security token standard
ERC1400 is the interface standard for security tokens — tokenized equities, bonds, real estate, and other regulated financial instruments that carry legal restrictions on who can hold them and when they can be transferred.
A plain ERC20 token transfers freely to any address with no restrictions. A security token cannot. Investor accreditation requirements, KYC and AML checks, holding period lockups, and jurisdiction based restrictions all need to be enforced at the contract level — not as off chain policies that can be bypassed. ERC1400 provides the interface architecture for these controls.
canTransfer and transferByPartition
The canTransfer function checks whether a proposed transfer is permissible before it executes. The contract returns a reason code if the transfer is blocked — investor not KYC verified, holding period not met, recipient jurisdiction not allowed. transferByPartition extends this to partition based transfers: within a security token, different partitions represent different classes of shares or tranches of a debt instrument, each with their own transfer rules.
Forced transfers by authorized controllers
Security regulations sometimes require a token issuer to forcibly transfer or redeem tokens — for court orders, regulatory enforcement, or error corrections. ERC1400 specifies the operatorTransferByPartition function for this purpose. Controllers are addresses the issuer designates with the ability to move tokens regardless of holder consent. This is deliberately unlike ERC20, where no one can move your tokens without your approval.
Issuance and redemption
ERC1400 includes issuance functions (issue, issueByPartition) for minting new security tokens during a fundraise and redemption functions (redeem, redeemByPartition) for burning them at maturity or buyback. Every issuance and redemption emits events that provide a clear audit trail for regulators.
Where ERC1400 is used in production
Tokenized real estate platforms (RealT, Lofty) use ERC1400 or closely related security token standards to restrict transfers to accredited investors. Tokenized US Treasury products (Ondo Finance, Franklin Templeton) use partition based structures for different share classes. Corporate debt tokenization projects at Société Générale and ABN AMRO rely on ERC1400 compatible security token frameworks. Most implementations are ERC1400 derived rather than strict reference implementations — the standard is adopted as an architectural pattern, not a byte-for-byte spec.
The highest search volume for ERC1400 in 2026 is around the specification and documentation: "ERC-1400 security token standard overview" (590 monthly searches, KD 17) and "ERC-1400 security token standard documentation" (480 searches, KD 12). Developers building tokenized securities infrastructure are looking for a practical guide to the standard, not just the EIP text.
Section 06 · 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 07 · 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 08 · ERC6551
ERC6551: token bound accounts — NFTs that own assets
ERC6551 gives any ERC721 NFT its own smart contract wallet. The NFT can accumulate tokens, execute transactions, and interact with protocols — and everything it owns transfers automatically when the NFT changes hands.
The core problem ERC6551 solves: in a standard ERC721 collection, the NFT represents ownership but the NFT itself cannot own anything. If a game character earns a sword, the sword lives in the player's wallet — not in the character's wallet. When the player sells the character NFT, the sword stays behind. ERC6551 fixes this by giving each NFT a deterministic smart contract wallet address computed from the NFT's contract address and token ID.
Registry contract and deterministic addresses
The ERC6551 registry is a singleton contract deployed at the same address on every EVM chain. Any application can compute the wallet address for any NFT without reading from the registry at all — the address is derived from the token contract address, the token ID, the chain ID, and the implementation contract address via CREATE2. This determinism means the wallet exists logically from the moment the NFT is minted, even before any assets are deposited.
Ownership follows the NFT
The token bound account owner is always the current owner of the NFT. When the NFT is transferred, control of the wallet transfers automatically. The new NFT holder immediately controls all assets in the bound account. There is no separate step to transfer wallet ownership, no admin override, and no possibility of the wallet and NFT ownership falling out of sync.
Execution and nested ownership
The token bound account implements a standard execute function that lets the NFT owner call any contract, send ETH, or batch multiple actions. Nested token bound accounts are possible — an NFT that owns another NFT automatically controls that second NFT's wallet too, enabling hierarchical ownership structures for things like game item sets and portfolio collections.
ERC6551 use cases in production and development
Web3 games are the primary early adopter: game characters that accumulate loot, pets that earn experience, vehicles that collect upgrades — all owned by the character NFT and portable across any platform that reads on chain state. Identity use cases are emerging: an identity NFT whose bound account holds verifiable credentials, certifications, and attestations that follow the holder. DeFi applications include NFT portfolios whose bound accounts hold positions, automatically transferring an entire investment portfolio when the portfolio NFT changes hands. The highest search intent for ERC6551 in 2026 is around the specification: 'erc-6551 token bound accounts standard' (210 monthly searches, KD 6) and 'erc-6551 token bound accounts specification' (70 searches, KD 0).
Section 09 · Side by Side
How the seven 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 |
| ERC1400 | Security token | Tokenized equities, bonds, real estate | Ondo Finance, RealT |
| ERC4626 | Tokenized vault | DeFi yield, lending, strategies | Aave V4, Morpho |
| ERC4337 | Smart wallet account | Gas sponsorship, social recovery | Safe, Argent |
| ERC6551 | Token bound account | Game inventories, portable identity | Tokenbound, Stapleverse |
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, reward users with an ERC1155 collection of access passes, and represent game characters as ERC721 NFTs with ERC6551 wallets that hold the character's earned items. Each standard handles its piece without knowing about the others.
Section 10 · 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.
What is the ERC1400 security token standard?
ERC1400 is the Ethereum standard for security tokens — tokenized equities, bonds, real estate, and other regulated financial instruments. Unlike ERC20, which transfers freely to any address, ERC1400 adds partition-based transfer restrictions, KYC and accreditation checks via canTransfer, forced transfers by authorized controllers for regulatory compliance, and explicit issuance and redemption functions. It is the interface standard most tokenized securities platforms build on, even when they adapt or extend it rather than implementing it verbatim.
What is ERC6551 and what are token bound accounts?
ERC6551 is the standard for token bound accounts — a mechanism that gives any ERC721 NFT its own smart contract wallet. The wallet address is computed deterministically from the NFT's contract address, token ID, and chain ID, so any application can derive it without registry lookups. The NFT's current owner controls the wallet. When the NFT transfers, wallet control transfers automatically. Token bound accounts enable game characters that own their own inventory, NFT portfolios that hold positions, and portable digital identity where credentials follow the holder rather than the wallet address.