ERC-20 vs ERC-721 vs ERC-1155: Interface Design Trade-offs That Shape On-Chain Economies

Most explanations frame ERC-20, ERC-721, and ERC-1155 as "fungible, non-fungible, and multi" — which is true but unhelpful. The deeper distinction is how each standard models ownership in contract storage.

ERC-20 stores a single mapping: address → uint256. One balance per address. The token ID is the contract address itself. Every unit is interchangeable because there is nothing to differentiate them — no metadata pointer, no index.

ERC-721 stores two core mappings: tokenId → owner (address) and owner → tokenCount (uint256). Each token is an entry in the first mapping. Enumeration (ERC-721Enumerable) adds a third mapping — tokenId → index — which is where gas costs explode on large collections.

ERC-1155 collapses both models into a nested mapping: tokenId → address → uint256. This is the key insight: ERC-1155 doesn't "support both fungible and non-fungible." It supports arbitrary balances per (id, address) pair. Whether a given id is fungible or non-fungible is an application-layer convention — the contract doesn't enforce it. You can mint 10 billion units of id 1 and exactly 1 unit of id 2. The standard is agnostic.

This storage difference drives every downstream trade-off in gas, composability, and indexing.

ERC-20 is the most deployed and the most abused standard on Ethereum. The interface is six functions and two events. The subtlety is in what's left unspecified.

• approve + transferFrom is a two-transaction pattern that grants unlimited spend by default in most implementations. The spender can drain up to the approved amount at any time. Most users approve type(uint256).max and forget about it — this is the single largest persistent attack surface in DeFi.
• decimals is cosmetic. The contract operates on raw uint256 values. A token with 18 decimals and a balance of 1e18 is "1 token" only by UI convention. Contracts that assume 18 decimals without checking will mishandle USDC (6), WBTC (8), or any non-standard decimal token.
• Return value handling — the original EIP specifies that transfer and transferFrom return bool. But tokens like USDT on mainnet (deployed before the standard was finalized) return nothing. This is why OpenZeppelin's SafeERC20 exists: it wraps calls to handle both cases. Contracts that call transfer directly without SafeERC20 will revert on USDT.
• Fee-on-transfer and rebasing tokens break any contract that compares balanceOf before and after a transfer and assumes the difference equals the input amount. This has caused losses in dozens of protocols.

ERC-20 has no hooks. There's no onERC20Received. Tokens sent to a contract that doesn't expect them are lost permanently. ERC-223 attempted to fix this; it never gained adoption.

ERC-721 assigns each token a unique uint256 identifier and tracks a single owner per id. The interface adds safeTransferFrom, which calls onERC721Received on the recipient if it's a contract. This is both a safety mechanism and an attack vector.

• safeTransferFrom performs an external call to the recipient. If the recipient is malicious, it can re-enter the calling contract. Any ERC-721 transfer in a protocol that doesn't follow checks-effects-interactions is a reentrancy risk. This is not theoretical — it has been exploited.
• Approval granularity: ERC-721 supports both per-token approval (approve) and blanket operator approval (setApprovalForAll). Operator approval grants control over every token owned by the caller in that collection. One compromised operator contract means total loss.
• Enumeration is optional (ERC-721Enumerable) and expensive. The tokenOfOwnerByIndex and totalSupply functions require maintaining ordered arrays on-chain. Minting and transferring become O(1) in the base spec but O(n) in enumerable variants for large collections. This is why many NFT contracts skip enumeration and rely on off-chain indexing.
• Metadata is handled by tokenURI, which returns a URI per token. The standard says nothing about what's at that URI or whether it's immutable. Most NFT metadata is on centralized servers or IPFS without on-chain content hashes. The token is on-chain; the thing it represents usually isn't.

ERC-1155 was designed to reduce deployment and interaction costs for applications managing many token types — games, marketplaces, mixed collections.

• Batch operations: safeBatchTransferFrom moves multiple token ids in a single call. Gas savings are real — roughly 40–60% cheaper than equivalent individual ERC-721 transfers for 10+ items, depending on implementation. But the ids and amounts arrays must match in length, and a revert on any single id reverts the entire batch. No partial execution.
• Single contract, many tokens: instead of deploying one contract per token type, ERC-1155 uses one contract for all ids. This simplifies deployment but centralizes risk. A bug in the contract affects every token id simultaneously.
• URI handling uses a single uri(uint256 id) function. The spec defines a substitution pattern — clients replace {id} in the returned string with the hex-encoded token id. This means all tokens share a URI template unless the contract overrides per-id. Off-chain infrastructure must handle this substitution correctly.
• Receiver hooks are mandatory: onERC1155Received and onERC1155BatchReceived must be implemented by any contract receiving tokens. Same reentrancy concern as ERC-721, but doubled — batch transfers invoke the hook once with arrays, and the callee has access to the full batch context during the callback.

The biggest practical friction with ERC-1155 is ecosystem support. Wallets, marketplaces, and block explorers have slower and less consistent support for 1155 than for 20 or 721. Indexing is harder because a single Transfer event (TransferSingle or TransferBatch) can represent minting, burning, or transfer depending on the from/to addresses, and batch events encode multiple operations in one log.

• Approval-based attacks span all three standards. Unlimited ERC-20 approvals, ERC-721 setApprovalForAll, and ERC-1155 setApprovalForAll all grant persistent access that survives until explicitly revoked. Users routinely forget to revoke. Tools like revoke.cash exist specifically because of this.
• Reentrancy via hooks: ERC-721 and ERC-1155 safe transfer functions make external calls to recipients. Any protocol accepting arbitrary NFT deposits via safeTransferFrom without reentrancy guards is vulnerable. ERC-20 lacks hooks entirely, which is actually safer in this narrow respect.
• Supply manipulation: ERC-20 has no standard mint/burn interface. Any token can add arbitrary minting functions. The standard guarantees nothing about supply integrity — only about the transfer interface. The same applies to ERC-721 and ERC-1155: minting logic is entirely implementation-defined.
• Interface detection: ERC-1155 requires ERC-165 (supportsInterface). ERC-721 also requires it. ERC-20 predates ERC-165 and doesn't use it. Contracts that rely on supportsInterface to detect ERC-20 will fail silently. There is no reliable on-chain method to detect whether an arbitrary contract is ERC-20 compliant.
• Phantom functions: nothing prevents a contract from implementing the ERC-20 interface but behaving maliciously — returning true from transfer without updating balances, or emitting fake Transfer events. The interface is a social contract, not an enforced one.

• Use ERC-20 when every unit is identical and you need maximum composability with existing DeFi infrastructure. AMMs, lending protocols, and governance systems are built around this interface.
• Use ERC-721 when individual token identity matters and you need per-token metadata, provenance, or ownership history. The ecosystem tooling (OpenSea, Reservoir, etc.) is deepest here.
• Use ERC-1155 when you're managing many token types from a single contract and batch operations provide meaningful gas savings — game items, edition-based art, mixed fungible/non-fungible systems. Accept the trade-off of weaker ecosystem tooling and more complex indexing.
• If you need a non-fungible token with fungible-like batch efficiency but full marketplace support, consider ERC-721 with a custom batch transfer function. It won't be standard, but marketplace aggregators already handle custom batch logic.

• EIP-20 specification: eips.ethereum.org/EIPS/eip-20
• EIP-721 specification: eips.ethereum.org/EIPS/eip-721
• EIP-1155 specification: eips.ethereum.org/EIPS/eip-1155
• OpenZeppelin implementation source for all three: github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token
• Approval checker and revocation tool: revoke.cash
• Dune dashboard for ERC-1155 adoption metrics: dune.com/queries filtering on ERC-1155 TransferSingle/TransferBatch events
• ERC-165 interface detection: eips.ethereum.org/EIPS/eip-165 — essential reading for understanding how 721 and 1155 self-identify on-chain