How ERC-721 (NFT) Tokens Work

The term "NFT" became synonymous with speculative digital art during 2021 and 2022, which obscured what's actually happening at the technical level. An NFT isn't a category of asset — it's an instance of a specific token standard called ERC-721. Understanding the standard reveals what NFTs actually are and, more usefully, what they're not.

ERC-721 and ERC-20 both live on Ethereum, but they solve opposite problems. ERC-20 tokens are fungible: every USDC is identical to every other USDC, so the contract only needs to track balances per address. ERC-721 tokens are non-fungible: each token has a unique identifier, and the contract tracks ownership per token ID, not per account balance. The distinction is structural, not cosmetic — and it has real consequences for how the tokens behave.

The Core Mechanism

An ERC-721 contract maintains a mapping from token IDs to addresses. Specifically, mapping(uint256 => address) for ownership. When you "own" an NFT, what's actually true is that your address appears as the value for that token's ID in that mapping on-chain. Ownership is a storage slot in a smart contract.

The standard defines a small set of required functions:

• ownerOf(tokenId) — returns the address currently holding the token
• balanceOf(address) — returns how many tokens from this contract a given address holds
• transferFrom(from, to, tokenId) — moves a token, but performs no safety check on the recipient
• safeTransferFrom(from, to, tokenId) — same transfer, but if the recipient is a contract, it must implement onERC721Received() or the transfer reverts

That last distinction matters more than it sounds. The transferFrom function can send a token to a smart contract that has no mechanism to handle it, locking it permanently. safeTransferFrom prevents that by requiring the receiving contract to explicitly confirm it can process ERC-721 tokens. Most modern protocols use safeTransferFrom, but the standard includes both — and which one gets called is at the caller's discretion.

Approval mechanics follow a two-level structure. approve(address, tokenId) grants a single address permission to transfer one specific token. setApprovalForAll(operator, bool) grants (or revokes) permission for an operator to transfer all tokens you hold from that contract. NFT marketplaces typically request setApprovalForAll so they can list and execute sales without per-token approval transactions. This is efficient, but it means a single compromised or malicious marketplace approval can expose your entire NFT holdings from that contract — the same structural risk as unlimited approvals in ERC-20.

The Metadata Problem

ERC-721 includes an optional but near-universal Metadata Extension, which adds a tokenURI(tokenId) function. This returns a URI — typically a URL pointing to a JSON file describing the token: name, description, image, attributes.

The token itself lives on-chain. The metadata almost never does.

Most NFT collections store metadata on IPFS (a content-addressed peer-to-peer network), a centralized server, or Arweave (a pay-once permanent storage protocol). The image referenced in the JSON is similarly off-chain. What the blockchain record proves is that you own token ID 4521 from contract 0xabc... — but whether that token ID still resolves to its original image depends entirely on where the metadata is hosted and whether it's being actively maintained.

If the IPFS node pinning a collection's metadata goes offline and no one preserves it, the token becomes an entry in a contract pointing to a broken link. This isn't theoretical — it's happened to real collections. Some projects have addressed it directly: fully on-chain SVG rendering (stored in contract storage, expensive but permanent), Arweave with upfront funding, or IPFS with decentralized pinning through services like Filecoin-backed pinning. But most haven't.

The smart contract is immutable. The metadata it points to is not necessarily permanent. These are two separate systems, and conflating them is one of the more common misconceptions about what "owning" an NFT actually means.

Where Constraints Live

The ERC-721 standard places very few constraints on issuers. Any contract can claim ERC-721 compliance, mint arbitrary quantities, omit royalty logic, and define whatever metadata structure it wants. The standard doesn't govern supply caps, royalty enforcement, metadata permanence, or whether the contract itself is upgradeable via a proxy.

What the standard does enforce is the ownership interface. The functions above must behave as specified. Everything else is implementation discretion.

Gas economics impose a practical constraint: each token transfer is a distinct on-chain operation touching individual contract storage slots. At scale, this is meaningfully more expensive than ERC-20 operations, which manipulate simple integer balances. ERC-1155 — a hybrid standard supporting both fungible and non-fungible tokens in a single contract — emerged partly to address this overhead for gaming assets and other high-volume use cases.

What's Changing

A few structural developments are worth tracking.

ERC-6551 (Token-Bound Accounts), deployed mid-2023, gives each ERC-721 token its own smart contract account. A token can hold other assets, sign transactions, and accumulate on-chain history. This changes NFTs from passive ownership records to active agents — with implications for identity, gaming, and DeFi. Adoption is real but still early.

ERC-2981 (Royalty Standard) provides a standardized royaltyInfo() function that marketplaces can query to calculate creator royalties. It doesn't enforce payment — it's a read interface. Whether marketplaces honor it is a separate question. After the royalty enforcement debates of 2022-2023, where several major marketplaces reduced or eliminated royalty enforcement to compete for volume, this tension remains structurally unresolved.

ERC-4907 (Rental Standard) adds a setUser() function that distinguishes between an owner and a temporary user with a time-bound expiry. This enables rental markets without requiring token transfer. Adoption is growing in blockchain gaming and utility NFT contexts.

Confirmation Signals

ERC-6551 adoption expanding beyond initial experiments into gaming, identity, and DeFi infrastructure. On-chain metadata solutions (SVG rendering, Arweave with verifiable funding) becoming standard practice in new collections where permanence matters. ERC-4907 integration in gaming protocols at scale.

Invalidation

A successor standard displacing ERC-721 as the dominant 1:1 NFT interface — ERC-1155 has done this partially for gaming assets but hasn't replaced ERC-721 for digital art and PFP collections. Cross-chain NFT standards gaining enough adoption to fragment EVM-native NFT infrastructure. Regulatory treatment of NFTs that materially changes the issuance or custody model.

Timing Perspective

Now: ERC-721 is the operative standard across essentially all EVM chains. The ownership and transfer mechanics described above are what's running in every major NFT collection.

Next: ERC-6551 token-bound accounts are in active development and deployment — worth understanding before they become widespread infrastructure.

Later: On-chain metadata solutions and cross-chain NFT interoperability remain directional. Not yet consequential for most use cases.

Boundary Statement

This post explains ERC-721 as a technical mechanism. It doesn't address the economic properties of any specific NFT collection, the legal status of NFT ownership across jurisdictions, or the investment characteristics of digital collectibles. Standard compliance says nothing about supply controls, the permanence of what the contract points to, or the trustworthiness of the issuer.

The mechanism is defined. What gets built on top of it varies considerably.