Fungible vs non-fungible
ERC-20 defines fungible tokens: every unit is interchangeable, tracked as one balance per address. ERC-721 defines non-fungible tokens: each tokenId is unique and individually owned, with its own metadata. ERC-1155 is a multi-token standard letting a single contract manage both fungible and non-fungible token types, saving gas versus deploying many separate contracts.
- •ERC-20: balanceOf(address) → uint256.
- •ERC-721: ownerOf(tokenId) → address, one owner per unique id.
- •ERC-1155: balanceOf(address, id) → uint256, batched transfers.
Metadata and where art actually lives
An NFT contract usually stores only a tokenURI pointing to a JSON metadata file describing name, image and attributes. That file and the image it references can be hosted on a centralized server (fragile — it can disappear), IPFS (content-addressed, but needs pinning to stay available), or, less commonly, fully on-chain as base64-encoded data (durable but expensive).
- •Centralized URL: cheapest, least durable.
- •IPFS: content hash guarantees integrity if pinned by someone.
- •Fully on-chain: most durable, most expensive to store.
Approvals and marketplaces
Marketplaces don't hold your NFT to list it; you grant an approval (approve or setApprovalForAll) letting a marketplace contract move the token on your behalf when a sale executes. This is powerful and risky — a malicious or compromised marketplace contract with blanket approval can transfer every approved asset, so approvals should be reviewed and revoked when no longer needed.
Royalties
ERC-2981 lets a contract declare a suggested royalty percentage and recipient for secondary sales. Critically, it's a signal, not an enforcement mechanism — nothing on-chain forces a marketplace to pay it. Many marketplaces made royalties optional, which is why creators increasingly rely on off-chain agreements or contract-level transfer restrictions instead of trusting ERC-2981 alone.