ERC-721 is the Ethereum standard for non-fungible tokens (NFTs). It defines an API that lets smart contracts represent tokens that are unique and can carry different value from one another, even inside the same contract. For founders building on NFTs, the practical takeaway is that the standard handles identity and transfer mechanics, not pricing, demand or business model.
What the standard actually defines
According to the Ethereum developer documentation, the ERC-721 (Ethereum Request for Comments 721) was proposed by William Entriken, Dieter Shirley, Jacob Evans and Nastassia Sachs in January 2018. It is a Non-Fungible Token Standard that implements an API for tokens within smart contracts.
The functionality it provides is operational, not commercial. It covers transferring tokens from one account to another, reading the current token balance of an account, fetching the owner of a specific token, and reporting the total supply available on the network. It also supports approving an amount of tokens from an account to be moved by a third-party account.
A smart contract that implements the required methods and events can be called an ERC-721 Non-Fungible Token Contract. Once deployed, that contract is responsible for keeping track of the created tokens on Ethereum.
Why uniqueness is the core idea
A Non-Fungible Token is used to identify something or someone in a unique way. The documentation frames this as the reason ERC-721 exists: an NFT is unique and can have different value than another token from the same smart contract, perhaps because of age, rarity or something visual.
The mechanical foundation is a uint256 variable called tokenId. For any ERC-721 contract, the pair of contract address and uint256 tokenId must be globally unique. That pairing is what gives each token its addressable identity.
Everything a user sees is built on top of that identifier. A dapp can act as a converter that takes the tokenId as input and outputs an image of something cool, such as zombies, weapons, skills or collectible animals. The standard does not store the image; it anchors the identity that a dapp maps to content.
Where NFTs fit as products
The documentation lists platform use cases: collectible items, access keys, lottery tickets, and numbered seats for concerts and sports matches. These share a trait worth noting for founders. Each use depends on a token being singular and distinguishable, whether the value comes from scarcity, utility or a specific claim on an event.
Two named examples illustrate different models. CryptoKitties is described as a game centered on breedable, collectible creatures. Sorare is described as a global fantasy football game where users collect limited-edition collectibles, manage teams and compete to earn prizes. In both cases the token standard is infrastructure; the game design and the collectible supply sit in the application layer.
Inspection and interoperability
The documentation argues that a shared standard makes contracts simple to inspect. It notes that only the Contract Application Binary Interface (ABI) is needed to create an interface to any ERC-721 token, and that a simplified ABI can keep an example low-friction. The example setup references installing the Web3.py Python library.
It also notes that the CryptoKitties contract has some interesting events beyond the standard ones, and points to an NFT tracker that lists top NFTs on Ethereum by transfer volume. The useful lesson for teams is that standard compliance gives baseline compatibility, while custom events and off-standard features are where projects differentiate and where inspection needs care.
A worked example of the identity model
| Element | What it holds | Why it matters |
|---|---|---|
| Contract address | The deployed contract on Ethereum | Identifies the collection or system |
| tokenId | A uint256 number | Identifies the token inside that contract |
| The pair | Contract address + tokenId | Must be globally unique |
| Dapp layer | Converter using tokenId as input | Turns identity into an image or experience |
Hypothetical: suppose two projects each mint a token with the uint256 value 1. The tokens are still distinct because the contract addresses differ. Now suppose a single project mints tokenId 1 twice. That would break the global uniqueness rule, because the pair of the same contract address and the same tokenId would no longer be unique. This is a design constraint, not a statement about market value.
Checklist for founders reading an ERC-721 contract
- Confirm which required methods and events are implemented before calling it an ERC-721 contract.
- Check whether custom events or extra functions exist beyond the standard, as the documentation notes for CryptoKitties.
- Verify that tokenId assignment respects global uniqueness for the contract-tokenId pair.
- Separate what the standard guarantees (ownership, balances, transfers, approvals, total supply) from what your product layer must deliver (content, utility, access rules).
- Treat transfer volume trackers as activity signals, not as evidence of value.
Timeline and status of the standard
The proposal dates to January 2018 by the four named authors. The documentation describes ERC-721 as a standard that implements an API for tokens within smart contracts and that, once deployed, contracts are responsible for tracking created tokens on Ethereum. These are descriptive statements about the specification, not announcements of product launches or approvals.
What the source does not say
The documentation does not establish any price, valuation, market size or return expectation for NFTs or for any project using ERC-721. It does not describe royalty mechanics, minting economics, gas costs, or business sustainability. It does not state that any listed use case has been commercially successful. It does not provide a publication date or describe later revisions to the standard. Nothing in the source should be read as investment guidance.