ERC-20 vs ERC-721 vs ERC-1155

Token standards define interfaces that wallets, marketplaces, indexers, and applications can recognize. They do not define a complete product, guarantee value, or remove the need for permission and economic design. ERC-20 models interchangeable units, ERC-721 models individually identified tokens, and ERC-1155 models multiple token IDs inside one contract. Choosing among them begins with the asset model and user operations, not with which acronym is most familiar.

Fungible and non-fungible assets

Fungible units are interchangeable within the same asset: one smallest unit has the same contract-defined meaning as another. Non-fungible tokens have distinct identifiers that can point to different metadata or rights. Semi-fungible systems may have many interchangeable copies of one item ID alongside unique items. The distinction affects storage, balances, transfer interfaces, approvals, indexing, and UI. It does not by itself establish legal ownership of an off-chain object or the permanence of external metadata.

ERC-20: interchangeable balances

ERC-20 tracks balances by account and exposes a common interface for total supply, balance queries, transfers, allowances, and delegated transferFrom operations. Common uses include utility units, governance weight, stable-value representations, and protocol accounting. The decimals value is presentation metadata; contract arithmetic still uses integers. Allowances deserve careful UX because an approval can authorize future spending up to a limit. Applications should display the spender address, requested amount, and revocation path rather than presenting approval as a harmless setup step.

ERC-721: one owner per token ID

ERC-721 assigns each existing token ID to one owner and supports approvals for a token or an operator. A token URI can point to metadata, but the standard does not require the referenced content to be immutable or available forever. Transfers should use the safe variants when sending to contracts so recipients can acknowledge support. Application design must decide how minting is authorized, whether metadata can change, what burning means, and whether ownership of a token conveys any off-chain license or access.

ERC-1155: multiple token types in one contract

ERC-1155 stores balances for account-and-ID pairs. One ID can have many interchangeable copies while another may have a supply of one. Batch balance and transfer functions reduce repeated calls when an application manages sets of assets. Operator approvals apply broadly, so the interface must explain their scope. Receiver callbacks help prevent assets from becoming trapped in contracts, but integrations still need to handle batch events and URI substitution correctly.

A practical comparison

Standard | Asset model                 | Balance shape       | Typical transfer
ERC-20   | Fungible units               | account -> amount   | transfer(to, amount)
ERC-721  | Unique token IDs             | tokenId -> owner    | safeTransferFrom(...)
ERC-1155 | Many IDs, each with a supply | account + id -> qty | safeTransferFrom / batch

This comparison describes the interface shape, not implementation quality. Extensions add enumeration, metadata, permits, royalties, voting, pausing, supply tracking, and other behavior. Every extension expands integration and security work. Use only the capabilities the product requires, and verify what wallets and downstream platforms actually support.

Transfers and approvals need careful UX

An ERC-20 allowance authorizes a spender for an amount. ERC-721 can approve one token ID or grant an operator access to all of an owner's tokens. ERC-1155 uses operator approval across token IDs. These permissions are different, but each can outlive the transaction that created it. Show the exact contract receiving authority, avoid unlimited approvals when they are unnecessary, and provide a way to inspect and revoke permissions. Contracts should validate callers and follow checks-effects-interactions around external receiver calls.

Choose from product invariants

• Use ERC-20 when the application needs divisible, interchangeable units and balance-based accounting.
• Use ERC-721 when each token ID is independently owned and identity matters more than quantity.
• Use ERC-1155 when one system manages many IDs, editions, or batch operations with per-ID quantities.
• Avoid forcing real-world rights into token semantics that the contract cannot enforce.
• Document minting, burning, metadata, approvals, administrative powers, and upgrade behavior before implementation.

Security and permission considerations

Review supply controls, privileged minting, pause powers, metadata updates, operator permissions, receiver callbacks, and external marketplace assumptions. Token standards improve interoperability, not safety. Use reviewed implementations where they fit, test nonstandard tokens and recipient contracts, and obtain independent review for high-value systems. The best standard is the smallest well-understood interface that represents the actual asset and permission model.

Design for real integration behavior

Applications must handle more than the happy-path transfer. ERC-20 tokens can vary in decimals and may not return values exactly as a client expects. ERC-721 transfers to contracts should use receiver-aware methods when the recipient must acknowledge custody. ERC-1155 receivers handle both single and batch callbacks. Test approvals, revocation, zero balances, batch ordering, duplicate IDs, and transfers to contracts that deliberately reject assets. An interface that displays a transfer as successful before the receipt and relevant events are confirmed can mislead users even when the token contract is correct.

Metadata needs a lifecycle too. Define whether URIs are immutable, content-addressed, or controlled by an administrator; validate how clients behave when metadata is unavailable; and avoid promising ownership rights that exist only in an external policy. For bridged or multi-chain assets, decide which contract is authoritative and how duplicate representations are labeled. The standard selects a common interface, but supply governance, metadata integrity, custody, and legal meaning remain application decisions that should be visible to users and reviewers.

Choose semantics before an interface

Start with the asset model: fungible quantity, unique identity, or multiple IDs with per-ID balances. Then choose the smallest standard that expresses it, document every privileged capability, and test the wallets, marketplaces, and receiver contracts the product actually supports. Compatibility is earned through precise behavior and integration testing, not through an ERC number alone.