ERC-721 tracks which address owns which identifier

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

A standard for telling one token from another

EIP-721 was created on 24 January 2018 by William Entriken, Dieter Shirley, Jacob Evans and Nastassia Sachs, and later reached final status. The standard distinguishes itself from fungible interfaces directly: 'each asset is distinct (non-fungible) whereas each of a quantity of tokens is identical (fungible).' Its core guarantee is an owner mapping: an ownerOf function returns the address holding a given tokenId, and the standard states that the pair of contract address and tokenId forms 'a globally unique and fully-qualified identifier for a specific asset on an Ethereum chain.'

What ownership, in this narrow sense, means

Owning an ERC-721 token means controlling the private key that can call transferFrom or approve on that specific tokenId, nothing more and nothing less. The standard specifies transfer, approval and a Transfer event, mirroring the pattern the earlier ERC-20 standard set for fungible balances, adapted here to unique identifiers instead of interchangeable amounts. An optional metadata extension adds a tokenURI function, which the standard says 'returns a distinct Uniform Resource Identifier... for a given asset,' typically pointing to a JSON file describing a name, a description and an image. The standard requires that this URI exist as a pointer; it does not require anything about what the pointer resolves to.

The gap between the identifier and the asset

This is the load-bearing distinction the standard leaves open: tokenId and ownerOf are enforced by the Ethereum network itself, verifiable by any node running the chain. tokenURI is a string the contract's deployer chose to store, and by default nothing in EIP-721 constrains what that string points to, how long it stays reachable, or whether its contents can be changed after the token was sold. A buyer acquires a cryptographically enforced claim to an identifier; whatever that identifier is supposed to represent is a separate, and separately checkable, claim, one the ethereum.org documentation itself does not resolve.

• Does the contract's tokenURI point to content that is itself content-addressed, or to a mutable location the deployer or a third party can change?
• Is the uniqueness being marketed the tokenId's uniqueness, guaranteed on-chain, or the uniqueness of the artwork it references, which the standard does not guarantee?
• Who controls the server or storage location the tokenURI resolves to, and what happens to that pointer if they stop maintaining it?

ERC-721 solved a real problem: giving each of many similar-looking tokens a distinct, network-verified owner. It solved nothing about what those tokens point to, which is precisely the question a metadata extension raises without answering.