ERC-721

What Is ERC-721?

ERC-721 is an Ethereum token standard for creating and managing non-fungible tokens, commonly called NFTs.

Each ERC-721 token has a unique token ID that distinguishes it from every other token managed by the same smart contract.

The official ERC-721 specification defines standardized rules for tracking ownership, transferring tokens, and granting other addresses permission to manage NFTs.

ERC-721 is classified as a Final Ethereum Request for Comments standard.

It was created because fungible-token standards cannot accurately represent assets that must be identified and tracked individually.

An ERC-721 token can represent a digital collectible, game item, membership credential, virtual property, event ticket, financial position, domain-like asset, or record connected with a physical item.

The standard defines blockchain ownership and transfer behavior, but it does not automatically establish copyright, legal ownership, authenticity, financial value, or rights to an external asset.

What Does ERC Mean?

ERC stands for Ethereum Request for Comments.

An ERC describes a technical standard that applications and smart contracts can follow to improve interoperability across the Ethereum ecosystem.

ERC-721 is the identifying number assigned to the non-fungible-token standard.

The number does not describe the token’s supply, price, blockchain address, or release date.

A contract implementing ERC-721 can add optional extensions and custom functions as long as its required behavior remains compatible with the standard.

Why Was ERC-721 Created?

Fungible assets are interchangeable because one unit normally has the same role as another unit of the same asset.

Non-fungible assets must be tracked separately because each unit can have different characteristics, history, rarity, rights, or value.

ERC-721 gives wallets and applications a common method for identifying the owner of each unique token.

It also standardizes transfers, approvals, operator permissions, and ownership-related event logs.

Without a shared standard, every NFT contract could require a different integration.

Shared functions allow general-purpose wallets, blockchain explorers, indexers, games, lending protocols, and other crypto applications to interact with many NFT collections.

How ERC-721 Works

An ERC-721 smart contract stores or calculates the owner associated with each valid token ID.

The contract also tracks how many NFTs each address owns within that collection.

When an authorized transfer occurs, the contract removes ownership from the sender and assigns the token ID to the recipient.

The contract emits a standardized

event so external applications can observe the change.

The owner can approve one address to transfer a specific NFT or authorize an operator to manage every NFT the owner holds in that contract.

All transfers and approvals must follow the authorization rules encoded in the deployed smart contract.

Ethereum nodes execute the transaction and verify that the resulting ownership state follows the contract and protocol rules.

What Is a Token ID?

A token ID is an unsigned integer that uniquely identifies one NFT inside an ERC-721 contract.

The same token ID can exist in several different contracts without representing the same asset.

An NFT is therefore identified by its blockchain network, contract address, and token ID together.

For example, token ID 50 in one contract is unrelated to token ID 50 in another contract.

Token IDs do not need to begin at zero or increase in a simple sequence.

A collection can use sequential IDs, randomly assigned IDs, encoded identifiers, or another system supported by its contract.

Applications should query the contract rather than assuming that every number within a range represents an existing NFT.

What Makes ERC-721 Non-Fungible?

Each ERC-721 token is tracked as an individual blockchain object.

Two NFTs from the same collection can have different metadata, histories, properties, rarity, and market values.

Ownership of one token ID does not give the holder ownership of another token ID.

A standard ERC-721 token is transferred as one complete token rather than as a decimal quantity.

Fractional economic ownership requires a separate smart contract or token structure outside the core ERC-721 standard.

Calling two NFTs non-fungible does not guarantee that they have different visual content because separate token IDs can point to similar or identical metadata.

Core ERC-721 Functions

The core standard includes functions for checking ownership, transferring NFTs, and managing transfer permissions.

The required functions include

, , , two versions of , , , , and .

ERC-721 also relies on ERC-165 interface detection.

The standard does not require a public mint function, public burn function, sale mechanism, royalty system, maximum supply, or fixed metadata policy.

These features are determined by the specific implementation or separate extensions.

The balanceOf Function

The

function returns the number of NFTs an address owns within one ERC-721 contract.

If an address owns token IDs 8, 19, and 250 from one collection, its balance is three.

The returned value does not reveal which token IDs the address owns.

The function also does not report the market value of those NFTs.

The standard requires a balance query for the zero address to fail.

Applications that need a complete token list can use event indexing or an optional enumeration extension.

The ownerOf Function

The

function returns the address currently recorded as the owner of a specific token ID.

A query for a nonexistent or invalid token must fail.

The owner address cannot be the zero address for a valid token.

The address returned by

has the core on-chain ownership and transfer rights defined by the contract.

This blockchain record does not automatically prove ownership of copyright, trademarks, physical property, or contractual benefits.

External rights must be established through the project’s legal terms and applicable law.

The transferFrom Function

The

function moves an NFT from its current owner to another address.

The caller must be the owner, the approved address for that token, or an authorized operator for the owner.

The supplied sender must match the contract’s current owner record.

The recipient cannot be the zero address.

The function does not check whether a receiving smart contract knows how to manage NFTs.

An NFT transferred to an incompatible contract through

may become inaccessible.

A safe transfer is generally preferable when the recipient is a contract.

The safeTransferFrom Functions

ERC-721 includes two versions of

.

One version accepts the sender, recipient, and token ID.

The other version also accepts a bytes field containing application-specific data.

Both versions perform the standard ownership and authorization checks.

When the recipient is a smart contract, the NFT contract calls the recipient’s

function.

The recipient must return the required selector or the complete transfer reverts.

This check reduces the chance that an NFT will be accidentally sent to a contract that cannot receive it correctly.

It does not guarantee that the recipient is safe or that the NFT can later be withdrawn.

What Is an ERC-721 Receiver?

An ERC-721 receiver is a smart contract that implements

.

The callback receives information about the operator, previous owner, token ID, and optional attached data.

A compatible receiver returns the expected selector, commonly represented as

.

An incorrect return value or reverted callback causes a safe transfer to fail.

The current ERC-721 implementation documentation includes a receiver interface and a basic receiver utility for contracts that need to accept NFTs.

A receiver should verify the NFT contract that triggered the callback before recording a deposit or granting a benefit.

ERC-721 Approvals

ERC-721 approvals let an NFT owner delegate transfer authority without transferring ownership immediately.

A token-specific approval applies to one token ID.

An operator approval applies to all NFTs owned by one address within that contract.

Approvals are recorded on-chain and can be used without another signature from the owner while they remain valid.

Users should treat NFT approval requests as sensitive financial permissions.

Approving an untrusted address can allow the approved party to transfer valuable NFTs.

The approve Function

The

function authorizes one address to transfer one specific token ID.

The owner or an approved collection-wide operator can normally grant this permission.

The approved address does not become the NFT owner.

Token-specific approval is cleared when the NFT is transferred.

An approval can also be cleared by setting the approved address to the zero address.

The owner should verify the approved address and intended token ID before signing the transaction.

The getApproved Function

The

function returns the address with token-specific approval for a valid NFT.

It normally returns the zero address when no token-specific approval exists.

The result does not include collection-wide operator permissions.

An application checking whether an account can transfer an NFT must also consider

.

The setApprovalForAll Function

The

function grants or revokes collection-wide operator authority.

An approved operator can transfer every NFT the owner currently holds in that contract.

The approval can also apply to NFTs the owner receives later from the same collection.

This permission is commonly used when an application needs to manage several NFTs.

It is much broader than approving one token ID.

A malicious operator can remove every affected NFT while the approval remains active.

Disconnecting a wallet from a website does not revoke an approval recorded on the blockchain.

The isApprovedForAll Function

The

function reports whether an operator is authorized to manage an owner’s NFTs within one collection.

The function returns either

or .

Approval in one ERC-721 contract does not grant authority over NFTs in another contract.

Users should review their active operator permissions and revoke access that is no longer necessary.

ERC-721 Events

ERC-721 defines the

, , and events.

These event logs help wallets, blockchain explorers, data indexers, and applications track NFT activity.

Events are stored in transaction receipts after successful smart contract execution.

An event should be interpreted in the context of the contract that emitted it.

A malicious contract can emit familiar event names without representing a legitimate NFT collection.

The Transfer Event

The

event records the previous owner, new owner, and token ID.

A normal NFT transfer uses nonzero sender and recipient addresses.

Minting is generally represented as a transfer from the zero address to the first owner.

Burning is generally represented as a transfer from the owner to the zero address.

The existence of a mint event does not prove that the supply is limited or that additional tokens cannot be created.

Applications can reconstruct much of an NFT’s ownership history by indexing transfer events.

The Approval and ApprovalForAll Events

The

event records permission for one specific NFT.

The

event records whether collection-wide operator authority was enabled or disabled.

These events do not indicate a change in NFT ownership.

Approval monitoring can help users and security systems detect unexpected permissions.

Revoking an approval does not reverse transfers completed while that approval was active.

ERC-165 Interface Detection

Every compliant ERC-721 contract must support ERC-165 interface detection.

The ERC-165 standard defines the

function.

The core ERC-721 interface ID is

.

A compliant contract should return

when asked whether it supports this identifier.

Optional extensions have separate interface IDs.

Interface detection helps applications avoid calling unsupported functions.

A contract’s claim of support does not prove that its implementation is correct or secure.

ERC-721 Metadata

ERC-721 includes an optional metadata extension.

The extension adds the

, , and functions.

Its ERC-165 interface ID is

.

The collection name and symbol are chosen by the contract developer and are not guaranteed to be unique.

A copied name or symbol does not make a contract part of the original collection.

The contract address remains the main technical identifier.

How tokenURI Works

The

function returns a URI associated with a valid token ID.

The URI commonly points to a JSON metadata document containing a display name, description, image, animation, and attributes.

Metadata can be stored on a traditional server, decentralized content network, or directly on-chain.

The ERC-721 standard permits metadata to change.

A project can update the URI, alter the referenced file, or change content served at an external location when its implementation and storage system permit it.

Users should check whether metadata is mutable, permanently stored, or controlled by an administrator.

Owning the NFT does not automatically preserve an external image when the hosting service disappears.

Metadata Update Events

ERC-721 itself does not provide a standardized event for every metadata change.

The optional ERC-4906 metadata update extension adds

and events.

These events tell applications that they should retrieve updated metadata for one token or a range of token IDs.

The ERC-4906 interface ID is

.

Metadata-update events improve synchronization but do not guarantee that the new metadata is accurate or permanent.

ERC-721 Enumeration

The optional enumerable extension makes NFT supplies and ownership lists discoverable through on-chain functions.

Its interface ID is

.

The extension adds

, , and .

The

function reports the number of currently valid NFTs tracked by the contract.

The index functions allow callers to retrieve token IDs from the collection or from one owner’s holdings.

Enumeration creates additional storage writes and gas costs.

Current implementation guidance notes that many contracts exclude it because of this overhead.

Off-chain applications can instead reconstruct ownership through indexed

events.

Minting ERC-721 Tokens

Minting creates a new valid token ID and assigns its first owner.

The core ERC-721 standard does not define who can mint or how minting must be requested.

A collection may allow public minting, restrict minting to authorized roles, require payment, use allowlists, or create every NFT during deployment.

A mint normally emits a

event from the zero address.

Safe minting checks whether a receiving smart contract supports the ERC-721 receiver interface.

Users should inspect maximum supply, minting authority, upgrade permissions, and administrator controls before relying on scarcity claims.

Burning ERC-721 Tokens

Burning removes an NFT from valid ownership records.

The core ERC-721 interface does not require a public burn function.

A collection can allow owners, approved operators, administrators, or protocol logic to burn tokens.

A burn normally emits a

event to the zero address.

Burning an NFT does not necessarily delete off-chain metadata or erase earlier blockchain history.

Users should confirm whether burning is permanent and whether another token with the same ID could ever be recreated under the implementation.

ERC-721 Royalties

Creator royalties are not part of the core ERC-721 standard.

The optional ERC-2981 NFT royalty standard provides a method for reporting a royalty recipient and suggested amount for a sale price.

ERC-2981 communicates royalty information but does not force every transfer or application to pay it.

A collection can define default or token-specific royalty settings when its implementation supports them.

Royalty recipients and rates may be changeable if the contract grants an administrator that authority.

Users should not assume that every ERC-721 transfer includes an enforceable creator payment.

ERC-721 vs. ERC-20

ERC-20 is designed for fungible token balances, while ERC-721 is designed for individually identified NFTs.

An ERC-20 account may hold a divisible quantity of one token.

An ERC-721 account owns distinct token IDs.

The ERC-721

function counts NFTs rather than reporting a quantity attached to one token ID.

ERC-721 does not use a standard decimals field because each NFT is normally transferred as a complete token.

The two standards also use different approval and transfer models.

ERC-721 vs. ERC-1155

ERC-721 represents individually owned token IDs through one NFT collection contract.

The ERC-1155 multi-token standard allows one contract to manage many token IDs with separate quantity balances.

An ERC-1155 token ID can represent a fungible, semi-fungible, or unique asset.

An address can own several units of one ERC-1155 token ID.

One valid ERC-721 token ID has one owner under the standard model.

ERC-1155 also supports standardized batch transfers, while ERC-721 transfers normally process one NFT at a time.

The appropriate standard depends on the project’s ownership and inventory requirements.

ERC-721 Use Cases

Digital art collections can use ERC-721 tokens to record ownership of individually identified works.

Blockchain games can use NFTs for characters, land, equipment, or other unique items.

Membership systems can use NFTs to represent access rights or community status.

Financial applications can tokenize unique debt positions, insurance policies, liquidity positions, or claims.

Event systems can issue individually identified tickets with controlled transfer rules.

Projects can connect NFTs with physical products, although the smart contract cannot independently verify possession or legal ownership of the physical item.

An ERC-721 token can also represent a credential, but sensitive personal data should not be stored openly on a public blockchain.

NFT Ownership vs. Copyright

Owning an ERC-721 token means the blockchain contract recognizes the owner address for that token ID.

It does not automatically transfer copyright in the associated artwork or media.

Copyright and commercial-use rights depend on the creator’s license, sale agreement, and applicable law.

A project may grant broad commercial rights, limited personal use, or no additional intellectual property rights.

Metadata can also reference content that the token issuer did not have permission to use.

Buyers should review the project’s legal terms rather than assuming that token ownership grants every possible right.

ERC-721 Approval Risks

Malicious approval requests are a major security risk for NFT holders.

A phishing application may request

while describing the transaction as account verification or access confirmation.

After approval, the operator can transfer the owner’s NFTs from that collection without another signature.

A token-specific approval can similarly expose one valuable NFT.

Users should inspect the contract address, operator address, permission type, and selected network before signing.

Previously granted permissions should be reviewed after interacting with an unfamiliar application.

Safe Transfer and Reentrancy Risk

A safe NFT transfer calls external code when the recipient is a smart contract.

The recipient can call back into the original application before the first operation has completely finished.

This behavior can create reentrancy vulnerabilities in minting, sales, lending, staking, escrow, or withdrawal contracts.

The official Solidity security guidance recommends completing checks and important state changes before external interactions when the intended logic allows it.

Developers should also consider cross-function reentrancy because a malicious receiver may call a different exposed function.

Receiver callbacks should be tested with hostile contracts rather than treated as simple notifications.

Metadata Security Risks

An NFT’s visible content may depend on data outside the blockchain.

An external server can become unavailable, change its response, or remove a file.

A mutable URI can point to different content after purchase.

Metadata can contain misleading descriptions, copied artwork, hidden external links, or unsafe file formats.

Decentralized storage can improve persistence, but content remains dependent on continued availability and correct identifiers.

Fully on-chain metadata reduces external hosting dependence but can increase deployment and update costs.

Contract Authenticity Risks

Anyone can deploy an ERC-721 contract with a familiar name, symbol, image, or token ID.

Interface compatibility does not prove that a collection is authentic.

Users should verify the blockchain network and complete contract address through an authoritative project source.

A verified source-code publication shows code correspondence but does not guarantee honest business conduct or secure economic design.

Token history, creator statements, administrator permissions, and metadata controls should also be reviewed.

Upgradeable ERC-721 Contracts

An ERC-721 contract may use a proxy that allows its logic to change after deployment.

Upgrades can fix bugs or add features.

They can also change minting, transfer, approval, metadata, royalty, pause, or burn behavior.

A compromised upgrade authority may install malicious logic that affects NFT ownership.

Users should identify who controls upgrades, how many signatures are required, and whether a time delay applies.

A collection described as decentralized may still contain powerful administrator roles.

How Developers Can Implement ERC-721

Developers should use a reviewed and actively maintained implementation unless a custom design is necessary.

The current ERC-721 development guide describes core implementations and optional extensions for metadata, enumeration, burning, pausing, royalties, voting, and other uses.

Minting access should match the collection’s documented supply rules.

Transfers and approvals should reject unauthorized callers and invalid addresses.

Safe minting should be used when a token can be issued directly to a smart contract.

Developers should test malicious receivers, reentrancy, invalid token IDs, approval clearing, operator permissions, burns, and interface detection.

Administrative functions should use clear access control and emit useful events.

How to Evaluate an ERC-721 NFT

The first step is to verify the network, contract address, and token ID.

The second step is to confirm that the contract supports the core ERC-721 interface.

The third step is to inspect the current owner and transfer history.

The fourth step is to review token-specific and collection-wide approvals.

The fifth step is to check how metadata and linked media are stored.

The sixth step is to identify minting, burning, pausing, freezing, and upgrade authorities.

The seventh step is to determine whether supply and rarity claims can be verified on-chain.

The eighth step is to review audits and source code without treating them as guarantees.

The ninth step is to understand which legal or commercial rights accompany the NFT.

The tenth step is to test unfamiliar contracts with a low-value transaction before risking valuable assets.

Example of an ERC-721 Transfer

Suppose Alice owns token ID 101 in an ERC-721 collection.

The contract’s

function returns Alice’s address.

Alice decides to send the NFT to a contract designed to hold NFTs securely.

Her wallet calls

with Alice’s address, the recipient contract, and token ID 101.

The ERC-721 contract checks that Alice owns the NFT and is authorized to transfer it.

The contract updates its ownership records and calls

on the recipient.

The recipient verifies the collection, operator, previous owner, and token ID.

If the correct selector is returned, the transfer completes and the NFT contract emits a

event.

If the receiver rejects the NFT, the entire transaction reverts and Alice remains the owner.

Common ERC-721 Mistakes

One common mistake is assuming that a collection name uniquely identifies an NFT.

Another mistake is granting collection-wide operator access without reviewing the operator address.

A third mistake is believing that disconnecting a wallet removes on-chain approvals.

A fourth mistake is using

to send an NFT to an unknown contract.

A fifth mistake is assuming that safe receipt guarantees a future withdrawal.

A sixth mistake is treating metadata as permanent without checking its storage method.

A seventh mistake is assuming that ERC-721 automatically enforces royalties.

An eighth mistake is assuming that every collection supports on-chain enumeration.

A ninth mistake is confusing NFT ownership with copyright or ownership of a physical asset.

A tenth mistake is treating standards compliance as proof that an NFT is authentic, valuable, or secure.

FAQ

What does ERC-721 mean?

ERC-721 is the Ethereum standard that defines ownership, transfer, approval, and interface rules for non-fungible tokens.

Is ERC-721 the same as an NFT?

ERC-721 is a technical NFT standard, while NFT is a broader term that can include tokens created under other standards.

Is ERC-721 fungible?

No, each valid ERC-721 token ID is tracked individually and can have different properties and value.

What is the ERC-721 interface ID?

The core ERC-721 interface ID is

.

What identifies an ERC-721 NFT?

An NFT is identified by its blockchain network, smart contract address, and token ID together.

What does balanceOf return?

It returns the number of NFTs an address owns within one ERC-721 contract.

What does ownerOf return?

It returns the current owner address for a valid token ID.

What is the difference between transferFrom and safeTransferFrom?

checks whether a receiving contract supports the ERC-721 receiver callback, while does not.

Can an ERC-721 NFT be sent to a smart contract?

Yes, but a safe transfer should normally be used so the recipient must confirm that it can accept the NFT.

What does approve do?

It gives one address permission to transfer one specific NFT.

What does setApprovalForAll do?

It authorizes an operator to manage every NFT the owner holds in that ERC-721 contract.

Does an operator approval expire automatically?

No, a standard operator approval remains active until the owner revokes it or custom contract logic changes its effect.

Does an NFT transfer clear its token-specific approval?

Yes, the token-specific approval is cleared when the NFT is transferred.

Is metadata required for ERC-721?

No, the metadata interface is optional, although it is implemented by most NFT collections.

Can ERC-721 metadata change?

Yes, metadata can change unless the contract and storage system provide a verifiable immutability guarantee.

Does every ERC-721 contract have totalSupply?

No,

belongs to the optional enumerable extension.

Does ERC-721 define minting?

The standard recognizes minting through ownership events but does not require a particular public mint function or supply policy.

Does ERC-721 define burning?

No, a burn function is optional and depends on the individual implementation.

Does ERC-721 enforce royalties?

No, royalties require separate logic or standards, and royalty information does not automatically force payment.

Does owning an ERC-721 token grant copyright?

No, intellectual property rights depend on the applicable license and legal agreement.

Can ERC-721 contracts be upgraded?

Some can be upgraded through proxy systems, while others are immutable after deployment.

Can an ERC-721 NFT be fractionalized?

Fractional ownership requires a separate contract or token mechanism because the core ERC-721 token is owned as one complete unit.

Can an ERC-721 approval be used to steal NFTs?

Yes, a malicious approved address can transfer the NFTs covered by its permission.

Does ERC-721 compliance prove authenticity?

No, anyone can deploy a compatible contract, so the collection address and issuer must be verified independently.

What is the main benefit of ERC-721?

Its main benefit is standardized ownership and transfer behavior that lets many crypto applications interact with unique tokenized assets.

Conclusion

ERC-721 is the primary Ethereum standard for representing individually identified non-fungible tokens.

It defines common ownership queries, transfers, approvals, operator permissions, events, and interface-detection rules.

Each NFT is uniquely identified by its blockchain network, contract address, and token ID.

The core interface ID is

.

Optional extensions can provide metadata, on-chain enumeration, royalty information, and metadata-update notifications.

The standard does not automatically define minting access, maximum supply, burning rights, royalties, metadata permanence, legal ownership, or collection authenticity.

Users should verify contract addresses, inspect approvals, review metadata storage, and understand administrator permissions before interacting with an NFT.

Developers should use maintained implementations, secure every authorization path, and treat safe-transfer receiver callbacks as potentially hostile external calls.

ERC-721 interoperability makes NFTs easier to use across crypto applications, but technical compatibility does not remove smart contract, phishing, metadata, legal, or market risks.

Understanding ERC-721 helps users distinguish blockchain ownership of a unique token from the broader content, rights, value, and promises associated with that token.