Ethereum's token standards divide into three families. ERC-20 handles fungible tokens where every unit is interchangeable (like USDC or ETH). ERC-721, ERC-1155, and ERC-404 handle tokens where identity matters — NFTs, gaming items, and hybrid designs. Each solves a slightly different problem and has different tradeoffs. Understanding when to reach for each is required literacy for anyone dealing with NFT-adjacent products.
The core distinction
Fungible tokens are like dollars — one is worth exactly the same as another, and you don't care which specific unit you hold. ERC-20 handles this cleanly.
Non-fungible tokens are like art or property titles — each has a unique identity and possibly different value. Two "identical" NFTs are still distinguishable by their token ID.
Semi-fungible tokens are like concert tickets or gaming items — many copies of the same thing exist (a specific ticket type, a specific in-game item), but individual instances have identity too (row 5 seat 12, or gaming item #384 with specific stats).
The three NFT-family standards address these use cases differently.
ERC-721: the OG NFT standard
ERC-721 launched in 2018 and defined what most people think of as "an NFT." Every token has a unique ID within its collection. The mapping is strict: one owner per token ID, each ID exists as a unique instance.
Required functions:
- ownerOf(tokenId) — who owns this specific token
- balanceOf(owner) — how many tokens this owner has
- transferFrom(from, to, tokenId) — transfer a specific token
- approve(to, tokenId) — allow another address to transfer a specific token
Storage-wise, ERC-721 keeps a mapping from token ID to owner. Every mint creates a new entry. Every transfer updates one entry.
Used by: virtually every "PFP" NFT collection (CryptoPunks retroactively, Bored Ape Yacht Club, Doodles), Ordinals (in adaptation), most digital art platforms, ENS names (each is an ERC-721 token), most POAP-like collectibles.
Strengths: mature, universally supported, well-understood by every wallet and marketplace. Any wallet knows how to display an ERC-721 collection.
Weaknesses: expensive to mint and transfer in bulk (each operation is a separate transaction with separate gas costs). Not designed for many-copies items (would require minting each copy as a separate ERC-721, which wastes gas). Metadata (image, attributes) is typically stored off-chain, adding external dependencies.
ERC-1155: the flexible standard
ERC-1155 emerged in 2019 from the gaming community. Instead of "each ID is one token," it allows "each ID represents a class of tokens, and multiple copies of that class can exist."
The mental model: instead of NFT #1, NFT #2, NFT #3 being three separate assets, ERC-1155 has "Sword" as an ID and mints 1,000 copies. Each user's balance for that ID is a number — like ERC-20 but with multiple IDs.
Key features:
- Batch operations: mint or transfer many token IDs and quantities in one transaction
- Combined balance queries: check balances across many IDs at once
- Semi-fungibility native: can have both "type 1: unique sword #1" and "type 2: potion, 1000 in circulation" in the same contract
Required functions:
- balanceOf(account, id) — how many of this ID does this address hold
- safeTransferFrom(from, to, id, amount, data) — transfer a specific quantity of a specific ID
- safeBatchTransferFrom — transfer many IDs and quantities at once
- setApprovalForAll — one approval covers all IDs in the contract
Used by: Enjin (pioneered ERC-1155), most gaming NFTs, OpenSea's shared storefront contracts, editions and multiples in digital art (SuperRare editions, some Zora drops).
Strengths: gas-efficient for bulk operations (mint 100 items in one transaction), flexible (supports both unique and multi-copy tokens in the same contract), designed for games and multi-item catalogs.
Weaknesses: less familiar to marketplaces and wallets (many won't display ERC-1155 collections as cleanly as ERC-721), harder to build classic PFP-style collections (though possible), no per-token ownership query (you always need to know the ID you're asking about).
ERC-404: the hybrid
ERC-404 launched in early 2024 as an experimental standard that combines ERC-20 and ERC-721 behaviors. The pitch: tokens that are fractional and tradeable like ERC-20 when in wallets, but which "materialize" as NFTs when accumulated to a whole unit, and "dematerialize" back to fractional balances when spent.
Mechanically: a user with 0.5 tokens holds a fractional balance. When they acquire 0.5 more (reaching a whole 1), an NFT is minted to them. If they spend that NFT (or move any of the balance), the NFT is burned and the balance updates accordingly.
The intent is DEX liquidity for NFT-style assets. An NFT collection with an ERC-404 token can trade on Uniswap V3 pools like any other ERC-20, and holders who accumulate whole units get the NFT experience.
Used by: some experimental NFT collections in 2024-2025 (Pandora was the flagship early example), various derivative projects.
Strengths: DEX-native liquidity for previously illiquid NFTs. Solves the "hard to trade individual NFTs" problem.
Weaknesses: substantial gas overhead per operation (every ERC-20 transfer might trigger NFT minting/burning logic). Semantics are strange — an NFT's "value" is tied to the fractional token's DEX price, which fluctuates. Not universally supported; many wallets and marketplaces treat ERC-404 as either an ERC-20 or an ERC-721 rather than a native hybrid.
The standard remains experimental. Adoption has been niche, and most builders have not moved to it. It's worth understanding as a concept but is not the default for new NFT projects.
Choosing between them
For a new PFP-style collection (unique art per token, each token owned by one holder): ERC-721. Universal support, clean UX.
For a game or app with many items and copies (weapons, potions, land plots): ERC-1155. Gas-efficient, flexible, designed exactly for this.
For a project intending to launch on DEXs with NFT-style semantics: ERC-404 might make sense, but understand you're on experimental territory with limited ecosystem support.
For editions and multiples of digital art: either ERC-721 (each edition as separate token) or ERC-1155 (each edition as an ID with N copies). ERC-1155 wins on gas; ERC-721 wins on collector familiarity.
Metadata: the shared challenge
All three standards share a problem: what does the token look like?
The standard says: the contract can specify a URI for each token that returns JSON with name, description, image URL, and attributes. But the standard doesn't say where that URI must live or how the image must be stored.
Common patterns:
- IPFS storage: metadata pinned to IPFS with content-hashed URIs. Decentralized but requires either the collector to run an IPFS node or an IPFS gateway.
- Arweave storage: pay once, stored forever (in theory). Permanent but relies on Arweave's long-term viability.
- Centralized storage: metadata on the project's own web server. Cheapest but the collection dies if the server goes away.
- On-chain: full metadata (and sometimes image data) stored in the contract itself. Most expensive but permanent.
Standards for metadata pinning quality are cultural, not enforced. When you buy an NFT, checking where the metadata lives is part of evaluating what you're buying.
The one thing to remember
The token standard is not the same as the token itself. ERC-721, ERC-1155, and ERC-404 are contract patterns. The specific token contract implementing them has its own logic — mint mechanics, royalty enforcement, transfer restrictions, upgrade paths. Two ERC-721 collections can have very different behaviors even though they share a standard interface.
When you're evaluating an NFT collection, "it's ERC-721" tells you the interface is standard. It doesn't tell you what the specific contract does beyond that interface — for that, you need to read the contract itself.
