ERC-721
ERC-721 is a standard for representing non-fungible tokens (NFTs) on the Ethereum blockchain, defining how unique digital assets are created, managed, and traded.
ERC-721, formalized as EIP-207, is the standard interface for non-fungible tokens (NFTs) on the Ethereum blockchain. Unlike fungible tokens (like ERC-20) where each unit is identical and interchangeable, ERC-721 tokens are unique and indivisible. Each token is identified by a unique tokenId, and the contract manages the ownership mapping between token IDs and their respective owners. The standard mandates several core functions: balanceOf(address _owner) returns the number of NFTs owned by an address; ownerOf(uint256 _tokenId) returns the address of the owner of a specific NFT; safeTransferFrom(address _from, address _to, uint256 _tokenId) and transferFrom(address _from, address _to, uint256 _tokenId) are used to transfer ownership of an NFT; approve(address _approved, uint256 _tokenId) grants permission to another address to transfer a specific NFT; getApproved(uint256 _tokenId) returns the approved address for a specific NFT; and isApprovedForAll(address _owner, address _operator) checks if an operator is approved to manage all of the owner's NFTs. It also requires events like Transfer and Approval to log these state changes. The primary advantage of ERC-721 is its ability to represent unique digital assets, such as digital art, collectibles, or in-game items, with verifiable ownership on the blockchain. The safeTransferFrom function is designed to prevent accidental loss of NFTs by ensuring that the recipient contract can handle ERC-721 tokens, adding a layer of security. Trade-offs include higher gas costs compared to ERC-20 due to the unique nature of each token and the complexity of managing individual token states.
graph LR
Center["ERC-721"]:::main
Pre_erc_20["erc-20"]:::pre --> Center
click Pre_erc_20 "/terms/erc-20"
Pre_smart_contract["smart-contract"]:::pre --> Center
click Pre_smart_contract "/terms/smart-contract"
Center --> Child_nft["nft"]:::child
click Child_nft "/terms/nft"
Center --> Child_metadata["metadata"]:::child
click Child_metadata "/terms/metadata"
Center --> Child_soulbound_token["soulbound-token"]:::child
click Child_soulbound_token "/terms/soulbound-token"
Rel_erc_1155["erc-1155"]:::related -.-> Center
click Rel_erc_1155 "/terms/erc-1155"
Rel_ipfs["ipfs"]:::related -.-> Center
click Rel_ipfs "/terms/ipfs"
Rel_erc_20["erc-20"]:::related -.-> Center
click Rel_erc_20 "/terms/erc-20"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Explain Like I'm 5
Imagine ERC-721 as a digital certificate of ownership for unique items, like a one-of-a-kind [trading](/en/terms/trading) card or a specific piece of digital art. Each card or artwork has its own special number, and the [blockchain](/en/terms/blockchain) keeps track of who owns which specific item.
🤓 Expert Deep Dive
ERC-721 (EIP-207) establishes a standard for non-fungible tokens, enabling the representation of unique digital assets on Ethereum. Its core innovation lies in the tokenId mechanism, which allows for granular tracking and ownership of individual assets within a single smart contract. The ownerOf function provides direct retrieval of an asset's proprietor, while transferFrom and the more secure safeTransferFrom facilitate provenance tracking. The safeTransferFrom function incorporates checks to ensure the receiving address is capable of handling ERC-721 tokens, typically by verifying adherence to the ERC-721 or ERC-1155 standards via onERC721Received callbacks. This prevents tokens from being sent to incompatible contracts, thereby avoiding 'black holes'. The approve and isApprovedForAll functions enable delegated management, crucial for marketplaces and secondary sale mechanisms. Architectural trade-offs include increased gas costs per token compared to ERC-20 due to the need to store and manage individual tokenId ownership mappings. Furthermore, the immutability of tokenId assignments means that once a token is minted, its identifier cannot be changed, necessitating careful planning during contract deployment.