ERC-20, ERC-721, and ERC-1155 describe different Ethereum token-contract models: ERC-20 represents fungible units, ERC-721 identifies distinct tokens, and ERC-1155 lets one contract manage multiple token types. Their interfaces shape how applications refer to assets and interact with contracts, but do not by themselves establish a token’s economic or legal meaning, security, or suitability for a particular application.
What ERC-20, ERC-721, and ERC-1155 describe
A token standard is a specification for a contract interface and expected behavior. Applications can use a standard interface to interact with compatible contracts, but the interface is not a complete description of every implementation or of the asset represented.
ERC-20 is a fungible-token interface. Fungible units of the same token are interchangeable in the token model. Its specified interface includes total supply, account balances, transfers, allowances, approvals, and Transfer and Approval events. These define common interaction points; they do not establish how a token is issued, what backs it, or what it is worth.
ERC-721 provides interfaces for distinct tokens. A token is identified by the combination of its contract address and token ID on an Ethereum chain. The standard covers ownership lookup, approvals, authorized transfers, and transfer events. A token ID identifies a token within its contract; it is not a universal identifier across contracts.
ERC-1155 is a multi-token standard: one contract can manage multiple token types, including fungible, non-fungible, or semi-fungible configurations. It supports transfers of individual tokens and batch transfers. The category depends on how a token ID is implemented and supplied; an ID can have a quantity greater than one.
Compare the asset models and identifiers
| Standard | Model described | What identifies or measures a token | Interface emphasis |
|---|---|---|---|
| ERC-20 | Fungible units | Account balances and total supply | Transfers, approvals, and allowance-based spending |
| ERC-721 | Distinct tokens | Contract address plus token ID | Ownership, token approvals, and transfers |
| ERC-1155 | Multiple token types in one contract | Token IDs and balances, which can represent quantities | Single-token and batch transfers |
The key distinction is what the contract interface treats as the unit of interaction. ERC-20 centers on balances of a fungible token. ERC-721 centers on ownership of an individually identified token. ERC-1155 combines token IDs and quantities within a multi-token contract, so one contract can represent more than one token type.
These labels describe token-contract interfaces, not the asset’s full meaning. For example, an ERC-721 metadata interface can expose a URI referring to token metadata, but the standard does not guarantee that referenced content is available, permanent, accurate, or licensed. More generally, reading a token interface alone does not establish the rights or value associated with it.
How their interfaces shape interactions
ERC-20 applications commonly use balances to represent how many fungible units an account holds. The interface includes direct transfers and approvals that let another address spend up to an authorized amount. That allowance is an interaction permission defined by the token interface, not a statement about the token’s backing or purpose.
ERC-721 applications typically need to identify a specific token when checking ownership or authorizing a transfer. An application therefore needs the contract address and token ID, and it must use the token’s ownership and approval interfaces as intended. The standard specifies these interaction points; it does not prove that a particular contract is free of defects.
ERC-1155 interaction can refer to a token ID and a quantity. Its support for both single and batch transfers provides an interface pattern for moving one or several token types in a batch. This does not mean every ERC-1155 asset is interchangeable: a token ID may represent a fungible quantity, a unique item, or another configuration supported by the implementation.
For each standard, the application must use the interface that matches the deployed contract. Ethereum JSON-RPC exposes protocol-oriented records such as blocks, transactions, receipts, state queries, and contract logs; it is not itself a universal application-level token model. This distinction matters when an application reads contract data: the token standard describes contract interactions, while the node interface supplies blockchain data and transaction access. source
Common application patterns and trade-offs
A fungible balance model can fit an application that needs to represent interchangeable units. An individually identified model can fit an application that needs to distinguish tokens by ID. A multi-token model can fit a contract design that groups several token types and quantities under one contract. These are patterns implied by the interfaces, not endorsements or claims about any particular project.
The standards also imply different integration questions. Does the application need to track a balance, a specific token ID, or both IDs and quantities? Must it support approvals or authorized transfers? Does the application need batch operations? Which standard interfaces do the applications that will read or interact with the contract expect? Answering these questions helps clarify requirements without assuming that any one standard is universally preferable.
Do not infer that a standard guarantees security, performance, recovery, or compatibility with every wallet or marketplace. A standard defines interfaces and expected behavior; an implementation can add behavior or fail to meet expectations. Contract-specific review is separate from identifying the standard the contract claims to implement. The evidence here does not establish implementation-level security or performance outcomes.
Questions to resolve before selecting a standard
Use a requirements review rather than a label alone:
- Asset model: Does the application need interchangeable units, individually identified tokens, or multiple token types with quantities?
- Identifiers and records: Will the application work with account balances, contract-and-token-ID pairs, or token IDs plus quantities?
- Operations: Which transfers, approvals, ownership checks, and batch operations must the application support?
- Integration: Which interfaces do the specific applications and services involved expect, and do they match the deployed contract?
- Implementation: Has the specific contract been examined separately from its standard designation?
Finally, treat claims about security, performance, recovery, fees, availability, regulation, tax, or compliance as separate questions requiring evidence for the relevant contract and context. The standard comparison can clarify the interface and asset model, but it cannot answer those questions on its own.
Sources and references
- JSON-RPC API — ethereum.org; retrieved 2026-10-18.