NFTs

In brief

Fungible tokens are interchangeable: one unit is as good as another. Non-fungible tokens are distinguishable. On Ethereum, ERC-721 defines a standard interface for unique token IDs; ERC-1155 lets one contract mix fungible, non-fungible and semi-fungible IDs. Ownership in the token contract is not ownership of the underlying copyright or of a file on a server. Metadata often lives off-chain at a URI. Royalties are not universally enforced. Other chains use different models — on Solana, the Token Program uses mint accounts and token accounts rather than ERC-721 contracts.

Fungible versus non-fungible

ethereum.org’s NFT page puts the contrast cleanly. You do not care which specific dollar or which specific ETH you hold. You do care which specific NFT you hold, because each one has its own ID and, usually, its own metadata.

ERC-721’s abstract says the same thing in standards language: NFTs are distinguishable; you must track ownership of each one separately. The standard considered houses, unique digital collectibles, and even “negative value” assets such as obligations. The identifying pair on Ethereum is (contract address, tokenId). The ID is a uint256 that must not change for the life of the contract.

A token with supply 1 is not automatically an NFT in the ERC-721 sense. Some “limited edition” projects are many separate fungible contracts. ERC-721 exists so wallets and marketplaces can speak one interface.

What the token actually is

On Ethereum, an NFT is usually an entry in a contract: ownerOf(tokenId) returns an address. Transfer functions move that mapping. Optional metadata (tokenURI) returns a URI that may point to JSON describing name, description and an image URL.

That on-chain object is a record. It is not, by itself:

• the JPEG;
• the copyright;
• a legal deed to a house (unless some legal system separately says so);
• a guarantee that the URI still works next year.

ERC-721’s own metadata discussion allows the URI to be mutable. The example in the standard is a house whose occupants and photos change. Mutability is a choice of the contract author.

Ownership of the token versus ownership of the work

Buying an NFT typically moves the token record to your address. Copyright is a legal right. It transfers when a contract (in the legal sense) or a statute says it does — not when safeTransferFrom succeeds.

Creators can license work to token holders in off-chain terms. They can also keep the copyright and sell only a collectible. Marketplaces often blur this. This article does not.

The same gap exists for “real-world” claims. An NFT can represent a ticket or a membership. Whether a venue honors it is a venue policy.

Metadata: on-chain, off-chain, and the permanence myth

ERC-721’s optional metadata extension returns a URI, often to JSON that itself points to an image. That JSON may live on:

• a company server (can vanish or change);
• IPFS or another content-addressed system (more durable if someone keeps pinning the content);
• fully on-chain (expensive; used by some projects).

ERC-1155’s optional metadata URI extension similarly specifies JSON and allows {id} substitution so many IDs can share one template.

If the image is on a server the author controls, the NFT can keep the same tokenURI while the bytes at that URL change. If nobody pins an IPFS CID, the CID still names the bytes but the bytes may be unavailable. The chain stores the pointer more reliably than it stores the picture.

Permanence of the record is the usual blockchain kind: expensive to rewrite, not magically eternal. Permanence of the media is a storage problem.

Minting, transfer, collections

Minting creates a new ID and assigns an owner. ERC-721 does not specify a mint function; implementations add one. Burning is likewise implementation-defined; the standard says how Transfer events should look when from or to is zero.

Transfer is specified. ERC-721 has safeTransferFrom (which calls onERC721Received on contract recipients) and transferFrom (unsafe if the recipient cannot handle NFTs). Owners, per-token approved addresses, and operators approved for all of an owner’s tokens may transfer.

A collection is usually one contract that issues many IDs on Ethereum. Marketplaces commonly group those tokens by contract address. Other ecosystems use different grouping conventions. Nothing stops unrelated assets from reusing a name or symbol; identifiers and verified relationships matter more than display names.

Ethereum standards: ERC-721 and ERC-1155

ERC-721 (Entriken, Shirley, Evans, Sachs; final, 24 January 2018) is the unique-token interface: balanceOf, ownerOf, transfers, approve, setApprovalForAll, plus optional metadata and enumeration. It is an Ethereum/EVM standard.

ERC-1155 (Radomski, Cooke, Castonguay, Therien, Binet, Sandford; final, 17 June 2018) is a multi-token interface. One contract can hold many IDs. Each ID can be fungible (supply > 1), non-fungible (supply 1), or something in between. Batch transfers save gas when moving several IDs at once. Games that would otherwise deploy thousands of ERC-20s or ERC-721s were a stated motivation; the standard is not limited to games.

Neither standard is how Solana or Bitcoin represent unique assets.

Non-Ethereum models

On Solana, official token docs treat fungible and non-fungible assets as mint accounts plus token accounts under a Token Program. An NFT-style asset commonly uses a fixed-supply mint with one indivisible unit. The Token Program stores supply, decimals and authorities, not an ERC-721-style ownerOf mapping in a per-collection contract.

Other chains have their own NFT interfaces or native asset primitives. Do not call them ERC-721s.

Marketplaces and royalties

Marketplaces are websites and contracts that list, bid on and settle transfers. They are not the token. They can go offline, charge fees, or ignore a creator’s wished-for royalty.

Royalties — a cut of secondary sales to a creator or rights holder — are not universally enforced. ERC-2981 standardizes a royaltyInfo() query that tells a marketplace the recipient and amount for a given sale price; it does not transfer the money. The standard itself says payment is voluntary because an NFT transfer does not necessarily represent a sale. A venue can ignore the interface, and a holder can transfer an ERC-721 without a marketplace. Royalty payment therefore depends on the sale mechanism and venue, not on “NFT” as a category.

Uses beyond profile pictures

ERC-721’s motivation list and ethereum.org’s catalogue overlap:

• digital art and collectibles;
• event tickets and attendance badges (POAPs are a common example on ethereum.org);
• in-game items;
• names (ENS is a name system that uses NFTs for .eth);
• access passes;
• attempts to represent real-world assets (legal effect is off-chain).

A use case is not a proof that the current implementation is durable or lawful.

Limitations and dependencies

• Copyright does not travel with the token unless the law and the license say so.
• Media may be off-chain.
• Metadata URIs may change or rot.
• Smart-contract bugs and admin keys can freeze, mint extra, or rewrite pointers.
• Marketplaces can lose listings, fail to pay royalties, or rug their own contracts.
• Platform accounts (Discord roles, game servers) can ignore the token.
• Fees and confirmation behavior vary by chain and can make some transfers uneconomic.