ERC-721 defines ownership and transfer interfaces for individually identified tokens. This technical reference focuses on specification details an integrator can easily miss: opaque IDs, operator scope, receiver checks, optional enumeration and mutable metadata. The glossary entry below provides the broader NFT introduction. [1]

Last updated: 2026-10-08

Document and scope

• Title: ERC-721: Non-Fungible Token Standard.
• Authors: William Entriken, Dieter Shirley, Jacob Evans and Nastassia Sachs.
• Created: January 24, 2018.
• Status: Final, checked October 8, 2026.
• Rights: specification copyright and related rights waived through CC0.

The source standardizes a contract interface, not an NFT collection’s sale terms, minting policy or media license. Implementation licenses are separate: OpenZeppelin’s sample uses MIT. [1] [3]

Token IDs are opaque

ownerOf(tokenId) identifies a token’s current owner; balanceOf(owner) counts that owner’s NFTs. An ID is a uint256 unique within its contract. The standard tells callers not to assume IDs begin at zero or increase consecutively. The contract address and ID together identify the token on a particular chain; the network also matters when comparing assets across chains. [1]

Two contracts may both contain token 42. A wallet must not merge those records merely because the numbers match. Token IDs can be hashes or use other allocation patterns, and invalid or destroyed tokens cannot be treated as existing inventory. This follows from the standard’s identity rules, rather than a collection naming convention.

Approval scopes differ

approve authorizes an address for one token. setApprovalForAll authorizes an operator for the owner’s NFTs within that contract, including later-acquired tokens while the approval remains active. It does not authorize every collection on the network. getApproved and isApprovedForAll expose these distinct permission scopes. [1]

A transfer clears the token’s individual approval. It does not erase a separate owner-to-operator relationship for other tokens. A marketplace’s approval is permission to transfer, not proof that the owner signed a particular sale order. Applications need to distinguish token authorization from their own order logic.

What a safe transfer checks

Transfer calls require an authorized caller, the correct existing owner, a valid token and a nonzero recipient. When a safe transfer detects deployed recipient code, it invokes onERC721Received and requires the specified magic return value; rejection reverts the transaction. The plain transferFrom does not perform that receiver acceptance check. [1]

Acceptance is a protocol handshake. It does not certify the receiver’s withdrawal policy, trustworthiness or handling of every later operation. Recipient code can execute during the callback, so a safe-transfer label is not a substitute for reviewing application behavior. The source permits implementations to reject additional transfers, for example when paused.

Core discovery and optional extensions

Compliant contracts implement ERC-165 interface detection along with ERC-721. The core ERC-721 identifier is 0x80ac58cd. Metadata and enumeration have separate identifiers, 0x5b5e139f and 0x780e9d63. A claimed interface response is discovery information, not an independent audit. [1] [2]

name, symbol and tokenURI belong to the optional metadata extension. totalSupply, tokenByIndex and tokenOfOwnerByIndex belong to optional enumeration. Therefore an application cannot require on-chain enumeration from every base ERC-721 contract. A balance count alone does not reveal which IDs an owner holds. [1]

Events, minting and indexing

Transfer, Approval and ApprovalForAll events report ownership and permission changes. ERC-721 describes a constructor-time exception: tokens may be created and assigned during contract creation without individual Transfer events. Minting and burning methods themselves are outside the base interface. Indexers need to account for the actual contract’s implementation and optional interfaces, rather than assume one event-derived model always suffices. [1]

OpenZeppelin’s guide adds a custom awardItem method and per-token URI storage. Those methods illustrate an application design; ERC-721 does not mandate their names or unrestricted minting. [3]

Metadata updates and availability

The standard permits a token URI to change. A URI can refer to off-chain JSON, which can in turn refer to an image. Storing the URI on-chain does not place all those resources on-chain. Content-addressed IPFS data still needs retained copies and availability; a CID alone does not guarantee perpetual hosting. [1] [3] [4]

ERC-4906 separately defines MetadataUpdate and BatchMetadataUpdate to help services refresh changed JSON metadata. It does not include the new metadata in the event or guarantee that an indexer will refresh immediately. This optional extension is not required by base ERC-721. [5]

Royalty information is separate

ERC-2981 returns a royalty recipient and amount for a supplied sale price. The source describes voluntary payment and separates the information lookup from transferring funds. Neither base ERC-721 nor that lookup forces every transfer to pay a royalty; a transfer is not necessarily a sale. [6]

Social Media Sentiment

Not applicable to this standards reference. No current NFT market size, collection popularity or community mood is inferred from interface adoption.

Last updated: 2026-10

Related Terms

• ERC-721 — the broader glossary introduction.
• NFT — an individually distinguishable token.
• Smart Contract — code implementing ownership and permission rules.

See Also

• ERC-20 standard reference — fungible balances and numeric allowances.
• IPFS — content-addressed storage for resources such as metadata.

Sources

1. Entriken, Shirley, Evans and Sachs — ERC-721: Non-Fungible Token Standard (2018). The Final specification defines token identity, ownership, transfer checks, approvals, optional interfaces, events and CC0 rights.
2. ERC-165 — Standard Interface Detection. This specifies interface identifiers and the supportsInterface discovery procedure.
3. OpenZeppelin Contracts 5.x — ERC-721 guide. The implementation example separates custom minting and URI storage from the core token interface.
4. IPFS documentation — Persistence, permanence and pinning. The guide explains why content addressing does not itself guarantee continued availability.
5. ERC-4906 — EIP-721 Metadata Update Extension. This optional extension defines metadata-change events and their limits.
6. ERC-2981 — NFT Royalty Standard. This separate standard signals royalty recipient and amount; it does not force payment on every transfer.