ERC-20 vs ERC-721 vs ERC-1155: Token Standards
Token standards are the contracts that make crypto feel like products instead of isolated code. This complete guide explains how ERC-20, ERC-721, and ERC-1155 actually work in wallets, DeFi, marketplaces, games, and tooling. You will learn the real interface surface, how transfers and approvals are indexed, why safe transfers exist, how metadata flows, how permits and royalties fit (and where they do not), and what security pitfalls cause the most loss in production. By the end, you can pick the right standard confidently, design better UX, and avoid common traps like approval phishing, broken event emissions, token id confusion, and receiver-hook reentrancy.
TL;DR
- ERC-20 is for fungible balances: interchangeable units like currencies, points, governance weights, and vault shares.
- ERC-721 is for unique items: each tokenId has one owner, used for NFTs, tickets, membership passes, domains, and identity artifacts.
- ERC-1155 is a multi-token catalog: one contract manages many ids, each id can be fungible or non-fungible, with gas-saving batch transfers.
- Ecosystem support matters:
- Events are not optional:
- Approvals are the biggest user risk:
- Safe transfers exist for a reason:
- Defense for real users:Ledger.
If you are new, treat this like a map: what each standard is for and how it behaves. If you build apps, treat this like a checklist: what must be emitted, what must be checked, and what UX decisions reduce user loss. The goal is not just to memorize differences. The goal is to understand the contract and product surface that wallets, indexers, exchanges, bridges, marketplaces, and analytics tools assume.
1) The keyword focused intro: ERC-20 vs ERC-721 vs ERC-1155 token standards
If you search for ERC-20 vs ERC-721 vs ERC-1155, you will usually see a one-line summary: ERC-20 is fungible, ERC-721 is NFTs, and ERC-1155 is multiple token types. That is true, but it is incomplete. The standard you choose determines how your assets appear in wallets, how they are traded, how they are bridged, how they are indexed, and how easy it is to build safe UX around approvals and transfers.
A token standard is not only a developer choice. It is a compatibility contract with the entire ecosystem. When you implement ERC-20, you are implicitly promising that transfers emit the right events, balances behave predictably, approvals work as expected, and integrations can reason about decimals and total supply. When you implement ERC-721, you are promising that each tokenId is unique, ownership and approvals are consistent, and safe transfers protect users from accidental loss. When you implement ERC-1155, you are promising that ids are meaningful, batch transfers follow rules, and receiver hooks are correct.
This guide goes beyond labels. It explains how standards work end-to-end: the interface surface, the indexing layer, metadata, security pitfalls, and practical decision-making. By the end, you will know when each standard is the right fit, and what controls you need to ship it safely.
2) Why token standards exist and what they really standardize
Before standards, every token contract was a snowflake. Each project invented its own function names, its own event formats, and its own idea of what a transfer or approval should mean. That forced wallets, exchanges, and analytics tools to ship custom adapters. If the adapter did not exist, the token was invisible or unusable in that product.
Ethereum standards fix that by defining a shared interface. But it is important to understand what is and is not included:
- Standards define behaviors that other software relies on:
- Standards do not automatically guarantee safety:
- Standards are a language:
- Events matter as much as functions:
When you choose a standard, you are choosing your downstream dependencies. If you break the expected semantics, users blame wallets and marketplaces, but the root cause is often the token contract. A serious token design asks: what will indexers assume, what will wallets show, and what will users be asked to sign?
3) A precise mental model: units, ownership, ids, and operators
All token standards model value, but they model it differently. If you frame the standards as four concepts, the differences become obvious:
- Unit type:
- Identity:
- Transfer mechanics:
- Permission model:
ERC-20 is balance-first. ERC-721 is tokenId-first. ERC-1155 is catalog-first: a single contract manages many ids, and each id can behave like ERC-20 or like ERC-721 depending on supply and semantics.
Fast intuition: what users expect
- ERC-20:
- ERC-721:
- ERC-1155:
4) ERC-20: fungible tokens and the allowance system
ERC-20 is the backbone of DeFi. It models a ledger of balances per address, plus a permission layer called allowances. The simplicity is why it composes so well: DEXs, lending protocols, bridges, payroll systems, and analytics tools all speak the same interface.
A) ERC-20 surface: functions and events that integrations depend on
The core ERC-20 functions are familiar, but production issues often come from tiny deviations: missing returns, wrong events, or weird edge cases around transfer behavior. Most integrations expect:
- totalSupply() reports total units in existence.
- balanceOf(address) reports a user balance.
- transfer(to, amount) moves units from msg.sender to to.
- approve(spender, amount) sets allowance for spender.
- allowance(owner, spender) shows current allowance.
- transferFrom(from, to, amount) moves units using allowance.
- Transfer event is emitted for transfers, mints, and burns.
- Approval event is emitted when allowances change.
Mints and burns are typically represented as transfers to or from the zero address. Indexers often use that convention to track supply changes. If you mint without emitting a Transfer from address(0), many tools will not display supply correctly.
B) Decimals and UX: why 18 is common but never guaranteed
ERC-20 does not require decimals, name, or symbol, but most tokens include them for UX. The biggest rule for apps is simple: never assume decimals. A token with 6 decimals looks like a token with 18 decimals if you assume incorrectly, and users get confused. For builders, the biggest rule is also simple: publish correct metadata and keep it stable.
A subtle UX pitfall is mixing human amounts and raw units. Contracts operate in raw units. Frontends operate in human units. The safest pattern is: parse user input to raw units early, then never re-interpret it.
C) Allowances: the most important and most abused feature
Allowances are the permission model that lets a DEX or vault move tokens on your behalf. The convenience is also the risk. If a spender contract is compromised, or if a user approves the wrong contract, the spender can drain up to the allowance.
Common allowance patterns:
- Exact allowance:
- Unlimited allowance:
- Incremental allowance:
Most ERC-20 drains happen because of approvals: a malicious contract, a compromised router, a fake frontend, or a phishing signature. If your product asks for approvals, your product is part of the security story. Consider exact approvals by default, show contract addresses clearly, and remind users to revoke allowances after use.
D) The approve race issue and practical mitigation
The historical approve pattern has a known risk: if you change an allowance from X to Y, a spender could front-run and spend X before the change, then also spend Y after the change. Some tokens and apps mitigate by requiring setting allowance to zero before setting a new value. Many modern implementations use increaseAllowance and decreaseAllowance patterns to reduce risk.
In practice, app developers should be defensive: handle tokens that require zero-first, and show users what is happening in the UI. Token developers should avoid weird behavior that breaks standard tooling unless there is a strong reason.
E) Permits: approvals via signatures
Permit-style approvals allow users to approve spending via an off-chain signature, which a relayer or the spender submits on chain. The user avoids an extra transaction for approve. This improves UX and reduces friction, but adds security details: you must handle nonces, deadlines, and domain separation correctly to prevent replay.
- Nonce tracking:
- Deadline:
- Domain separation:
- User education:
F) Non-standard ERC-20 behaviors that break integrations
Many tokens implement ERC-20-like interfaces but with behavior that surprises protocols:
- Fee-on-transfer:
- Rebasing:
- Blacklist or pause logic:
- Non-standard return values:
If you ship a token with unusual behavior, document it clearly and expect integration friction. If you build an app, assume tokens can be weird and implement defensive checks.
5) ERC-721: non-fungible tokens and safe transfer semantics
ERC-721 is the standard for unique assets. Each tokenId has exactly one owner at a time. The interface includes ownership queries, transfers, and approvals. What makes ERC-721 different in practice is that NFTs are deeply tied to metadata: images, traits, animation, and external content.
A) Ownership model: tokenId maps to owner
In ERC-20, you ask "how many units does this address have?" In ERC-721, you ask "who owns tokenId X?" That difference changes everything: marketplaces list tokenIds, wallets display tokenIds, and transfers move a specific id.
- ownerOf(tokenId) returns current owner.
- balanceOf(owner) returns number of NFTs owned.
- tokenURI(tokenId) returns metadata pointer for that id.
B) Approvals: per-token approval and operator approval
ERC-721 has two approval modes:
- approve(to, tokenId) grants approval to move one tokenId.
- setApprovalForAll(operator, approved) grants operator approval for all tokens in the collection owned by the user.
Operator approvals are the biggest risk in NFTs. A malicious or compromised operator can transfer any NFT in that collection. Many phishing attacks aim to trick users into signing setApprovalForAll for a fake marketplace.
NFT approval safety checklist for product teams
- Warn on operator approvals:
- Prefer per-token approvals:
- Show the operator address:
- Promote revocation:
C) safeTransferFrom: why it exists
In early NFT days, users accidentally sent NFTs to contracts that could not handle them, effectively locking them forever. ERC-721 safe transfer solves this by checking whether the destination is a contract, and if so, calling onERC721Received on that contract. If the contract does not return the correct magic value, the transfer reverts.
Safe transfer is not a minor detail. It is a user protection mechanism. For builders, it also introduces a security consideration: it creates an external call during transfer. That means reentrancy patterns matter, especially if you add extra logic around transfers.
D) Metadata: tokenURI, permanence, and update discipline
Most ERC-721 NFTs depend on off-chain metadata JSON:
- image or animation_url points to media.
- attributes describe traits.
- name and description define display text.
The best practice for collectible NFTs is content addressing: IPFS or Arweave with stable identifiers. If your metadata is mutable, you should be transparent about it, because users price NFTs based on perceived permanence. A "freeze metadata" commitment is a product promise, not just a technical choice.
E) Enumeration and gas trade-offs
Some collections support enumerating tokenIds owned by an address on chain. This is expensive. Many teams avoid full enumeration and rely on indexers instead. The trade-off is: better on-chain discoverability vs higher gas costs for transfers and mints.
For most mainstream products, indexer-based enumeration is acceptable, but the contract should emit correct events so indexers can compute state reliably.
F) Royalties and reality
Royalties are commonly signaled via a separate standard that tells marketplaces what royalty percentage should be paid. The key reality is that many royalty mechanisms are enforced by marketplace policy rather than unstoppable contract logic. If you promise royalties, be precise: what is signaled, what is enforced, and where.
6) ERC-1155: multi-token catalogs, batch ops, and receiver hooks
ERC-1155 is designed for efficiency. It allows a single contract to manage many token types identified by id. Each id has balances per address, similar to ERC-20, but the contract can also represent unique items if supply is one or if ids map to unique concepts. The killer feature is batching: transfer many ids in one transaction.
A) Catalog model: id-based balances
Think of ERC-1155 as a warehouse. Each id is a SKU. For each SKU, each user has a balance. Some SKUs might be stackable (fungible), like "health potion x 5". Some SKUs might be unique, like "legendary sword id 9001". ERC-1155 does not enforce uniqueness by itself. Your application logic defines the meaning of ids.
B) Batch transfers and why they matter
Batch transfers reduce gas and improve UX for games and catalogs. Examples:
- Send a starter pack: multiple items in one transfer.
- Crafting: burn inputs and mint outputs in a single flow.
- Marketplace bundles: sell several ids together.
Batch operations also change indexing patterns. Instead of one Transfer event per id, you get TransferBatch. Your analytics stack must handle that correctly.
C) Approvals: operator model
ERC-1155 uses setApprovalForAll like ERC-721. That means operator approval can cover every id in the contract. This is convenient for marketplaces and game operators, but it is also a high-risk user permission. The same phishing patterns apply: users get tricked into approving an operator, then lose inventory.
D) Receiver hooks: onERC1155Received and onERC1155BatchReceived
Like ERC-721 safe transfer, ERC-1155 safe transfers call into the receiver contract if the receiver is a contract. If the receiver does not implement the expected interface, the transfer reverts. This reduces accidental loss, but again introduces external calls during transfers. Builders must treat hooks carefully: checks-effects-interactions, reentrancy guards when needed, and strict validation.
E) Metadata: uri() template and {id} substitution
ERC-1155 commonly uses a single URI template with a placeholder that clients substitute with the id. This is efficient, but it creates a subtle UX dependency: clients must follow the template rules. If you break expectations, metadata will not render correctly in wallets or marketplaces.
7) Feature comparison table: what differs in practice
A useful comparison is not only "fungible vs NFT". It is also approvals, batch ops, metadata mechanics, and integration reach.
| Feature | ERC-20 | ERC-721 | ERC-1155 |
|---|---|---|---|
| Primary identity | Balance amount | tokenId | id (SKU) plus amount |
| Fungible units | Yes | No | Per-id |
| Non-fungible units | No | Yes | Per-id by convention |
| Batch transfers | No | No | Yes |
| Approvals model | Allowance per spender | Approve per tokenId + operator | Operator approval for all ids |
| Safe transfer receiver checks | Not in standard | safeTransferFrom calls onERC721Received | safeTransferFrom calls onERC1155Received |
| Metadata mechanism | name symbol decimals (optional) | tokenURI per tokenId | uri() template with id substitution |
| Typical ecosystem strength | DeFi composability | Marketplaces and collectibles | Games, bundles, catalogs |
| Common user loss pattern | Unlimited allowance drains | Operator approval phishing | Operator approval phishing + hook bugs |
8) When to use which standard: a decision framework
Picking a standard is easier if you decide based on product constraints rather than trends. Use this framework: what you are selling, how it is traded, how it is composed, and what UX you can support.
A) Use ERC-20 when units are interchangeable and you want DeFi reach
ERC-20 is ideal if users naturally think in quantities, not unique items. Typical use cases:
- Currencies and stablecoins:
- Governance tokens:
- Points and rewards:
- Vault shares:
If you want deep integration with AMMs, lending markets, perps platforms, and bridges, ERC-20 is the default. The main cost is designing safe approval UX, because almost every DeFi action uses allowances.
B) Use ERC-721 when each item has uniqueness and broad NFT support matters
ERC-721 is ideal when each asset has identity: a pass, a ticket, a collectible, or an item with unique metadata. Typical use cases:
- Collectibles and art:
- Tickets and seats:
- Membership and access:
- Domains and identity:
The biggest advantage is marketplace and wallet compatibility. The biggest risks are operator approvals and metadata trust.
C) Use ERC-1155 when you have a catalog and need batch efficiency
ERC-1155 is ideal for large catalogs and inventories. Typical use cases:
- Game items:
- Editions and semi-fungibles:
- Bundles:
- Tickets at scale:
The biggest advantage is lower gas and atomic bundles. The biggest risks are operator approvals and hook-based bugs, plus complexity in indexing and id design.
Teams often start with ERC-721 for everything because it is the most common NFT narrative. Later they discover they actually need catalogs, bundles, and high-frequency transfers. If your design looks like an inventory, ERC-1155 is a better fit from day one.
9) Events and indexing: why your token might be invisible if you get this wrong
Blockchains store state, but most user-facing tools do not recompute state from scratch every time. They index events. That means event correctness is not a nice-to-have. It is the difference between a usable token and a ghost token.
A) ERC-20 indexing basics
ERC-20 indexers typically track balances by processing Transfer events: subtract from sender, add to receiver. For mints and burns, they use address(0). If your token does not emit Transfer correctly, many explorers will show incorrect balances.
B) ERC-721 indexing basics
For ERC-721, the Transfer event is also essential. Ownership is commonly derived from Transfer events. Safe transfers are still transfers. They should emit the same Transfer event.
C) ERC-1155 indexing basics
ERC-1155 uses TransferSingle and TransferBatch. Indexers must handle arrays of ids and amounts. If you emit wrong arrays, or if your ids are inconsistent with metadata, your inventory will look broken in wallets.
Indexing checklist for token builders
- Emit standard events correctly:
- Represent mints and burns consistently:
- Test against real indexers:
- Document metadata strategy:
10) Security and common failure modes across standards
Standards make integration easy, but they do not make your token safe. Most losses come from a few repeating patterns: approvals, hooks, and admin controls.
A) Approval phishing and compromised spenders
Approvals are permissions. If a user approves a malicious spender or operator, the contract may be working correctly while the user loses assets. Product design reduces this risk by defaulting to safer choices:
- Ask for exact approvals when possible:
- Show the contract address and purpose:
- Provide a revoke path:
- Use safer signing patterns:Ledger.
B) Receiver hooks and reentrancy
ERC-721 and ERC-1155 safe transfers call external contracts. If you add custom logic in transfer hooks, you can accidentally create reentrancy or state inconsistencies. The safe design approach:
- Keep transfer logic minimal:
- Use checks-effects-interactions:
- Guard sensitive operations:
C) Upgrades, admin roles, and trust boundaries
Many token projects use upgradeable proxies for flexibility. That is not automatically wrong, but it changes trust. If an admin can upgrade token logic, they can potentially change transfers, approvals, and metadata behavior. If trust minimization is a goal, be transparent:
- Publish admin addresses:
- Use timelocks:
- Separate roles:
- Do not brick recovery:
11) Developer notes: implementations, testing, and integration reality
The fastest path to a correct implementation is to start from audited, widely used libraries and minimize overrides. But even with good libraries, production behavior depends on how you integrate.
A) Use audited libraries and keep overrides small
Audited libraries reduce obvious mistakes, but overrides can reintroduce risk. The safest pattern is: keep the standard behavior intact, add your custom logic in carefully designed extension points, and document any behavior that deviates from typical expectations.
B) Testing strategy that catches real-world bugs
Unit tests are not enough. Token systems fail at boundaries: approvals, hooks, unusual transfers, and indexing assumptions. A robust test plan includes:
- Event emission tests:
- Approval invariants:
- Hook safety:
- Indexing simulation:
- Edge cases:
C) Interface detection and capability checks
Many contracts use interface detection to discover whether a token supports certain interfaces. That is common for ERC-721 and ERC-1155 receivers. If you implement interfaces incorrectly, safe transfers can fail. For builders integrating tokens: check interfaces when possible and fail with clear errors.
D) Naming, symbol collisions, and canonical addresses
Users often trust token symbols too much. Symbols are not unique. When tokens exist on multiple chains, confusion gets worse: multiple contracts can claim the same symbol. Serious projects publish canonical contract addresses per chain and link them from official channels. Serious apps show contract addresses and verify lists for safety.
If your UI only shows a symbol, you are training users to be phished. Showing the contract address or a verified badge is part of user safety. On the backend, always treat address as identity. Never trust a token symbol alone.
12) Metadata deep dive: permanence, updates, and practical UX
Metadata is where most non-fungible projects become real products. It is also where trust problems show up. Even ERC-20 tokens have metadata-like elements (name, symbol, decimals) that must be correct. For NFTs, metadata is the product.
A) Storage options: centralized, IPFS, Arweave, and hybrids
- Centralized URLs:
- IPFS:
- Arweave:
- Hybrid:
The biggest problem is not which one you pick. The biggest problem is failing to communicate the policy: can metadata change, how often, and who controls it?
B) Dynamic metadata and update signaling
Dynamic NFTs are popular: traits evolve, tickets are consumed, memberships level up. If metadata changes, the ecosystem needs a way to refresh. Some marketplaces refresh periodically, others need signals. The reliable pattern is:
- Emit update events when metadata changes.
- Keep changes predictable and documented.
- Avoid surprise content swaps that destroy trust.
C) ERC-1155 id schemas and metadata consistency
ERC-1155 id design is a product decision. A good id schema is:
- Stable:
- Documented:
- Extensible:
- Consistent:
13) Gas and scale: what gets expensive and what stays cheap
Gas efficiency is not just a developer concern. It affects user behavior. If it is expensive to mint or transfer, users avoid actions, marketplaces list fewer items, and your app feels slow.
A) ERC-20 gas profile
ERC-20 transfers are generally cheap and predictable. Approvals cost a bit more due to storage writes, especially when changing from zero to non-zero. For high-volume systems, gas savings come from minimizing unnecessary approvals and batching operations off-chain where appropriate.
B) ERC-721 gas profile
ERC-721 transfers and mints can be expensive if you store per-token metadata on chain or if you use enumeration. Many projects optimize minting with batch mint patterns and lighter metadata storage strategies. The trade-off is complexity and compatibility. Always test with major marketplaces and wallets.
C) ERC-1155 gas profile and batch advantage
ERC-1155 is typically the most efficient standard for inventories because it batches operations. If your product frequently moves multiple items, ERC-1155 can be the difference between usable and unusable. The main trade-off is integration complexity: not every marketplace treats ERC-1155 the same way, and your id semantics must be clear.
| Scenario | Best fit | Why | Watch out for |
|---|---|---|---|
| High-frequency swaps and DeFi | ERC-20 | Native composability with DeFi protocols | Allowance UX and spender risk |
| Unique collectibles with marketplace focus | ERC-721 | Strongest NFT ecosystem support | Operator approvals, metadata trust |
| Game inventory with bundles | ERC-1155 | Batch transfers and catalog model | Id schema and receiver hook safety |
| Tickets by tier with many copies | ERC-1155 | One id per tier, cheap distribution | Market compatibility and transfer rules |
14) Cross-chain and wrapping: how standards behave when you leave one chain
Token standards were designed for Ethereum-like environments, but today assets move across chains. Bridging creates new contracts and new trust assumptions. For users, the biggest risk is confusion: two tokens with the same name but different backing. For builders, the biggest risk is mismatched semantics: approvals, metadata, and id mapping.
A) ERC-20 bridging patterns
ERC-20s often bridge as wrapped representations. That means the "same token" on chain B is actually a different contract address. If your UI does not show canonical addresses, users can be tricked into trading a fake.
B) NFT bridging patterns
NFTs can bridge as locked originals with minted representations, or as burn-mint models depending on design. The complexity increases because metadata and tokenIds must remain consistent. A bridge can accidentally create duplicate tokenIds or break metadata references if not designed carefully.
C) ERC-1155 bridging patterns
ERC-1155 bridging must preserve id semantics and balances. Because ERC-1155 can represent both fungible and non-fungible concepts per id, mapping mistakes are easy. A serious bridge design publishes id mapping and ensures that receiver chains interpret ids the same way.
When assets exist on multiple chains, the token name is the least reliable signal. Encourage users to verify addresses and use trusted sources. If your app lists bridged assets, label them clearly and provide proof links.
15) Practical patterns: permits, royalties, semi-fungibles, and vault shares
Token standards rarely exist alone. Real projects combine standards or add adjacent standards. Here are the most common patterns and how to think about them.
A) Permit flows: fewer transactions, more signature security
Permit is popular because it improves UX. But signatures are powerful. If you adopt permit flows, build your UI to make the permission explicit, include deadlines, and consider safe defaults.
B) Royalties: signal vs enforce
Royalties are often a marketplace coordination problem. If you signal royalties, document where they are respected. If you want enforcement, understand that on-chain enforcement can break interoperability and liquidity. Many teams compromise: signal royalties and rely on marketplaces, while focusing on strong community incentives.
C) Vault shares and yield-bearing ERC-20
Many yield products use ERC-20 shares to represent deposits in a vault. The UX challenge is that users see a token balance that changes in value relative to underlying. The safety challenge is that approvals to the vault are approvals to a contract that can move funds. Make allowances clear and encourage revocation after deposits when feasible.
D) Semi-fungibles and value slots
Some assets are not purely fungible or purely unique. Examples: subscription passes with time value, bonds with maturity, or positions with partial value. Many projects represent these using NFTs with metadata, ERC-1155 ids, or specialized standards. The important part is not which standard you pick. It is whether downstream tools can interpret it safely.
16) Integration checklists: what to confirm before you ship
If you are integrating tokens into an app, the most common failures are assumptions. Use these checklists to avoid surprises.
A) ERC-20 integration checklist
ERC-20 integration checklist
- Decimals:
- Return values:
- Allowance UX:
- Fee-on-transfer:
- Rebasing:
B) ERC-721 integration checklist
ERC-721 integration checklist
- Use safeTransferFrom:
- Approval clarity:
- Metadata caching:
- Refresh behavior:
C) ERC-1155 integration checklist
ERC-1155 integration checklist
- Batch events:
- Id schema:
- Operator warnings:
- Receiver support:
17) Code sketches: minimal patterns that keep you safe
These code sketches are conceptual patterns you can adapt. They are not full implementations, but they show where safety checks live.
18) Real-world scenarios: pick the standard like a product engineer
This section gives scenario-based guidance. It is the fastest way to decide without overthinking.
A) You want a community token for tipping and governance
Use ERC-20. You want DeFi reach, simple transfers, and governance integration. Spend your energy on safe tokenomics and safe approval UX, not on uniqueness.
B) You want a membership pass that gates content
Use ERC-721 if each pass is unique and collectible, or if you want strongest NFT wallet support. Use ERC-1155 if you have tiers with many copies and you want cheap distribution per tier id. Design your revocation policy carefully: do you burn, expire via metadata, or check external conditions?
C) You are building a game with inventories, crafting, and bundles
Use ERC-1155. You will need batch operations, multiple item types, and a stable id schema. Build a strong operator warning UX, because game inventories get drained when users approve fake operators.
D) You are building ticketing for events
If tickets are unique seats, ERC-721 fits well. If tickets are by tier with many copies, ERC-1155 is efficient. Include safe transfer checks and clear metadata refresh logic if tickets can be invalidated or consumed.
E) You are representing positions, subscriptions, or bonds
Many teams use NFTs to represent positions because uniqueness is useful. But sometimes ERC-1155 ids work better if you need partial fungibility within a category. The correct choice depends on how you want users to trade positions and how you want wallets to display them.
19) Quick check
If you can answer these without guessing, you understand token standards at a practical level.
- What is the user permission difference between ERC-20 allowances and ERC-721 operator approvals?
- Why do ERC-721 and ERC-1155 have safe transfer receiver checks?
- What breaks if you emit wrong events, even if state is correct?
- When is ERC-1155 a better choice than ERC-721 for NFTs?
- What is the biggest user loss pattern across all three standards?
Show answers
Allowances vs operator approvals:
Safe transfer checks:
Wrong events:
ERC-1155 vs ERC-721:
Biggest user loss:
FAQs
Is ERC-1155 only for games?
No. It is best known for games, but it is useful anywhere you have many token types, editions, or bundles. Tickets by tier, membership tiers, and multi-item bundles are common non-game uses.
Can ERC-1155 represent NFTs?
Yes. ERC-1155 ids can represent unique items by convention, for example if each id has a max supply of 1. The standard itself does not enforce uniqueness, so your contract logic and your documentation must define it clearly.
Why do users lose tokens even when the contract is not hacked?
Because approvals can be abused. Users often approve malicious spenders or operators via phishing, fake frontends, or compromised routers. The contract can behave correctly while the user loses assets due to permissions they granted.
What is the safest approval strategy for users?
Prefer exact approvals for ERC-20 when possible, avoid setApprovalForAll unless necessary, and revoke permissions after use. For safer signing and phishing resistance, some users choose hardware wallets: Ledger.
Do token standards guarantee marketplace support?
They improve compatibility, but support still varies. ERC-721 has the broadest NFT marketplace support. ERC-1155 is widely supported, but some marketplaces handle metadata and listings differently. Always test on the platforms your users care about.
Should I use upgradeable proxies for tokens?
It depends on your trust model. Upgrades provide flexibility but increase trust assumptions. If you upgrade, publish admin addresses, use timelocks, announce changes clearly, and avoid breaking standard semantics.
Choose the standard that matches your product, then ship it safely
ERC-20 is money-like balance infrastructure, ERC-721 is identity-like uniqueness, and ERC-1155 is catalog-like efficiency. The best choice is not the trend. It is the one that matches how users think, how assets trade, and how your system scales. Then focus on the real risk: approvals and hooks. Good defaults, clear signing prompts, correct events, and honest metadata policies are what make tokens feel trustworthy in the real world.
References and deeper learning
Official and reputable starting points for token standards and safe implementations:
- EIP-20: ERC-20 Token Standard
- EIP-721: ERC-721 Non-Fungible Token Standard
- EIP-1155: Multi Token Standard
- Ethereum.org: Token standards overview
- OpenZeppelin Contracts: audited implementations
- TokenToolHub Blockchain Technology Guides
- TokenToolHub Blockchain Advance Guides
Further lectures (go deeper)
If you want to go beyond "what is ERC-20" and into real engineering decisions, follow this deeper path:
- Permits in production:
- NFT metadata permanence:
- Approval threat modeling:
- ERC-1155 id schema design:
- Hook safety:
- Cross-chain canonicals:
