ERC-721 Interface

What Is the ERC-721 Interface?

The ERC-721 interface is a standardized set of smart contract functions and events used to represent and transfer non-fungible tokens on Ethereum and compatible blockchain networks.

A non-fungible token, or NFT, represents a uniquely identified token rather than an interchangeable quantity of identical units.

The official ERC-721 specification defines how wallets, applications, smart contracts, and blockchain tools can check NFT ownership and perform standardized transfers.

The interface does not determine what an NFT represents, how valuable it is, or whether its linked content is authentic.

It defines a common technical language that different crypto applications can use when interacting with NFT contracts.

The ERC-721 standard reached Final status in the Ethereum Improvement Proposal process and remains one of the main standards for unique blockchain assets.

ERC-721 can be used for digital collectibles, game items, membership credentials, virtual land, event tickets, domain-like assets, financial positions, and tokenized records.

Why Is an Interface Important?

A smart contract interface describes the external functions and events that compatible software expects a contract to provide.

Without a shared interface, every NFT project could use different function names and transfer rules.

Wallets and decentralized applications would then need custom code for every collection.

The ERC-721 interface allows software to call familiar functions such as

, , , and .

It also standardizes events that allow off-chain systems to track NFT transfers and approvals.

A contract can add extra functions beyond ERC-721 while retaining compatibility with the core standard.

Interface compliance improves interoperability, but it does not guarantee that the contract is secure or that every application supports its custom features.

What Makes an ERC-721 Token Non-Fungible?

Each ERC-721 token has a unique unsigned integer called a token ID.

The token is fully identified by the combination of its blockchain network, contract address, and token ID.

Token ID 100 in one contract is unrelated to token ID 100 in another contract.

The standard does not require token IDs to begin at zero, increase in order, or follow a predictable pattern.

Applications should treat every token ID as an opaque identifier rather than guessing which IDs exist.

Each valid token ID has one owner at a time under the core ERC-721 ownership model.

An NFT can be transferred as one complete token, while fractional ownership requires a separate contract or token structure outside the basic interface.

Core ERC-721 Interface ID

The ERC-721 core interface is identified through ERC-165 by the value

.

A compatible contract should return

when is called with this identifier.

The ERC-165 interface detection standard calculates an interface identifier by applying XOR to the function selectors included in that interface.

ERC-165 allows an application to ask a contract which standardized interfaces it claims to support before attempting an interaction.

A positive response is useful for compatibility checks, but it does not independently prove that every function is implemented correctly.

Applications handling valuable assets may also need code review, testing, and transaction simulation.

Core ERC-721 Functions

The required ERC-721 interface includes ownership queries, transfer functions, and approval-management functions.

The main functions are

, , , , , , , and .

A compliant implementation must follow the standard’s required behavior, including authorization checks and failure conditions.

Minting, burning, royalties, supply limits, pricing, and collection administration are not fully defined by the core interface.

Projects usually add separate logic for those features.

The balanceOf Function

The

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

It does not return a divisible token quantity or the financial value of the NFTs.

If an address owns token IDs 4, 19, and 83 from the same collection, its balance is three.

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

The function does not reveal which specific token IDs the address owns.

Finding those IDs may require transfer-event indexing or the optional enumerable interface.

The ownerOf Function

The

function returns the current owner of a specific token ID.

The returned owner must not be the zero address for an existing token.

A query for an invalid or nonexistent token must fail under the standard.

Ownership recorded by the contract controls the core transfer rights associated with that NFT.

It does not necessarily prove ownership of copyright, trademarks, physical property, or other legal rights.

Those rights depend on the project’s agreement, applicable law, and external records.

The transferFrom Function

The

function transfers an NFT from one address to another after checking authorization and ownership.

The caller must be the owner, the specifically approved address, or an approved operator for the owner.

The

address must match the NFT’s current owner.

The recipient cannot be the zero address.

This function does not require a receiving smart contract to confirm that it can handle NFTs.

An NFT sent with

to an incompatible contract may become permanently inaccessible.

Users and developers should generally prefer a safe transfer when sending an NFT to an unknown contract.

The safeTransferFrom Functions

ERC-721 defines two overloaded versions of

.

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

The other version adds a bytes field that can carry application-specific data.

Both functions perform the normal ownership and authorization checks.

If the recipient is a smart contract, the transfer process calls

on that contract.

The recipient must return the expected selector or the entire transfer reverts.

This receiver check reduces the chance of sending an NFT to a contract that cannot manage it.

It does not prove that the receiving contract is trustworthy or that the NFT can later be withdrawn.

What Is IERC721Receiver?

is the interface that a smart contract implements when it wants to accept NFTs through .

Its required function is

.

The function receives the operator, previous owner, token ID, and optional data.

A successful receiver returns its function selector, commonly represented as

.

An incorrect return value or reverted call causes the safe transfer to fail.

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

A receiver should verify which NFT contract called it before using the callback to update important accounting.

ERC-721 Receiver Callback Risk

A safe transfer to a contract creates an external call to that recipient.

The recipient can execute additional code before the original transaction finishes.

This creates a potential reentrancy path when the sending application has not completed its internal state updates.

A malicious receiver may attempt to call another function in the original contract during the callback.

Solidity’s smart contract security guidance recommends completing checks and important state effects before making external interactions when the intended design permits it.

Developers should test safe NFT transfers against malicious receiver contracts rather than assuming the callback is harmless.

The approve Function

The

function gives one address permission to transfer one specific NFT.

The token owner or an authorized operator can normally grant this approval.

The approved address does not become the owner.

It receives authority to transfer the identified token ID.

A token-specific approval is generally cleared when the NFT is transferred.

Calling

with the zero address can clear an existing approval.

Users should verify the approved address because an attacker with valid approval can transfer the NFT without another signature from the owner.

The getApproved Function

The

function returns the address currently approved for one token ID.

If no address has token-specific approval, it normally returns the zero address.

The function applies only to a valid existing NFT.

It does not report operator approval covering an owner’s entire collection balance.

Applications should also check

when determining whether another address can transfer the token.

The setApprovalForAll Function

The

function authorizes or removes an operator for every ERC-721 token owned by the caller within that contract.

An approved operator can transfer existing NFTs and NFTs the owner later receives from the same collection.

This permission is broader than approval for one token ID.

It is commonly used when an application needs to manage several NFTs without requesting a separate approval for each one.

A malicious operator can transfer all affected NFTs while the permission remains active.

Wallets should clearly display the collection address and the scope of the operator approval.

The isApprovedForAll Function

The

function reports whether an operator has collection-wide authority for a particular owner.

It returns a Boolean value rather than a token amount.

Operator authority applies only within the ERC-721 contract that granted it.

An approval in one NFT collection does not automatically apply to another collection.

Users should periodically review active operator permissions and revoke those they no longer need.

ERC-721 Events

The core ERC-721 interface defines

, , and events.

These event logs allow wallets, indexers, analytics systems, and blockchain explorers to track standardized NFT activity.

Events help off-chain software reconstruct ownership and permission history.

A contract event is evidence of what the contract emitted during execution, but applications should still confirm that the transaction succeeded and came from the expected contract.

The Transfer Event

The

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

Normal transfers include nonzero sender and recipient addresses.

Minting is commonly represented by emitting a transfer from the zero address to the first owner.

Burning is commonly represented by emitting a transfer from the owner to the zero address.

The ERC-721 interface does not define public mint or burn functions, even though these event patterns support lifecycle tracking.

An event showing that an NFT was minted does not prove that the collection has a fixed supply or restricted minting authority.

The Approval Event

The

event records approval for one token ID.

It identifies the owner, approved address, and token ID.

Applications can use it to track changes in token-specific transfer authority.

The event should not be confused with an ownership transfer because the owner remains unchanged.

The ApprovalForAll Event

The

event records whether an owner enabled or disabled an operator.

It includes the owner, operator, and approval status.

Monitoring this event is important because one operator approval can affect every NFT the owner holds in that collection.

A revoked event does not reverse transfers already performed while the authorization was active.

Optional ERC-721 Metadata Interface

The metadata extension adds

, , and .

Its ERC-165 interface ID is

.

The extension is optional under the official specification, although many NFT contracts implement it.

The

function returns the collection’s descriptive name.

The

function returns a short identifier chosen by the contract developer.

The

function returns a URI associated with a specific token ID.

Collection names and symbols are not unique, so they should not be used as the only authenticity check.

How tokenURI Works

The

function typically points to a JSON metadata document.

The document may contain fields such as a display name, description, image location, animation, and project-specific attributes.

The URI can use an HTTPS address, decentralized content identifier, or an on-chain data URI.

The official ERC-721 standard allows metadata to be mutable.

This means the content displayed for an NFT may change after minting unless the contract or project provides stronger immutability guarantees.

The current ERC-721 development guide notes that off-chain metadata can be changed by the party controlling its storage location.

Ownership of the token does not automatically guarantee permanent availability of an external image or file.

Optional ERC-721 Enumerable Interface

The enumerable extension allows applications to discover token IDs through on-chain queries.

Its ERC-165 interface ID is

.

It adds

, , and .

The

function returns the number of currently valid tokens tracked by the contract.

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

Enumeration is optional because maintaining additional ownership indexes increases storage writes and gas consumption.

Many applications instead reconstruct NFT holdings from

events using off-chain indexing.

Minting and Burning

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

Each project decides whether minting is open, restricted, scheduled, capped, or permanently disabled.

The standard also does not require a public burn function.

A burn removes a token from valid ownership records according to the contract’s implementation.

Users should examine who can mint or burn NFTs and whether an administrator can affect tokens held by other accounts.

A compliant transfer interface does not prove that the token supply is fixed.

ERC-721 Interface vs. ERC-721 Implementation

The interface defines the external behavior required for compatibility.

An implementation contains the actual storage, authorization, transfer, minting, metadata, and administration logic.

Two contracts can support the same ERC-721 interface while using very different internal designs.

One implementation may be immutable, while another may operate through an upgradeable proxy.

One may have a fixed supply, while another allows an administrator to mint indefinitely.

One may store metadata on-chain, while another points to a changeable server.

Users should review the implementation rather than treating interface support as a complete security assessment.

ERC-721 vs. ERC-20

ERC-20 represents fungible balances, while ERC-721 represents individually identified tokens.

An ERC-20 account can hold a divisible quantity such as 250 units.

An ERC-721 account owns a count of distinct token IDs.

The ERC-721

function reports how many NFTs an account owns rather than the quantity of one token ID.

ERC-721 does not require a decimals field because each token is normally transferred as one complete unit.

Approvals also differ because ERC-721 supports approval for one token or operator control over a collection.

ERC-721 vs. ERC-1155

ERC-721 focuses on individually identified non-fungible tokens.

ERC-1155 allows one contract to manage many token IDs, including fungible, semi-fungible, and non-fungible assets.

An ERC-1155 account can hold several units of one token ID.

An ERC-721 token ID has one owner and does not maintain a quantity balance for each account.

The best standard depends on the asset model, transfer patterns, batch-operation needs, and application requirements.

Royalties and the ERC-721 Interface

The core ERC-721 interface does not define creator royalties.

A separate royalty interface can communicate a suggested payment recipient and amount.

Royalty information does not automatically force every transfer system to make the payment.

A collection claiming royalties should explain how the information is calculated and whether it can change.

Users should not assume that an ERC-721 NFT includes permanent or enforceable royalty rights.

Security Risks of ERC-721 Approvals

Approval phishing is one of the most important risks for NFT holders.

A malicious website may request

while describing the signature as account verification or collection access.

After approval, the operator may transfer every affected NFT without another authorization from the owner.

A token-specific approval can also permit theft of the identified NFT.

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

Disconnecting a wallet from a website does not revoke an approval already recorded on-chain.

Unsafe Transfer Risk

The

function can send an NFT to a contract that lacks a recovery mechanism.

The transaction can succeed even though nobody can later make the recipient contract transfer the NFT back out.

This problem is why

is preferred for transfers to contracts.

However, safe receipt only proves that the contract returned the expected callback value.

It does not guarantee that the recipient has a legitimate withdrawal path.

Metadata and Authenticity Risks

Anyone can deploy an ERC-721 contract using a familiar collection name or symbol.

The contract address is the most important technical identifier for a collection.

Metadata can also contain misleading names, copied artwork, unsafe external links, or unavailable files.

A token URI controlled by a project administrator may later point to different content.

On-chain ownership does not independently verify the creator’s identity or intellectual property rights.

Users should confirm the collection address and project information through authoritative sources.

Upgradeable Contract Risk

An ERC-721 implementation may operate behind an upgradeable proxy.

An authorized administrator may be able to change transfer rules, metadata logic, minting rights, or other behavior after users acquire NFTs.

Upgrades can repair bugs but also create governance and key-compromise risks.

Users should inspect upgrade permissions, time delays, multisignature controls, and administrator roles.

ERC-721 interface support does not reveal every privileged function in the implementation.

How Developers Should Implement ERC-721

Developers should begin with a reviewed and actively maintained implementation rather than rewriting sensitive ownership logic without a strong reason.

The current OpenZeppelin ERC-721 API provides core, metadata, enumerable, pausable, burnable, royalty, voting, and receiver-related components.

Minting access should be restricted according to the collection’s documented supply policy.

Safe minting should be considered when NFTs can be minted directly to smart contracts.

Receiver callbacks should be treated as external calls with possible reentrancy behavior.

Tests should cover ownership, approvals, operator permissions, safe receivers, malicious receivers, burns, invalid token IDs, and unauthorized transfers.

Developers should also test whether interface detection returns the correct values for every implemented extension.

How Applications Can Detect ERC-721 Support

An application can call

with the core ERC-721 interface ID.

A return value of

indicates that the contract claims to implement the interface.

The application can separately check the metadata or enumerable interface IDs.

Interface detection is more reliable than guessing from function names alone.

However, badly written or deceptive contracts can return inaccurate information.

Applications should handle failed calls and unexpected behavior safely rather than assuming every contract is compliant.

Example of an ERC-721 Transfer

Suppose Alice owns token ID 42 in an ERC-721 contract.

The contract’s

function returns Alice’s address for token ID 42.

Alice decides to send the NFT to a smart contract.

Her wallet calls

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

The NFT contract verifies that Alice owns the token and is authorized to transfer it.

It updates ownership and calls

on the recipient.

The recipient checks the NFT contract, operator, previous owner, and token ID.

If the recipient returns the correct selector, the transfer completes and a

event is emitted.

If the recipient rejects the callback, the entire transaction reverts and Alice remains the owner.

Common ERC-721 Interface Mistakes

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

Another mistake is treating

as the quantity of one token ID.

A third mistake is using

when sending to an unknown smart contract.

A fourth mistake is granting collection-wide operator approval without reviewing the operator address.

A fifth mistake is assuming that disconnecting a wallet revokes on-chain approvals.

A sixth mistake is treating metadata as permanently stored on-chain without checking the token URI.

A seventh mistake is assuming that ERC-721 includes mandatory royalties.

An eighth mistake is assuming that every ERC-721 contract supports enumeration.

A ninth mistake is ignoring reentrancy during the receiver callback.

A tenth mistake is treating ERC-165 support as proof that the implementation is secure or authentic.

FAQ

What is the ERC-721 interface?

The ERC-721 interface is a standardized set of functions and events for tracking ownership, approvals, and transfers of non-fungible tokens.

What is the ERC-721 interface ID?

The core ERC-721 interface ID is

.

What does balanceOf return for an ERC-721 contract?

It returns the number of distinct NFTs from that contract owned by an address.

What does ownerOf do?

It returns the current owner of 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.

What is onERC721Received?

It is the callback a smart contract implements to confirm that it can accept an NFT through a safe transfer.

Can a safe NFT transfer fail?

Yes, it fails when authorization checks fail or when a receiving contract does not return the expected callback selector.

What does approve do?

It authorizes one address to transfer one specific NFT.

What does setApprovalForAll do?

It gives an operator authority over all NFTs the caller owns in that ERC-721 contract.

Does an operator approval expire automatically?

No, a standard collection-wide approval remains active until the owner revokes it or the contract applies additional custom rules.

Does transferring an NFT clear its token-specific approval?

Yes, a normal ERC-721 implementation clears the approval associated with that token during transfer.

Is metadata required by ERC-721?

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

What is the ERC-721 metadata interface ID?

The metadata extension uses interface ID

.

What is the ERC-721 enumerable interface ID?

The enumerable extension uses interface ID

.

Does every ERC-721 contract support totalSupply?

No,

belongs to the optional enumerable extension.

Does ERC-721 require a mint function?

No, the core interface does not define how users or administrators mint NFTs.

Does ERC-721 require a burn function?

No, burning is an implementation feature rather than a required core function.

Does ERC-721 enforce royalties?

No, royalties are outside the core ERC-721 interface and require separate logic or standards.

Can ERC-721 metadata change?

Yes, the standard permits a mutable token URI unless the implementation provides stronger immutability guarantees.

Does ERC-721 compliance prove that an NFT is authentic?

No, anyone can deploy a compatible contract, so users must verify the contract address and issuer independently.

Conclusion

The ERC-721 interface provides the common ownership, approval, transfer, and event rules used by non-fungible tokens across Ethereum-compatible applications.

Its core interface ID is

, which contracts publish through ERC-165 interface detection.

The required functions allow applications to check balances and owners, approve transfer authority, and move unique token IDs.

The safe transfer functions reduce accidental transfers to incompatible contracts by requiring an ERC-721 receiver callback.

That callback also creates an external-call and reentrancy risk that developers must handle carefully.

Metadata and enumeration are optional interfaces with separate identifiers and additional gas or trust considerations.

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

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

Developers should use maintained implementations, test every authorization path, and treat NFT receiver callbacks as potentially hostile code.

Understanding the ERC-721 interface helps crypto users distinguish standardized NFT compatibility from the broader economic, legal, and security properties of an individual collection.