9 NFT Standards: ERC-721 vs ERC-1155 vs Others Explained

If you’re deciding how to mint, manage, or extend non-fungible tokens, the NFT standards you choose determine what your collection can (and can’t) do. In practice, ERC-721 sets the foundation for unique assets, ERC-1155 handles multiple token types efficiently, and a growing family of extensions add royalties, rentals, batch minting, metadata updates, soulbound locks, token-bound accounts, and more. Put simply: ERC-721 is the baseline for one-of-one items, ERC-1155 is the multi-tool for mixed or semi-fungible inventories, and the “others” are targeted upgrades you add when a use case demands it. This article shows you how to pick confidently, implement safely, and avoid costly rebuilds by understanding exactly what each standard guarantees.

Quick answer: Use ERC-721 for purely unique items, ERC-1155 for collections with editions or in-game items that benefit from batch operations, and add extensions (2981, 4907, 3525, 6551, 2309, 4906, 5192) when you need royalties, rentals, semi-fungibility, token-bound accounts, efficient batch minting, metadata-change signaling, or non-transferable “soulbound” behavior.
At a glance steps: (1) Clarify your token economics and user journeys, (2) pick ERC-721 or ERC-1155 as a base, (3) add only the smallest extensions that solve real needs, (4) plan marketplace and wallet compatibility, (5) document invariants and test with realistic data.

Neutral note (not legal/financial advice): Tokens can embody rights or value. For compliance, IP, or consumer protection questions, consult qualified professionals in your jurisdiction.

1. ERC-721: The baseline for unique, one-of-one NFTs

ERC-721 defines the essential interface for non-fungible tokens: each tokenId maps to a distinct asset, with standard functions and events enabling transfer, ownership queries, and operator approvals. If you want a clean mental model and maximum third-party compatibility, ERC-721 remains the default choice. It’s ideal for art, identity credentials (if transfer remains enabled), game characters, memberships with individualized traits, and any asset where “quantity = 1” is a feature. Because wallets, marketplaces, and indexers optimize for ERC-721, integrations are straightforward, and deviations you might add later—like rentals or non-transferability—are easier to reason about when you start from this simple base. In short, if your collection is truly unique items and you don’t need mixed supplies or batch operations, ERC-721 is the safe, predictable foundation.

Why it matters
ERC-721’s simplicity yields strong intuitions: one contract, many unique IDs, each with a single owner. Indexers can reconstruct state from standard events, wallets can display tokens consistently, and marketplaces can settle transfers with fewer surprises.

How to do it (implementation tips)

• Start with a well-audited implementation (e.g., OpenZeppelin’s ERC-721) and keep overrides minimal.
• Emit all required events; avoid custom transfer flows that break standard assumptions.
• Align metadata URIs and trait schemas early so indexers don’t need custom parsing.
• Keep “admin” powers explicit and time-boxed (e.g., metadata freezes), with clear docs.
• Plan upgrade strategy (proxy vs. immutable) before mint; immutability improves trust.

Numbers & guardrails

• Supply clarity: If you mint 10,000 unique IDs, your max effective supply is 10,000—never more than one per tokenId.
• Gas intuition: Per-token mint/transfers are straightforward; you’ll often pay more than batch-oriented designs for large drops, but less cognitive overhead for unique-only collections.
• Compatibility: ERC-721 is the most widely supported NFT interface across wallets and marketplaces.

Synthesis: Choose ERC-721 when uniqueness is the product, integrations matter, and you want a standard that says little—but promises exactly what it must.

One-table snapshot (use sparingly):

2. ERC-1155: Multi-token and semi-fungible at scale

ERC-1155 generalizes token handling so a single contract can define many IDs, where each ID may behave like a fungible balance (quantity > 1), a non-fungible instance (quantity = 1), or a semi-fungible edition (e.g., 1,000 copies). The standard ships with batch transfers and batch balance queries, which materially reduce on-chain overhead when you mint or move multiple items at once. This makes ERC-1155 well-suited to gaming inventories, editioned art, loyalty items with tiers, and drop mechanics where you frequently transfer sets. The trade-off is conceptual: indexers infer ownership from events rather than enumerating a simple array of unique IDs, and some wallet UIs treat 1155 assets differently. If your roadmap includes large editions, bundles, or frequent batched interactions, ERC-1155’s efficiency is compelling.

Why it matters
Batch operations and mixed supplies let you express product catalogs and complex drops without deploying a new contract per type. You gain operational efficiency and a cleaner on-chain footprint.

How to do it (implementation tips)

• Use safeBatchTransferFrom for multi-ID moves; confirm recipients implement the 1155 receiver interface.
• Sort IDs before batch calls when your library benefits from it; some implementations are gas-optimized for ascending order.
• Document which IDs are fungible vs. non-fungible to prevent indexer ambiguity.
• Keep URI schemes stable; moving metadata paths post-mint complicates downstream caches.
• For marketplaces that prefer ERC-721, consider wrappers or mirroring critical pieces as 721.

Mini case (illustrative)
You airdrop a “starter kit” of 5 items to 10,000 players: a sword, shield, potion set (quantity 3), and a badge. With ERC-721, that’s 50,000 transfers; with ERC-1155, it’s 10,000 batch calls, each moving 5 IDs, typically cutting transactions (and gas coordination) by ~80% in this scenario. (Actual gas varies by implementation.)

Synthesis: Choose ERC-1155 when you need editions, bundles, or game-like inventories—and accept a slightly more complex mental model for material efficiency gains.

3. ERC-2981: A standard way to publish royalty info

ERC-2981 standardizes how a contract exposes royalty information per token or collection so marketplaces can calculate suggested payouts. It does not enforce the payment on-chain; it signals recipient and rate so off-chain or marketplace policy can honor it consistently. If creators depend on secondary revenue, ERC-2981 is the smallest, least-controversial addition you can make: it keeps pricing logic out of proprietary APIs and places the parameters on chain in a predictable interface. You can set a default royalty for the collection and override for specific tokenIds where needed. Because it’s query-only, the standard plays well with both ERC-721 and ERC-1155, and most major indexers understand it.

How to do it

• Implement royaltyInfo(tokenId, salePrice) with per-token overrides where appropriate.
• Keep the math simple (basis points) and avoid dynamic callbacks that can fail during reads.
• Document your royalty policy; the standard signals intent, marketplaces decide enforcement.
• Pair with transparent payout addresses (e.g., multisigs) to reduce support questions.

Numbers & guardrails

• Common royalty ranges span 0%–10%; keep totals under marketplace caps and watch compounding if you layer fees.
• For a 1.50 ETH sale and a 5% royalty, your contract would return 0.075 ETH and the royalty recipient’s address; marketplaces then decide how to route.
• Always plan a safe “update policy”: immutable vs. owner-settable with timelocks.

Synthesis: Add ERC-2981 whenever you want a canonical, chain-readable source of royalty parameters without entangling transfer logic.

4. ERC-4907: Time-boxed rentals with a built-in “user” role

ERC-4907 extends ERC-721 with a second role—user—and an expires timestamp that automatically revokes usage rights after a period. Ownership stays with the owner; the user gets limited rights (e.g., play a game character, access a space) until expiry. The big win is that you avoid “return” transactions; expiration is part of the standard, which simplifies rentals and short-term access. This pattern reduces friction for lending, ticketing windows, or subscription-like experiences that still want assets to be tradable by the owner. Because it’s additive, ERC-4907 composes with ERC-2981 and metadata extensions without redefining the base token behavior.

How to do it

• Define what use means in your app (gate gameplay, access, or rendering) and check userOf(tokenId) on each interaction.
• Set conservative expires defaults and add buffers to accommodate clock skew across clients.
• Log user assignments clearly; indexers will mirror rental states for UIs.
• Decide whether rentals pause transfers; if not, specify edge-case behavior in docs.

Mini case (illustrative)
A studio lends 2,000 avatars for 14-day trials. With ERC-4907, it sets user to the tester’s wallet and expires to a UNIX timestamp. No “return” call is needed; after the window, userOf returns the null address. Support tickets drop because the app reads one canonical source of truth.

Synthesis: Use ERC-4907 when you want rentals or trials baked into the token itself—with clear, auto-expiring permissions and minimal custom logic.

5. ERC-3525: Slot-based, semi-fungible tokens (SFTs)

ERC-3525 creates a hybrid model: each token has a unique ID (like ERC-721) and a divisible value (like ERC-20), grouped by slots. Tokens in the same slot are considered mutually substitutable with respect to value, while still being separately identifiable by ID. This “ID + value” structure fits financial-like instruments (e.g., credit lines, subscriptions with remaining balance, vouchers), ticket tiers, or loyalty points that accrue/spend over time without losing identity. If ERC-1155 feels too coarse for your accounting or ERC-721 too rigid for balances, ERC-3525 gives you native math on value while preserving per-token histories and relationships via slots.

Why it matters
Slots encode category semantics (e.g., “Gold Pass”), while value represents quantity (e.g., “remaining 30 units”). Transfers can move partial value between IDs, enabling sophisticated flows that would be awkward to model in plain 721s.

How to do it

• Map business categories to slots first; avoid over-creating slots that fragment liquidity.
• Keep value units intuitive (e.g., minutes, credits) and document conversion to app behavior.
• Test partial transfers with edge values (0, max) and ensure events reflect both value and ID changes.
• Clarify redemption: burning vs. decreasing value to zero.

Mini case (illustrative)
You issue 1,000 subscription tokens in slot 101 with an initial value of 30 “days”. Users can transfer 10 “days” to friends without moving the whole token. Accounting remains consistent: slot 101 denotes the plan; each token’s value is the remaining balance.

Synthesis: Choose ERC-3525 when you need per-token identity and arithmetic on balances within well-defined categories.

6. ERC-6551: Token-bound accounts (TBAs) that let NFTs own assets

ERC-6551 lets an ERC-721 token control a smart-contract account—effectively, your NFT can own other tokens, sign transactions, and interact with apps via a registry-created account that’s deterministically tied to the NFT. This unlocks inventory-within-avatar patterns (skins, badges), modular game loadouts, or on-chain provenance for items “held by” a character. It also enables delegated actions where the token-bound account transacts without exposing the holder’s main wallet. Because TBAs are standard, wallets and tools can introspect, display nested ownership, and enable safer UX for complex interactions. If your roadmap includes composability and in-world inventories, ERC-6551 is a high-leverage addition.

How to do it

• Create TBAs via the public registry; avoid bespoke factories that break discoverability.
• Decide permissioning: who can instruct the TBA—the owner, an operator, or an in-game role?
• Model recoverability if the backing NFT is burned or bridged; specify how the TBA behaves.
• Index TBA relationships for UI (e.g., “this avatar holds 4 items and 20 tokens”).

Numbers & guardrails

• Expect an extra deployment per TBA; budget gas accordingly for N avatars.
• Keep a cap on nested depth (e.g., avatar → bag → item) to avoid confusing UX.
• Document security surfaces: approvals from the TBA vs. the owner wallet.

Synthesis: Use ERC-6551 when your NFT needs a wallet of its own—cleanly modeling nested assets and actions without custom ad-hoc patterns.

7. ERC-2309: Efficient batch minting via a single event

ERC-2309 introduces ConsecutiveTransfer, an event that represents the mint (or burn/transfer) of a contiguous range of token IDs in one go. Instead of emitting one Transfer per token, you emit a single event with fromTokenId and toTokenId. Indexers use this to reconstruct state efficiently, which is especially useful for large initial mints in the constructor. The standard is purpose-built: it assumes IDs are consecutive and is primarily intended for creation events, not ongoing arbitrary transfers. When used correctly, ERC-2309 cuts log size and speeds up indexing for mass mints while staying compatible with ERC-721’s interface detection.

How to do it

• Emit ConsecutiveTransfer(startId, endId, address(0), to) during initial mint of a contiguous range.
• Don’t mix non-consecutive IDs in one event; ranges must be tight and ordered.
• Keep this for minting; regular post-mint transfers should still emit standard Transfer events.
• Validate ERC-165 support so tools can trust the pattern.

Numbers & guardrails

• If you mint IDs 1–10,000 in a constructor, 1 event replaces 10,000 logs, shrinking indexer workload significantly.
• Gas savings depend on implementation, but the primary win is in event volume and sync speed.
• Misuse (e.g., overlapping ranges) causes reconciliation headaches—document mint windows.

Synthesis: Add ERC-2309 when you need a clean, indexer-friendly way to announce large, consecutive mints without flooding the chain with events.

8. ERC-4906: A standard event for metadata updates

ERC-4906 standardizes a MetadataUpdate event (and a BatchMetadataUpdate) so apps and marketplaces know which tokens changed metadata without polling bespoke events or re-reading every token. Many collections evolve: traits reveal after mint, dynamic art updates as gameplay progresses, or provenance fields get fixed. Without a shared event, downstream services implement fragile, per-project listeners; with ERC-4906, they can react consistently and quickly. This extension is small but mighty: it doesn’t change transfer logic or storage patterns; it just gives the ecosystem a reliable hook when content changes, including batched updates for ranges.

How to do it

• Emit MetadataUpdate(tokenId) when a single token’s URI-backed data changes.
• Use BatchMetadataUpdate(fromId, toId) for reveals or mass fixes across ranges.
• Keep your metadata schemas backward-compatible; version your JSON if you evolve fields.
• Announce your update cadence so indexers can tune their listeners.

Checklist (concise)

• Describe changes in release notes.
• Emit the proper event(s) at the same block as the change.
• Avoid re-emitting for no-ops; it wastes downstream processing.
• Test with staging indexers to ensure events propagate as expected.

Synthesis: Include ERC-4906 if your collection will change on purpose; it’s the standardized “heads-up” marketplaces and wallets expect.

9. ERC-5192 (and cousins): Minimal soulbound/non-transferable NFTs

ERC-5192 adds a minimal interface to lock NFTs to an account, signaling whether each token is transferable. It’s intentionally tiny—focused on a locked status—so projects can make identity badges, credentials, or achievements that are provably non-transferable without reinventing detection. There are related proposals like ERC-4671 (non-tradable tokens) that articulate richer semantics, but 5192’s minimalism and compatibility with ERC-165 make it an approachable way to model account-bound assets. If you need attestations or badges that shouldn’t move, adopt 5192 and document processes for revocation or re-issuance under strict conditions (e.g., lost keys).

How to do it

• Return true from locked(tokenId) to indicate a non-transferable state; integrate checks in transfer hooks.
• Treat revocation as a governance decision; define who can burn or re-issue and under what proofs.
• For privacy-sensitive credentials, minimize on-chain personal data; store only what’s necessary.

Numbers & guardrails

• Plan rare exceptions: a 1-time re-issue path with multi-sig approval helps handle lost wallets.
• Keep lock semantics binary; if you need nuanced rules, layer additional access lists off-chain.
• Communicate clearly in UIs when a token is locked vs. transferable.

Synthesis: Reach for ERC-5192 when you want non-transferability to be obvious and verifiable—with the smallest surface area possible.

Conclusion

Choosing between ERC-721 and ERC-1155 comes down to how you model supply and behavior: unique-only vs. mixed and batch-heavy. From there, add the smallest extension that unlocks the exact capability you need—2981 for royalty signaling, 4907 for rentals, 3525 for slot-based balances, 6551 for token-bound accounts, 2309 for big mints, 4906 for metadata updates, and 5192 when transfers must be impossible. The more intentionally you compose these standards, the less custom logic you’ll maintain, the smoother your marketplace integrations will be, and the clearer your commitments become to holders. Use a simple base, document your invariants, and test the “boring” paths—transfers, approvals, reveals—just as thoroughly as your flashy mint page. Decide once, implement cleanly, and your tokens will remain understandable, indexable, and interoperable across tools and time. Build the smallest thing that works, and upgrade only when a real user story demands it.

Copy-ready CTA: Ready to choose a base and add only what you need? Draft your standard mix today and cut future rebuilds.

FAQs

What’s the simplest mental model for picking between ERC-721 and ERC-1155?
Think of ERC-721 as “one item per ID, quantity is always one,” and ERC-1155 as “one contract with many IDs, each having a balance.” If your collection is unique-only and integrations are your priority, start with 721. If you ship editions, bundles, or inventories where batch operations matter, 1155 saves complexity and gas overhead.

Can I combine ERC-1155 with royalties and rentals?
Yes. ERC-2981 (royalty info) is read-only and composes with both 721 and 1155. For rentals, 4907 is defined against 721, but you can create analogous patterns or wrappers for 1155 items, or keep rentals at the app layer by gating use instead of ownership.

Are royalties enforced on-chain?
The standard (2981) signals royalty parameters; enforcement depends on marketplace policy or custom sale contracts. Many projects keep transfers permissionless and handle royalty distribution when sales happen through their own marketplace or partners.

When should I prefer ERC-3525 over a plain 1155 edition?
Choose 3525 when each token needs identity plus a changing balance (credits, time, quota) that you want to move partially or account for precisely. If editions are simple and balances aren’t a thing, 1155 is lighter.

How do token-bound accounts (6551) affect security?
A token-bound account is a smart account under your NFT’s control. Treat it like any wallet: understand who can trigger actions (owner, operator), audit the registry and account implementation, and limit nested approvals to avoid confusing signing flows.

Is batch minting with ERC-2309 safe for all use cases?
Use it primarily for initial, consecutive mints. It drastically reduces event volume and speeds indexing, but don’t try to shoehorn non-consecutive ranges or post-mint transfers into it. Fall back to standard Transfer events outside the constructor-style batch mint.

What’s the cleanest way to signal reveals or trait fixes?
Adopt ERC-4906 and emit MetadataUpdate or BatchMetadataUpdate when your URIs or JSON change. Indexers can then refresh exactly the affected tokens instead of re-pulling the entire collection.

Can I make NFTs non-transferable without breaking wallets?
Yes—ERC-5192 offers a minimal, discoverable lock interface. Wallets and apps can read locked(tokenId) and adjust UI or transfer logic. For richer semantics, explore ERC-4671, but keep in mind that minimal, well-documented behavior often integrates best.

Do these standards apply beyond Ethereum mainnet?
Most EVM-compatible chains mirror these ERCs. Always check chain-specific quirks (precompiles, gas costs, indexer support), but the interfaces themselves usually port cleanly.

How should I document my chosen mix of standards?
Publish a short “Standards Manifest” in your docs: base (721 or 1155), plus each extension with rationale, change policy (who can update royalties/URIs), and any emergency controls. This reduces confusion for marketplaces, auditors, and holders.

References

• ERC-721: Non-Fungible Token Standard — Ethereum Improvement Proposals — 2018 — Ethereum Improvement Proposals
• ERC-1155: Multi Token Standard — Ethereum Improvement Proposals — 2018 — https://eips.ethereum.org/EIPS/eip-1155 Ethereum Improvement Proposals
• ERC-2981: NFT Royalty Standard — Ethereum Improvement Proposals — 2020 — Ethereum Improvement Proposals
• ERC-4907: Rental NFT (User & Expires) — Ethereum Improvement Proposals — 2022 — Ethereum Improvement Proposals
• ERC-3525: The Semi-Fungible Token — Fellowship of Ethereum Magicians (EIP discussion) — 2022 — Fellowship of Ethereum Magicians
• ERC-6551: Token-Bound Accounts — Ethereum Improvement Proposals — 2023 — Ethereum Improvement Proposals
• ERC-2309: ERC-721 Consecutive Transfer Extension — Ethereum Improvement Proposals — 2019 — Ethereum Improvement Proposals
• ERC-4906: Metadata Update Extension — Ethereum Improvement Proposals — 2022 — Ethereum Improvement Proposals
• ERC-5192: Minimal Soulbound NFTs — Ethereum Improvement Proposals — 2022 — Ethereum Improvement Proposals
• ERC-4671: Non-Tradable Tokens Standard — Ethereum Improvement Proposals — 2022 — Ethereum Improvement Proposals