NFT Smart Contract Standards: ERC-721, ERC-1155, and ERC-2981 Explained

ERC-721, proposed in 2018, defines the interface for non-fungible tokens. Each token has a unique tokenId and belongs to exactly one address at a time. The standard defines ownerOf(tokenId), transferFrom(), safeTransferFrom(), and approve() functions.

ERC-721 is the right choice when every token is genuinely unique and independent. Art NFTs, unique in-game items with distinct properties, real estate tokens — cases where uniqueness is the core property.

The gas limitation of ERC-721: every token is a separate on-chain entity. Minting 10,000 NFTs requires 10,000 separate mint transactions or a batched approach. For large collections, this creates significant deployment costs and minting gas costs for users.

OpenZeppelin's ERC721 implementation is the gold standard. Do not write your own from scratch. The subtle security requirements (preventing reentrancy in safeTransferFrom, correctly implementing the IERC721 interface) are handled correctly in the battle-tested implementation.

ERC-1155, developed by Enjin, supports both fungible and non-fungible tokens in a single contract. A single ERC-1155 contract can represent millions of different token types, each with different total supplies.

The gas efficiency improvement is significant. ERC-1155's safeBatchTransferFrom can transfer multiple token types in a single transaction. Minting 100 copies of the same item to 100 different addresses is one transaction, not 100.

ERC-1155 is the right choice for gaming applications (where items may have multiple copies), token sets (sports cards, trading cards), and any application with large numbers of similar-but-not-identical items.

The trade-off: ERC-1155 is less widely supported by older marketplace infrastructure. OpenSea, Rarible, and most modern marketplaces support it fully. But some older indexers, wallets, and explorers handle it less gracefully than ERC-721.

Before ERC-2981, NFT royalties were enforced by marketplaces voluntarily. When a secondary sale happened, the marketplace would check its own records and pay the creator a percentage. When NFT trading shifted to marketplaces that did not honor royalties (Blur's zero-royalty model in 2022–2023), creators lost their secondary sale income entirely.

ERC-2981 is an on-chain royalty standard. The NFT contract implements royaltyInfo(tokenId, salePrice) which returns the royalty recipient and amount for any sale. Marketplaces that query this function and pay the royalty provide fully on-chain royalty enforcement.

The limitation of ERC-2981: it is advisory. Marketplaces must choose to query and honor it. The move toward operator filter registries (introduced by OpenSea after the Blur royalty war) attempted to block non-royalty-paying marketplaces at the smart contract level, but this created its own controversy and has been largely abandoned.

For creator-focused projects, implement both ERC-2981 and your own transfer restriction logic if royalty enforcement is a core product requirement. Understand that the enforcement landscape is still evolving.

An NFT contract stores a tokenURI — a link to the token's metadata JSON. This JSON describes the NFT's properties: name, description, image URL, and attributes. How you store this metadata matters enormously for longevity.

The worst pattern: hosting metadata on your own server. If your server goes down, the NFTs become empty shells. This is functionally equivalent to not having an NFT at all — just a token pointing to dead data.

The better pattern: IPFS with content-addressed URIs. IPFS stores data by its hash, so the URI is a permanent reference to immutable content. The risk is IPFS persistence — if nobody pins the content, it can be garbage collected. Filecoin or Arweave add economic incentives for permanent storage.

The best pattern for on-chain metadata: store the metadata directly in the contract or as a Base64-encoded JSON in the tokenURI. This is more expensive but eliminates all external dependencies. Fully on-chain NFTs like Loot and Nouns use this approach.

We built The Fine Art Ledger — an NFT marketplace and provenance platform serving 1,000+ artists. A few practical lessons from building and operating it in production:

Lazy minting significantly improves the creator experience. Rather than requiring artists to pay gas to mint before any sale, lazy minting defers the actual on-chain mint to the point of first purchase. The buyer pays the mint gas, not the creator. For platforms targeting non-crypto-native creators, this is a significant UX improvement.

Artist verification matters more than you think. Without a trusted verification system, collector confidence is lower. A verifiable on-chain provenance link between an artist's identity and their works is a product differentiator.

Secondary royalties should be clearly communicated at listing time, not discovered later. Collectors who feel surprised by royalties become hostile users. Explicit royalty disclosure in the listing UI prevents most of this friction.