Skip to main content
NFTs (briefly)

ERC-721: The NFT Standard Deep Dive

Pomegra Learn

ERC-721: The NFT Standard Deep Dive

The ERC-721 standard represents the foundational specification for non-fungible tokens on the Ethereum blockchain. Introduced in 2017, ERC-721 established a common framework that allowed developers to create, manage, and transfer unique digital assets using standardized interfaces and behaviors. Understanding ERC-721 requires examining not only what the standard specifies but also how it technically functions, what capabilities it enables, how it compares to alternatives, and how developers implement it in practice. This deep dive explores the architecture, components, advantages, and limitations of the ERC-721 standard.

The Genesis of ERC-721​

Prior to ERC-721, the Ethereum ecosystem had developed ERC-20, a standard for fungible tokens that became wildly successful. ERC-20 defined how interchangeable tokens should behave, specifying required functions, events, and interface characteristics that made tokens compatible across exchanges, wallets, and applications. The standard's clarity and consistency drove massive adoption across the DeFi ecosystem.

However, ERC-20's design was fundamentally unsuited to representing unique digital assets. The standard assumes all tokens are identical and interchangeable—you transfer amounts of tokens, not specific token instances. It was designed for currency and fungible assets, not collectibles or unique items.

ERC-721 was created to fill this gap. Drafted by William Entriken, Dieter Shirley, Jacob Evans, and Nastassia Sachs and formalized as Ethereum Improvement Proposal 721, the standard defined how unique, non-interchangeable tokens should function on Ethereum. The standard was revolutionary because it provided a clear, standardized way to represent digital ownership of unique items, something that had never been effectively possible at scale in decentralized systems before.

Core Architecture and Functions​

ERC-721 defines a set of required and optional functions that smart contracts must implement to comply with the standard. These functions establish consistent behavior across all ERC-721 tokens, enabling wallets, exchanges, and applications to interact with any ERC-721 contract without needing to understand the specific implementation details of that contract.

The fundamental concept in ERC-721 is the token ID. Each NFT is identified by a unique unsigned integer. The token ID, combined with the contract address, uniquely identifies a specific non-fungible token. When you own an ERC-721 token, you own a specific token ID within a specific contract.

Required functions in ERC-721 include balanceOf, which returns the number of tokens owned by a given address. This allows wallets and applications to determine how many NFTs an account holds. The ownerOf function returns the current owner of a specific token ID—given a token ID, this function returns the wallet address that owns that token. The transferFrom function allows the current owner to transfer their token to another address. The approve function allows an owner to authorize another address to transfer their token on their behalf.

Beyond these basic ownership and transfer functions, ERC-721 includes functions related to metadata. The tokenURI function is particularly important—it returns a URI (uniform resource identifier) pointing to metadata associated with a particular token. This URI typically points to a JSON file containing information about what the token represents: its name, description, image location, attributes, and other properties.

ERC-721 also specifies required events that contracts must emit when certain actions occur. The Transfer event is emitted whenever a token changes ownership. The Approval event is emitted when an owner approves another address to transfer their token. These events allow external systems to listen to blockchain activity and respond to token transfers and approvals in real time.

Token Metadata and URI Standards​

While ERC-721 specifies that tokens must have associated metadata accessible via a URI, the standard itself does not dictate the format or content of that metadata. However, a widely adopted convention specifies that metadata should be provided as a JSON object.

A typical ERC-721 metadata JSON file includes a name (the human-readable name of the specific token), description (a text description of what the token represents), image (a URI pointing to an image file representing the token), attributes (an array of property objects defining characteristics of the token), and optionally external_url (a link to more information about the token) and animation_url (a URI to an animated or dynamic representation).

The image and animation_url fields can point to various locations. Historically, many were stored on centralized servers, creating durability concerns—if the server disappeared, the image would become inaccessible. Increasingly, developers use decentralized storage systems like IPFS (InterPlanetary File System) or Arweave, which provide greater assurance that the data will persist. Some projects store metadata directly on-chain by encoding the JSON or image data as part of the smart contract itself.

An important distinction emerged around metadata mutability. Some ERC-721 contracts allow metadata to be modified after token creation—the image or attributes might change. Others create immutable metadata where the metadata associated with a token ID cannot be changed after creation. Immutability provides stronger guarantees about the permanence and integrity of the token's properties, which many collectors value.

Ownership, Transfers, and Approvals​

Understanding the mechanics of ownership and transfer in ERC-721 is essential for working with the standard. Ownership in ERC-721 is straightforward: at any given moment, one address owns each token. The ownerOf function returns this owner, and the balanceOf function indicates how many tokens an address owns.

Transfer mechanics work in two ways. Direct transfer allows an owner to transfer their token directly to another address using transferFrom. This immediately changes the ownership record on the blockchain, and the new address becomes the owner.

The approval mechanism enables delegation. An owner can approve a specific address to transfer their tokens. This is important for user experience on marketplaces. When you want to sell an NFT on a marketplace, you don't immediately transfer ownership to the marketplace. Instead, you approve the marketplace contract to transfer the token on your behalf. The marketplace then transfers the token to the buyer when the sale completes, and the buyer approves the marketplace to transfer to them. This separation of authorization from transfer provides important security and control to users.

The setApprovalForAll function allows an owner to approve another address to transfer any of their tokens without needing to approve each token individually. This is useful for marketplace integrations where users want to authorize the marketplace to handle transfers of any of their NFTs.

Enumeration and Discovery​

While not strictly required by ERC-721, the enumeration extension adds functions that help with token discovery. The totalSupply function returns the total number of tokens that have ever been created by a contract. The tokenByIndex function allows you to retrieve token IDs by index, enabling enumeration of all tokens in existence. The tokenOfOwnerByIndex function allows you to retrieve token IDs owned by a specific address by index.

These enumeration functions are not part of the core ERC-721 standard because they increase the computational overhead and gas costs of token contracts. However, they're frequently implemented because they enable useful features like displaying a user's entire NFT collection without requiring external indexing.

Many applications instead rely on external indexing services like The Graph that listen to blockchain events and create searchable databases of token information. When you query an NFT marketplace for all tokens in a collection or all tokens owned by a specific address, you're typically querying an off-chain index rather than reading directly from the blockchain.

Gas Costs and Efficiency Considerations​

Each operation on an Ethereum smart contract consumes computational resources measured in gas. Creating an NFT (minting), transferring it, and modifying its ownership all incur gas costs that users or contract deployers must pay. In ERC-721, each token is tracked individually, which creates efficiency trade-offs.

Minting a single new NFT in an ERC-721 contract requires updating storage to record that the new token ID is owned by the specified address. This is relatively inexpensive in terms of gas. However, if you want to create a thousand tokens simultaneously, you'd need to perform a thousand separate storage updates, incurring substantial gas costs.

Transfers are similarly reasonably efficient—changing the owner of a token requires a single storage update. However, the individual-token approach means that transferring multiple tokens requires multiple transactions or calls, each with its own gas cost.

This efficiency characteristic contributed to the development of ERC-1155, which allows batch operations and can represent many tokens within a single contract more efficiently. However, ERC-721 remains the standard of choice for most collectible and art NFT projects because its per-token focus aligns better with use cases where individual token identity and uniqueness is paramount.

Comparison with ERC-1155 Semi-Fungible Tokens​

While ERC-721 focuses entirely on non-fungible tokens, the later ERC-1155 standard introduced semi-fungible tokens that can represent both fungible and non-fungible assets in a single contract. Understanding the differences clarifies when each standard is most appropriate.

ERC-1155 allows a single contract to manage multiple token types. Some of those token types can be fungible (where all tokens with the same ID are identical), while others can be non-fungible (where each token ID is unique or unique combinations of ID and serial number identify specific items). This flexibility enables more sophisticated applications.

ERC-1155 also enables batch operations—you can transfer multiple tokens in a single transaction, which is more efficient in terms of gas usage than executing multiple ERC-721 transfers. For applications managing large numbers of items, particularly in gaming contexts, ERC-1155 offers superior efficiency.

However, ERC-721 remains the industry standard for standalone collectibles, artwork, and identity tokens because its focused, singular attention to non-fungible asset representation aligns perfectly with these use cases. Most NFT marketplaces, tools, and communities have been built around ERC-721.

Security Considerations and Best Practices​

ERC-721 implementations must address several security considerations. One important issue is the prevention of token loss through incorrect transfers. Unlike fungible token transfers where you specify an amount, ERC-721 transfers identify a specific token. Transferring to an incorrect address results in permanent loss.

Some implementations include a safe transfer function safeTransferFrom that includes a callback mechanism. When a token is transferred to a contract address, the contract must implement a specific function that acknowledges receipt of the token. If the contract doesn't implement this function, the transfer reverts, preventing accidental loss of tokens to contracts that can't handle them. This is a best practice that prevents a common class of errors.

Another security consideration involves authorization and approvals. Contracts should be careful about granting broad approval permissions. A malicious marketplace contract could theoretically authorize itself for all tokens and then misappropriate them. While blockchain transparency means such attacks would be immediately visible, users must carefully grant approvals only to trusted contracts.

Real-World Implementations and Examples​

ERC-721 has powered some of the most valuable and recognizable NFT projects. CryptoPunks, created in 2017, predated ERC-721 but inspired the standard and remains culturally significant. After ERC-721 was formalized, projects like CryptoKitties, Gods Unchained, and Decentraland used ERC-721 to manage unique digital items—collectible cats, game cards, and virtual real estate respectively.

Art platforms like SuperRare and Raible used ERC-721 to create verifiable digital ownership of artwork. The Bored Ape Yacht Club and similar generatively created collections built massive communities around ERC-721 tokens. Gaming projects increasingly adopted ERC-721 for in-game items, though some migrated to ERC-1155 for efficiency as collections grew.

These implementations revealed both the strengths and limitations of ERC-721 in practice. The standard provided a consistent interface that enabled marketplace interoperability—you could trade an NFT from one project on any ERC-721-compatible marketplace. However, the individual token focus created scaling challenges as collections grew, and the relatively simple metadata structure sometimes felt limiting for complex applications.

Evolution and Future Considerations​

While ERC-721 remains the industry standard for standalone NFTs, the ecosystem continues to evolve. Some proposals have suggested extensions to ERC-721 that would add capabilities like on-chain royalties—automatically directing a percentage of sales proceeds to the original creator. Other extensions aim to add composability, allowing NFTs to reference and interact with other tokens.

The emergence of ERC-1155 and other specialized standards shows that ERC-721, while foundational, is not always the optimal choice for every application. Gaming platforms, for instance, increasingly prefer the efficiency and flexibility of ERC-1155. Large-scale NFT projects sometimes develop custom standards optimized for their specific needs.

Nevertheless, ERC-721 has established itself as the defining standard for how non-fungible tokens should work on Ethereum and by extension on other blockchains that have adopted similar standards. Its clarity, simplicity, and focus on the unique token as a core concept have made it the foundation upon which the entire modern NFT ecosystem was built.

References​