Skip to content
Financial Context Wiki

ERC-721

ERC-721 is an Ethereum interface for non-fungible tokens (NFTs): each token is identified separately, with ownership and transfer rules tracked by a smart contract.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

ERC-721 is a standard interface for non-fungible tokens on Ethereum. Instead of one interchangeable balance, an ERC-721 contract tracks individual tokens by tokenId, exposes their owners, and defines how they can be transferred or authorized. The token is identified by the pair of the contract address and tokenId; the standard does not by itself establish the asset’s price, authenticity, scarcity, or legal rights.

ERC-721 is different from ERC-20 because ERC-20 units are fungible: one unit is intended to be interchangeable with another. ERC-721 tokens can belong to the same collection while still having different identifiers and metadata. A wallet or marketplace can support both standards, but the transfer and approval calls are different.

The practical question is not whether a project says “ERC-721”, but what its contract and surrounding systems actually do. Check the implementation, permissions, metadata, marketplace authorization, liquidity, and the rights promised to holders before treating an NFT as an asset.

How it works

Identity and ownership

The contract records an owner for each existing tokenId. ownerOf returns that address and balanceOf counts how many tokens an address owns. A mint normally creates a new identifier and emits a Transfer event from the zero address; a burn commonly emits a transfer to the zero address. These events are useful for indexing, but the contract’s state is the authority.

Transfers and approvals

The owner can call transferFrom directly, or authorize one address for one token with approve. setApprovalForAll authorizes an operator for every token that the owner holds in that collection, which is convenient for marketplaces but creates a broad permission. An operator should be checked by contract address, and stale approvals should be revoked on-chain. A signed marketplace order is separate from an on-chain approval: canceling one does not necessarily cancel the other.

safeTransferFrom additionally checks whether a contract recipient implements IERC721Receiver. That check helps prevent a token from being sent to a contract that cannot receive it; transferFrom does not perform the recipient callback. Neither function guarantees that a marketplace, bridge, or wallet will handle the token correctly.

Metadata and royalties

The optional metadata extension exposes tokenURI, which may point to data stored on-chain or elsewhere. A mutable base URI, upgradeable contract, administrator, or centralized hosting service can change what a token displays after minting. Permanent storage and decentralized storage reduce some dependencies but do not prove authorship, provenance, or intellectual-property ownership.

ERC-721 does not require secondary markets to pay creator royalties. A collection may implement the optional EIP-2981 royalty interface, but a marketplace can choose whether to honor it, and the interface does not settle or enforce payment. Supply limits, randomness, artwork authenticity, trademark licenses, and other promises must be checked separately in code, distribution rules, and legal documents.

Example

Suppose a contract mints token #42 to Alice. The token is not globally identified by 42 alone: its collection contract address is part of the identity. Alice can list it on a marketplace by granting approve for that token or setApprovalForAll for the marketplace operator. When the sale executes, the marketplace calls a transfer function, and the contract checks ownership and authorization. Alice should later revoke a collection-wide approval if she no longer needs it.

The image shown by the marketplace is a separate metadata question. Alice must inspect the collection’s tokenURI behavior, update permissions, hosting arrangement, and license instead of assuming that possession of the token transfers copyright or commercial-use rights.

Risks

  • Contract risk: a bug, malicious upgrade, privileged administrator, or incorrect transfer hook can lock or move tokens.

  • Authorization risk: a collection-wide setApprovalForAll or a compromised marketplace can move every approved token in that collection.

  • Metadata and legal risk: off-chain files can disappear or change, and token ownership does not automatically grant copyright, trademark, or other legal rights.

  • Market risk: NFT prices can be volatile, liquidity can be thin, and a quoted floor price may not be executable for a particular token.

On-chain actions are generally irreversible. Verify the collection contract, recipient address, approvals, metadata controls, and transaction details before signing; treat claims from promoters or communities as claims to verify, not as guarantees.

Common misconceptions

Myth 1: ERC-721 guarantees scarcity

It distinguishes tokens within a contract. The issuer may mint more tokens, deploy similar collections, or make multiple identifiers refer to equivalent media. Scarcity depends on supply rules and the permissions that enforce them.

Myth 2: The NFT includes all intellectual-property rights

The blockchain records a token transfer. Copyright, reproduction, commercial use, adaptation, and trademark rights depend on the collection’s license and applicable law; they cannot be inferred from ownerOf.

Myth 3: Canceling a marketplace listing removes every permission

A listing, its signature and expiry, and an on-chain approve or setApprovalForAll are separate states. Check and revoke the on-chain permission independently when it is no longer needed.

Sources

Navigation

Search the wiki...