ERC-20 vs ERC-721 vs ERC-1155: Which Token Standard Do You Need?
ERC-20 vs ERC-721 vs ERC-1155: if you are building anything on Ethereum in 2026, you will encounter all three token standards. Each solves a different problem. Choosing the wrong one does not just waste gas — it means building on a foundation that does not fit your use case, and refactoring a deployed token contract is not possible. This guide explains exactly what each standard does, where each fits, and how to choose between them with confidence.
The Three Ethereum Token Standards at a Glance
Ethereum does not have one token standard — it has a family of them. The three most important are ERC-20, ERC-721, and ERC-1155. Each was designed for a distinct category of digital asset, and each has become the foundation of a multi-billion-dollar ecosystem.
| Standard | Type | Proposed | Primary Use | Key Property |
|---|---|---|---|---|
| ERC-20 | Fungible | 2015 (EIP-20) | Currencies, DeFi, governance | Every token is identical |
| ERC-721 | Non-fungible | 2018 (EIP-721) | NFTs, collectibles, art | Every token is unique |
| ERC-1155 | Multi-token | 2018 (EIP-1155) | Gaming, mixed asset platforms | Fungible and non-fungible in one |
Understanding the distinction between these three standards is the most important architectural decision you will make before writing a single line of Solidity. Let us look at each one in depth.
ERC-20: The Fungible Token Standard
ERC-20 is the bedrock of the Ethereum token economy. Proposed by Fabian Vogelsteller and Vitalik Buterin in 2015, it defines a common interface that every fungible token on Ethereum implements. "Fungible" means each token unit is identical and interchangeable — one USDC is exactly equal to any other USDC, just as one US dollar bill is interchangeable with any other US dollar bill.
The Six Mandatory Functions
Every ERC-20 contract must implement six standard functions:
- totalSupply() — Returns the total number of tokens in existence.
- balanceOf(address account) — Returns the token balance of a given address.
- transfer(address to, uint256 amount) — Transfers tokens from the caller to another address.
- allowance(address owner, address spender) — Returns how many tokens a spender is approved to use on the owner's behalf.
- approve(address spender, uint256 amount) — Approves a spender to use up to a specified amount of the caller's tokens.
- transferFrom(address from, address to, uint256 amount) — Transfers tokens on behalf of an approved owner.
The Two Standard Events
ERC-20 contracts emit two events that indexers, explorers, and DeFi protocols rely on:
- Transfer(address indexed from, address indexed to, uint256 value) — Emitted on every token transfer, including minting (from zero address) and burning (to zero address).
- Approval(address indexed owner, address indexed spender, uint256 value) — Emitted when an approval is set.
ERC-20 Use Cases
The range of ERC-20 applications is enormous. The standard powers:
- Stablecoins — USDC, USDT, DAI, and FRAX are all ERC-20 tokens.
- Governance tokens — UNI, AAVE, COMP, and MKR let holders vote on protocol changes.
- DeFi utility tokens — LINK, GRT, and BAL fuel decentralized service networks.
- Staking and reward tokens — Protocols distribute staking yields as ERC-20 tokens.
- Loyalty and points programs — Any system that needs a transferable, programmable point unit.
- ICO/IDO tokens — The vast majority of fundraising tokens are ERC-20.
If you want to create an ERC-20 token, the process is straightforward: define a name, symbol, supply, and decimals, then deploy a contract that implements the six functions above. The most robust way to do this is with OpenZeppelin's ERC-20 implementation, which has been audited by leading security firms and battle-tested across thousands of deployments.
ERC-721: The Non-Fungible Token Standard
ERC-721 introduced the concept of non-fungible tokens (NFTs) to Ethereum. Authored by William Entriken, Dieter Shirley, Jacob Evans, and Nastassia Sachs, the standard was finalized in January 2018. It defines a token where every unit is unique and distinguishable from every other unit.
The critical difference from ERC-20: instead of tracking a balance for each address, ERC-721 tracks ownership of individual token IDs. Token ID #1 is a completely different asset from token ID #2, even if they live in the same contract.
Core ERC-721 Interface Functions
- ownerOf(uint256 tokenId) — Returns the address that owns a specific token.
- balanceOf(address owner) — Returns how many tokens an address owns (count, not value).
- transferFrom(address from, address to, uint256 tokenId) — Transfers ownership of a specific token.
- safeTransferFrom(address from, address to, uint256 tokenId) — Transfers with a receiver check to prevent accidental loss.
- approve(address to, uint256 tokenId) — Approves an address to transfer a specific token.
- setApprovalForAll(address operator, bool approved) — Approves an operator to manage all of the caller's tokens.
- tokenURI(uint256 tokenId) — Returns a URI pointing to off-chain metadata for the token (JSON with name, description, image).
Metadata and the tokenURI Pattern
ERC-721 tokens derive their value largely from their metadata. The tokenURI function returns a URL (often an IPFS or Arweave link) pointing to a JSON file that contains the token's name, description, image, and attributes. Marketplaces like OpenSea, Blur, and LooksRare read this metadata to display NFTs to buyers.
The metadata standard (not part of the core EIP but universally adopted) looks like:
{
"name": "Bored Ape #1234",
"description": "A unique Bored Ape from the Yacht Club collection.",
"image": "ipfs://Qm.../1234.png",
"attributes": [
{ "trait_type": "Background", "value": "Army Green" },
{ "trait_type": "Fur", "value": "Golden Brown" }
]
}
ERC-721 Use Cases
- Digital art and collectibles — CryptoPunks, Bored Ape Yacht Club, Art Blocks generative art.
- Gaming items — Unique swords, characters, or land parcels where rarity matters.
- Real estate tokenization — Each property token represents a distinct, unique asset.
- Domain names — ENS domains (.eth) are ERC-721 tokens, each representing a unique name.
- Event tickets — Each ticket is unique (different seat, different event, different date).
- Certificates and credentials — Diplomas, badges, or proof-of-attendance tokens where uniqueness matters.
ERC-1155: The Multi-Token Standard
ERC-1155 was designed by Witek Radomski, Andrew Cooke, Philippe Castonguay, James Therien, and Eric Binet at Enjin, and finalized in June 2019. It solves a problem neither ERC-20 nor ERC-721 addresses on their own: what if you need both fungible and non-fungible tokens in the same application?
In a blockchain game, players might hold gold coins (fungible — one gold is worth one gold), health potions (fungible — each potion is identical), and a legendary sword (non-fungible — one specific sword with specific attributes). ERC-1155 lets all of these live in a single contract, dramatically reducing deployment costs and operational complexity.
How ERC-1155 Works
Instead of mapping addresses to balances (ERC-20) or token IDs to owners (ERC-721), ERC-1155 uses a nested mapping: mapping(uint256 => mapping(address => uint256)). This maps a token ID to an address, then to a balance. A token ID with a max supply of 1 behaves like an NFT. A token ID with a supply of 1,000,000 behaves like a fungible token.
The Batch Transfer Advantage
ERC-1155's most powerful feature is batch operations. The safeBatchTransferFrom function lets you transfer multiple token IDs in a single transaction:
safeBatchTransferFrom(
address from,
address to,
uint256[] calldata ids,
uint256[] calldata amounts,
bytes calldata data
)
Sending 10 different item types to a player in one transaction (instead of 10 separate transactions) reduces gas costs by 60-80% for batch operations. This is transformative for games and platforms with high transaction volume.
ERC-1155 Use Cases
- Blockchain gaming — The dominant standard for games with mixed asset types (currency + items + characters).
- Digital trading cards — Semi-fungible: multiple copies of common cards, single copies of rares.
- Platform storefronts — OpenSea's Shared Storefront contract is ERC-1155.
- Supply chain tracking — Batches of identical items alongside unique serial-numbered items.
- Reward systems with tiers — Multiple fungible reward token types plus unique achievement badges in one contract.
Key Technical Differences
Fungibility Model
The fundamental technical difference is how each standard models ownership:
- ERC-20 —
mapping(address => uint256) balances. An address holds an amount. No individual token has an identity. - ERC-721 —
mapping(uint256 => address) owners. A token ID has exactly one owner. The token has an identity. - ERC-1155 —
mapping(uint256 => mapping(address => uint256)) balances. A token ID maps to an address, which maps to a quantity.
Transfer Function Signatures
| Standard | Transfer Function | Batch Support |
|---|---|---|
| ERC-20 | transfer(to, amount) |
No (requires loops) |
| ERC-721 | transferFrom(from, to, tokenId) |
No (one token at a time) |
| ERC-1155 | safeTransferFrom(from, to, id, amount, data) |
Yes — safeBatchTransferFrom |
Metadata Handling
ERC-20 has no built-in metadata standard (name and symbol are optional but universally implemented). ERC-721 defines tokenURI(uint256 tokenId) — a per-token metadata URI. ERC-1155 defines uri(uint256 id), which can use a template with {id} substitution, making it possible to serve all token metadata from a single URI pattern like https://api.example.com/token/{id}.json.
Receiver Interface Requirements
ERC-721 and ERC-1155 require recipient smart contracts to implement receiver interfaces (IERC721Receiver and IERC1155Receiver respectively) to accept safe transfers. ERC-20 has no such requirement, which has historically led to tokens being permanently lost in contracts that did not expect to receive them.
Gas Cost Comparison
Gas costs vary with network congestion, but the relative differences between standards are consistent. Here are representative figures based on Ethereum Mainnet activity:
| Operation | ERC-20 | ERC-721 | ERC-1155 |
|---|---|---|---|
| Contract deployment | ~800,000 gas | ~2,500,000 gas | ~2,000,000 gas |
| Single transfer | ~21,000-65,000 gas | ~85,000-150,000 gas | ~55,000-100,000 gas |
| Batch transfer (10 items) | ~650,000 gas (10 txns) | ~1,000,000 gas (10 txns) | ~120,000 gas (1 txn) |
| Mint (single) | ~45,000 gas | ~100,000-150,000 gas | ~55,000-80,000 gas |
Key takeaways: ERC-20 is the cheapest to deploy and cheapest for individual transfers. ERC-1155 wins dramatically for batch operations. ERC-721 carries the highest per-operation cost due to the complexity of tracking individual ownership records.
For projects sensitive to deployment cost, understanding the full picture of ERC-20 token creation costs helps set realistic budget expectations.
Which Token Standard for Which Use Case?
Choose ERC-20 When
- You are building a currency, stablecoin, or payment token.
- You need DeFi compatibility — Uniswap, Aave, Compound, Curve, and nearly every DeFi protocol works exclusively with ERC-20.
- You are launching a governance token for a DAO or protocol.
- You need staking mechanics where token amounts (not specific token IDs) matter.
- You are running an ICO, IDO, or token sale.
- You want your token listed on centralized or decentralized exchanges.
- You are building a loyalty points or reward program.
Choose ERC-721 When
- Every asset you are tokenizing is unique and distinguishable.
- You are building a digital art or collectibles platform.
- You need per-token metadata (individual traits, attributes, provenance).
- You want maximum marketplace compatibility — OpenSea, Blur, and other major platforms have first-class ERC-721 support.
- You are tokenizing real-world assets where each item has a distinct identity (property deeds, vehicle titles).
- You are building a ticketing system with unique seat assignments.
Choose ERC-1155 When
- Your application needs both fungible and non-fungible tokens.
- You are building a game with currency, consumables, and unique items.
- You need frequent batch transfers and want to minimize gas costs at scale.
- You want to manage multiple token types under a single contract address.
- You are building a digital trading card system (multiple copies of common cards, single copies of legendaries).
- You want semi-fungible tokens — limited-edition items where multiple identical copies exist but the supply is capped.
Full Comparison Table: ERC-20 vs ERC-721 vs ERC-1155
| Feature | ERC-20 | ERC-721 | ERC-1155 |
|---|---|---|---|
| Fungibility | Fully fungible | Non-fungible (each unique) | Both (per token ID) |
| Token identity | No individual identity | Unique token ID per item | Token ID + quantity |
| Deployment gas | Low (~800K) | High (~2.5M) | Medium (~2M) |
| Transfer gas | Lowest | Highest | Medium (single), Lowest (batch) |
| Batch transfers | No | No | Yes (native) |
| Per-token metadata | No | Yes (tokenURI) | Yes (uri with {id}) |
| DeFi support | Universal | Very limited | Limited |
| NFT marketplace support | None | Universal | Good (OpenSea, Rarible) |
| Uniswap compatible | Yes | No | No |
| OpenZeppelin support | Yes | Yes | Yes |
| EIP finalized | 2015 | 2018 | 2019 |
| Primary use case | DeFi, currencies, governance | Art, collectibles, real estate | Gaming, mixed-asset platforms |
Real-World Examples of Each Standard
ERC-20 in Production
The ERC-20 standard powers some of the largest tokens by market capitalization on Ethereum:
- USDC (USD Coin) — Circle's stablecoin, pegged to the US dollar, processing billions in daily volume as an ERC-20 token.
- UNI (Uniswap) — The governance token of the world's largest DEX, allowing holders to vote on protocol upgrades.
- LINK (Chainlink) — The utility token for Chainlink's oracle network, used to pay node operators for real-world data feeds.
- SHIB (Shiba Inu) — A meme token with a community of millions, demonstrating ERC-20's flexibility.
- AAVE — The governance and staking token for the Aave lending protocol.
Each of these tokens benefits from the full ERC-20 ecosystem: Uniswap pools, Aave collateral, Etherscan tracking, and exchange listings. This is the power of a universal standard.
ERC-721 in Production
- CryptoPunks — One of the earliest NFT projects (originally pre-ERC-721, later migrated), 10,000 unique pixel characters with floor prices in the hundreds of ETH.
- Bored Ape Yacht Club (BAYC) — 10,000 unique generated ape images, each with distinct trait combinations stored as ERC-721 token metadata.
- ENS Domains — Ethereum Name Service domains (e.g., vitalik.eth) are ERC-721 tokens, each representing a unique human-readable name.
- Art Blocks — Generative art platform where each token is a unique algorithm-generated artwork, stored entirely on-chain.
ERC-1155 in Production
- Enjin Multiverse — The team that invented ERC-1155 uses it across their gaming ecosystem, where game items can be traded between different games.
- OpenSea Shared Storefront — OpenSea's own minting contract uses ERC-1155, allowing creators to mint without deploying individual contracts.
- Rarible Protocol — Uses ERC-1155 for its creator tools, supporting editions (multiple copies of the same artwork).
- Gods Unchained — A blockchain trading card game where cards use ERC-1155, with multiple copies of common cards and single copies of legendaries.
DeFi and Marketplace Compatibility
One of the most practically important distinctions between the three standards is ecosystem compatibility. This is not a minor technical detail — it determines where your token can be used on day one after launch.
DeFi Protocols: ERC-20 Only
The entire DeFi stack is built on ERC-20:
- Uniswap V2 and V3 — Only supports ERC-20/ERC-20 pairs. There is no mechanism for listing an ERC-721 or ERC-1155 token on Uniswap directly. See our guide on listing an ERC-20 token on Uniswap for the step-by-step process.
- Aave and Compound — Lending and borrowing is ERC-20 only. NFT lending protocols exist but are entirely separate infrastructure.
- Curve Finance — Stablecoin AMM, ERC-20 only.
- MakerDAO — Collateral assets are ERC-20 tokens.
- Yearn Finance — Yield vaults accept ERC-20 tokens.
If you want your token to be swappable on DEXes, eligible as lending collateral, or usable in any yield strategy, you need ERC-20. There is no workaround.
NFT Marketplaces: ERC-721 and ERC-1155
The major NFT marketplaces support both non-fungible standards, though ERC-721 typically has deeper integration:
- OpenSea — Full support for both ERC-721 and ERC-1155. Largest NFT marketplace by volume.
- Blur — Primarily ERC-721 focused, the dominant marketplace for high-value NFT trading.
- Rarible — Supports both standards, with strong ERC-1155 edition support.
- Foundation — Exclusively ERC-721, focused on 1-of-1 digital art.
Verifying Your Contract
Regardless of which standard you choose, verifying your contract on Etherscan builds trust with users and investors. Our guide to Etherscan contract verification walks through the complete process. For ERC-20 tokens deployed through our platform, verification happens automatically.
For projects thinking about tokenomics design — how to structure your ERC-20 supply, vesting, and distribution — our ERC-20 tokenomics guide covers the full decision framework used by successful token projects.
Ready to launch your ERC-20 token?
Use our platform to create an ERC-20 token online in minutes. OpenZeppelin contracts, automatic Etherscan verification, 0.02 ETH flat fee.
Launch Your Token →Frequently Asked Questions
What is the difference between ERC-20 and ERC-721?
ERC-20 tokens are fungible — each token is identical and interchangeable, like dollar bills or litres of water. ERC-721 tokens are non-fungible (NFTs) — each token has a unique ID and is distinguishable from every other token in the contract. Use ERC-20 for currencies, governance tokens, and DeFi utility tokens. Use ERC-721 for unique digital assets like artwork, collectibles, domain names, and game items where individual identity matters.
When should I use ERC-1155 instead of ERC-721?
Use ERC-1155 when your application needs both fungible and non-fungible tokens in the same contract, or when you need to batch-transfer multiple token types in a single transaction to save gas. ERC-1155 is especially powerful in gaming, where players hold both currency tokens (fungible) and unique items (non-fungible). It is also ideal for digital trading card systems with multiple copies of common cards alongside single-copy legendaries. If you only have unique 1-of-1 assets, ERC-721 is simpler and has broader marketplace support.
Can I create an ERC-20 token without coding?
Yes. ERC20Token.app lets you deploy a fully audited ERC-20 token on Ethereum Mainnet in under 5 minutes with no Solidity knowledge required. You configure the token name, symbol, total supply, and decimals through a web interface, connect your MetaMask wallet, and deploy. The contract is based on OpenZeppelin's battle-tested implementation. The flat fee is 0.02 ETH plus standard gas fees, and your contract is automatically verified on Etherscan.
Which token standard does Uniswap support?
Uniswap V2 and V3 support ERC-20 tokens only. The AMM model requires tokens to be fungible and interchangeable — it cannot create liquidity pools for NFTs or ERC-1155 tokens. NFT-focused liquidity protocols exist (Sudoswap for ERC-721, for example), but they are entirely separate from the Uniswap ecosystem. If your goal is to have a tradeable token on Uniswap, you must deploy an ERC-20. Our guide on listing your token on Uniswap explains exactly how to create your first liquidity pool after deployment.
Is ERC-1155 better than ERC-721?
Neither is universally better — they solve different problems. ERC-1155 is more gas-efficient for batch transfers and is the only standard that supports both fungible and non-fungible tokens in a single contract. However, ERC-721 has broader marketplace support, especially on Blur and Foundation, and is the universally expected standard for unique digital collectibles. For pure NFT projects (1-of-1 art, unique collectibles), choose ERC-721. For games or platforms with mixed asset types, choose ERC-1155. When in doubt about a collectible project, ERC-721 is the safer choice for maximum ecosystem compatibility.