NOUTITA NEWSROOMSTEP-BY-STEP GUIDE

NFT Standards Explained: ERC-721, ERC-1155 and ERC-6551

An in-depth learning guide for the US Web3 market outlining what NFT standards are, how ERC-721, ERC-1155 and ERC-6551 differ, their trade-offs, and actionable steps to implement and experiment responsibly.

LEARN & GUIDES / TECHNICAL GUIDE

noutita.com#TECH

NFTs are more than cute images on chain. They’re standardized interfaces that let wallets, marketplaces, and contracts talk to each other about ownership, metadata, and rights. In this guide, we unpack three influential Ethereum NFT standards — ERC-721, ERC-1155, and ERC-6551 — and show you how to reason about when to use each in real-world apps. We’ll also surface two credible vantage points on debates around these standards and show practical steps you can take to experiment safely.

In Brief (TL;DR)

ERC-721 is the classic NFT standard: each token is unique and owned by an address. It emphasizes strict one-to-one ownership, with optional metadata and enumeration extensions. Key foundation: ERC-165 interface detection and the canonical NFT interface. (eips.ethereum.org)

ERC-1155 is a multi-token standard designed to reduce gas and enable batched transfers, representing both fungible and non-fungible tokens in a single contract. It supports batch operations and a flexible token ID scheme. (eips.ethereum.org)

ERC-6551 (Token Bound Accounts) links an NFT to a deterministic, on-chain account that can own assets and execute actions. It enables NFTs to act like agents with their own execution context, backed by a central registry. Created in 2023, it’s still under active review and adoption. (eips.ethereum.org)

Real-world angle: Layer-2 ecosystems are rapidly prototyping NFT bridges and token standards, with L2BEAT tracking and comparing various bridge patterns (e.g., L2ERC721Bridge). This matters for cost, data availability, and cross-chain usability. (l2beat.com)

1. Theoretical Foundations & Invariants

NFTs formalize ownership, transfer rules, and metadata in programmable contracts. Three invariants recur across NFT standards:

Identity: Each token has a unique identifier and a well-defined owner.

Ownership transfer: Transfers and approvals follow strict rules to prevent unauthorized moves.

Interoperability: Marketplaces, wallets, and dApps rely on a common interface so they can operate with any compliant contract.

A short, important reminder from the ERC-721 specification sets the tone for how these standards are written and enforced:

"The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119." This strict language underpins predictable behavior across implementations and is foundational to audits and tooling. (eips.ethereum.org)

ERC-721: A standard interface for non-fungible tokens. Each tokenId is unique, and ownership is tracked per token. The ERC-721 family includes metadata and optional enumeration extensions to describe and enumerate assets. The canonical interface requires supportsInterface (ERC-165) and a Transfer/Approval workflow. (eips.ethereum.org)

ERC-1155: A multi-token standard designed to represent multiple token types — fungible and non-fungible — in a single contract. This enables batch transfers and reduces boilerplate when many item types exist in a game or marketplace. It defines an interface that all token types must implement and emphasizes a robust event log model for balance auditing. (eips.ethereum.org)

ERC-6551: Token Bound Accounts assigns a deterministic, account-like wrapper to a non-fungible token. This pattern lets NFTs own assets and execute operations through a dedicated account, with a central registry establishing the address space. The proposal was created in 2023 and remains under review and discussion as of today. (eips.ethereum.org)

Two hotly debated angles help illuminate how teams decide between these paths:

Gas and UX: ERC-1155’s batch transfers can dramatically reduce gas in scenarios with many token types. Proponents argue this makes on-chain item bundles and games cheaper to operate. Critics warn that the complexity of a multi-token contract can complicate tooling and upgrades for some projects. (eips.ethereum.org)

True individuality vs. efficiency: ERC-721 preserves one-to-one identity and straightforward metadata, which is ideal for unique art and collectibles. ERC-1155 trades some granularity for efficiency, which benefits games and platforms with many item types. The Ethereum.org token standards hub presents both views and the basic tradeoffs. (ethereum.org)

Tip: If you want canonical practice examples or reference implementations, you can study OpenZeppelin’s ERC721 docs and the ERC-721 GitHub spec. They pull together practical patterns used by many live contracts. (github.com)

Blockquote: A concise primer from the ERC-721 spec emphasizes ownership and interoperability: “A standard interface allows wallet/broker/auction applications to work with any NFT on Ethereum.” (eips.ethereum.org)

Source note: The origin and framing of ERC-721 and ERC-1155 are described in their EIP pages, including publication years and core rationale. ERC-721 was published in January 2018; ERC-1155 followed in June 2018. These dates anchor the evolution of NFT standards. (eips.ethereum.org)

2. Step-by-Step Tutorial (Practice)

This section translates theory into hands-on steps you can run on a testnet. We’ll cover prerequisites, risk considerations, and a practical sequence to explore ERC-721, ERC-1155, and ERC-6551 in a safe, incremental way.

A. Prerequisites & Security

Prereqs (conceptual): A wallet (e.g., MetaMask), a testnet account (Goerli or Sepolia), a development environment (Hardhat, Foundry, or Brownie), and a basic Solidity knowledge foundation.

Tooling basics: You should be comfortable compiling, deploying, and interacting with contracts. Use existing, audited libraries where possible (e.g., OpenZeppelin) to minimize risk. (github.com)

Security posture: NFT contracts require careful attention to reentrancy, approvals, and the signature verification patterns. ERC-6551, in particular, introduces an account abstraction layer that can affect custody and authorization flows. Review the ERC-6551 specifications and the security considerations in the proposal. (eips.ethereum.org)

ABI awareness: Interacting with NFT contracts typically uses a standard ABI (functions like balanceOf, ownerOf, safeTransferFrom for ERC-721; batchTransfer for ERC-1155). ABI concepts are summarized by Etherscan’s information center, which explains how ABIs translate human calls into calldata. This is essential when you write scripts to mint, transfer, or query token data. (kb.etherscan.com)

What you’ll gain from this guide:

A mental model for choosing NFT standards based on use case, scale, and cross-chain considerations.

A practical, testnet-oriented workflow to mint, transfer, batch, and bind accounts to NFTs.

A lens on how L2 ecosystems affect NFT design decisions and developer tooling. (ethereum.org)

Primary sources you’ll want to reference during the practice:

ERC-721 specification (January 2018) for the baseline contract model, interface IDs, and metadata conventions. (eips.ethereum.org)

ERC-1155 specification (June 2018) for multi-token handling and batch transfers. (eips.ethereum.org)

ERC-6551 specification (February 2023) for token-bound accounts and cross-chain account semantics. (eips.ethereum.org)

OpenZeppelin’s ERC721 docs for pragmatic patterns and secure defaults. (github.com)

Ethereum.org’s token standards hub for ecosystem-facing summaries and canonical definitions. (ethereum.org)

B. Executing the Steps

Step 1 — Set up a minimal ERC-721 testbed

Create a simple NFT contract that adheres to ERC-721, including the essential balanceOf, ownerOf, transferFrom, and approve functions. Use ERC-721 metadata extension to expose tokenURI data. The ERC-721 specification itself and OpenZeppelin examples provide the required interfaces and optional extensions. (eips.ethereum.org)

Deploy to a testnet. Mint a small collection (e.g., 3–5 items) to a test wallet. Observe Transfer events in the transaction log to understand how ownership moves between addresses. The ERC-721 page explicitly documents the Transfer event and its semantics. (eips.ethereum.org)

Watch the metadata flow: the tokenURI data points to off-chain metadata that describes the asset. The ERC-721 spec’s metadata extension is optional but commonly used; the metadata JSON format is illustrated in the spec. (eips.ethereum.org)

Step 2 — Explore ERC-1155 for multi-type assets

Implement or adopt a minimal ERC-1155 contract and deploy a few token types (IDs) that can be both fungible and non-fungible within one contract. The ERC-1155 spec emphasizes the ability to transfer multiple IDs in one call and to emit appropriate TransferSingle or TransferBatch events. This is a central design benefit for game items and bundles. (eips.ethereum.org)

Perform batch transfers: mint a few IDs with different “amounts” and execute a batch transfer to a wallet, then query balanceOfBatch to confirm ownership. The spec explicitly codifies the batch transfer behavior and the balance tracking through events. (eips.ethereum.org)

Review interoperability notes: because ERC-1155 can represent both fungible and non-fungible tokens, your UI should be prepared to display multiple token types from a single contract. The spec’s design decisions around non-fungible tokens and balance tracking provide guidance here. (eips.ethereum.org)

Step 3 — Peek at token-bound accounts with ERC-6551

Read the ERC-6551 spec to understand the Registry, Account Interface, and Execution Interface. The registry creates token-bound accounts using create2 for deterministic addresses, which unlocks new composability patterns for NFTs as agents. (eips.ethereum.org)

Create a token-bound account for one of your ERC-721 tokens (per the spec’s pattern) and perform a simple on-chain operation via the bound account (e.g., a minimal signed action). The ERC-6551 page outlines the high-level mechanics and the account interface that must be implemented. (eips.ethereum.org)

Security lens: token-bound accounts introduce a new automation layer and a new attack surface. Review the security considerations and the idea that token-bound accounts must interoperate with ERC-165 and signature validation (ERC-1271). These guardrails are stated in the ERC-6551 doc and its reference implementations. (eips.ethereum.org)

Step 4 — Consider cross-chain and L2 patterns

Layer-2 ecosystems add both cost and complexity. L2BEAT tracks NFT bridges and cross-L2 patterns, revealing that many projects architect bridges like L2ERC721Bridge to move NFTs across layers. This matters for users who care about gas efficiency, data availability, and cross-chain ownership proofs. (l2beat.com)

When planning production, consider how your NFT flow behaves on L2s, which can influence your choice of standard (e.g., batch operations on ERC-1155 vs. single-token flows on ERC-721) and whether ERC-6551’s token-bound accounts add value in your multi-chain UX. The Ethereum.org token standards hub and L2-focused tooling provide a baseline for these decisions. (ethereum.org)

Two competing viewpoints you’ll want to weigh as you design real products:

Viewpoint A: Favor ERC-1155 for bundles and bulk operations in games and marketplaces. The standard explicitly enables batch transfers and multi-token types in a single contract, which can dramatically cut gas and simplify some flows. Proponents highlight the scalability benefits for asset packs and mass distributions. (eips.ethereum.org)

Viewpoint B: Favor ERC-721 for true individuality and simple metadata hosting. For uniquely identifiable art, collectibles, and provenance, one tokenId per asset can be easier to reason about, audit, and integrate with traditional NFT marketplaces. The ERC-721 baseline emphasizes interoperable ownership and metadata extensions that many creators rely on. (eips.ethereum.org)

Open-source and industry references you can study as you experiment:

ERC-721: the canonical spec and its explanation, including the metadata extension and enumeration optionality. (eips.ethereum.org)

ERC-1155: the multi-token standard, with batch transfer mechanics and the practical guidance on mixed fungible/non-fungible use cases. (eips.ethereum.org)

ERC-6551: token-bound accounts as a forward-looking pattern for on-chain agency and custody, including registry and account interfaces. (eips.ethereum.org)

Practical patterns and API surface from OpenZeppelin and Ethereum.org, which help translate the standards into secure, production-ready code. (github.com)

A note on tooling and interaction: ABIs are the bridge between human-readable function calls and on-chain calldata. Understanding ABIs helps you script interactions with ERC-721/1155 contracts and debug issues faster. Etherscan’s ABI overview is a concise primer for developers. (kb.etherscan.com)

Short glossary and references you’ll want at hand while building:

ERC-721: Non-Fungible Token Standard (January 2018 – original publication). (eips.ethereum.org)

ERC-1155: Multi Token Standard (June 2018). (eips.ethereum.org)

ERC-6551: Non-fungible Token Bound Accounts (February 2023). (eips.ethereum.org)

Token Standards hub: overview and ecosystem context (Ethereum.org). (ethereum.org)

L2 bridge patterns and ecosystem context (L2BEAT). (l2beat.com)

Implementation snapshots and reference code you can study today:

ERC-721 reference implementations and tests (GitHub). (github.com)

ERC-721 metadata/enumeration shims and patterns (GitHub doc). (github.com)

OpenZeppelin’s ERC721 contracts/docs (production-grade patterns). (github.com)

Notes on sourcing and time-bound facts:

The dates of the ERC publications are anchored to the EIPs themselves (January 2018 for ERC-721, June 2018 for ERC-1155, February 2023 for ERC-6551). These dates are cited directly from the EIP pages. If you need a quick reference, the EIPs page for each standard contains the official publication timestamp and authorship. (eips.ethereum.org)

Citations and references used in this article:

ERC-721: Non-Fungible Token Standard (EIP-721) — official specification and publication date. (eips.ethereum.org)

ERC-1155: Multi Token Standard (EIP-1155) — official specification and publication date. (eips.ethereum.org)

ERC-6551: Non-fungible Token Bound Accounts (EIP-6551) — creation date and overview. (eips.ethereum.org)

Ethereum.org token standards hub — high-level definitions and ecosystem framing for ERC-721 and ERC-1155. (ethereum.org)

OpenZeppelin ERC721 docs — practical, battle-tested implementation patterns. (github.com)

ERC721 GitHub spec (Ethereum/ercs) — reference interface details and metadata/enumeration notes. (github.com)

Etherscan ABI primer — fundamentals of how ABIs enable contract interaction. (kb.etherscan.com)

L2BEAT — NFT bridge patterns and cross-layer context. (l2beat.com)

Endnote on the learning arc: NFT standards are not static. As a result, practitioners should frequently revisit EIPs and major implementations as ecosystems evolve (especially around L2s and token-bound account research). The sources above provide a solid, citable backbone for both education and practical development as you explore the NFT standard landscape.