ERC-721, ERC-1155 and ERC-6551: which one and why
Three standards, three different problems. Picking the wrong one is not a bug you patch later — the contract is deployed and the choice is in it. Here is how to decide before that happens.
Most people meet these three as a list of acronyms and conclude that the newest must be the best. They are not versions of each other. They answer different questions, and the answer you need is decided by the product, not by the release date.
ERC-721: one token, one owner, one thing
The original. Every token has a unique id, exactly one owner at a time, and its own metadata. A transfer moves one specific item from one address to another.
The mental model is a deed. Token #412 is a particular object; nobody else can hold #412 while you do; and if you want two of something, you need two ids.
Use it when each item is genuinely distinct and individually tracked: art, a numbered membership, a domain name, a deed. Anything where "which one do you have" is a meaningful question.
What it costs. Minting is per token, and so is the gas. A ten-thousand-piece collection is ten thousand mints. Airdropping to a thousand people is a thousand transfers unless the contract is written to batch them.
ERC-1155: many kinds, many copies, one contract
ERC-1155 introduces a second dimension. A token id no longer means one object — it means a type, and an address holds a balance of that type. Id 1 might be "bronze ticket" with 5,000 copies; id 2 "gold ticket" with 200.
The mental model is a warehouse shelf rather than a deed. The contract tracks how many of each kind each address holds.
Two properties follow, and they are the whole reason the standard exists:
- Batching. One transaction can move several ids and several quantities at once. For a game handing out items, or an event issuing tiers, this is the difference between an affordable operation and an impossible one.
- Fungible and non-fungible in the same contract. A currency-like id with a million copies and a one-of-one id can live side by side, sharing infrastructure.
Use it when you have categories with copies: tickets, editions, in-game items, loyalty tiers, anything issued in runs.
What it costs. Individual identity. If holders need to care which copy they hold — a serial number, a history, a provenance chain — ERC-1155 does not give it to you, because copies of an id are interchangeable by design. Some marketplace and wallet interfaces also still treat 1155 as a second-class citizen next to 721.
ERC-6551: the token gets an account
This one is not a replacement for either. It sits on top.
ERC-6551 gives each ERC-721 token its own smart contract account — an address the token owns, deterministically derived from the contract and the id. That account can hold other tokens, hold a balance, and sign transactions, and whoever owns the NFT controls it.
The mental model is a wallet with a deed on the front. Sell the deed and everything inside the wallet goes with it, in one transfer.
Use it when the item needs to own things: a game character carrying inventory, a membership accumulating badges, an artefact with a history that should travel with it on resale. Before 6551, "this character has these items" was a database entry on somebody's server; now it can be an on-chain fact.
What it costs. Complexity, and a new class of mistake. The account is a contract that must be deployed and understood; the transfer of a parent token silently transfers everything inside it, which is either the feature or an expensive surprise depending on whether the buyer knew. Support across wallets and marketplaces is real but not universal, so a product that depends on it needs to check its own venues rather than assume.
Deciding
Three questions, in order, and the first one that gets a clear answer usually settles it.
- Do holders need to know which copy they have? If yes, you need 721 semantics. If it genuinely does not matter — a ticket is a ticket — 1155 will be cheaper and simpler for the rest of the product's life.
- Will you ever move many items at once? Batch airdrops, seasonal item grants, bulk issuance. If that is a routine operation rather than a launch-day one, 1155's batching is not a nice-to-have.
- Does the item need to hold other items? Only then does 6551 enter the conversation, and it enters as an addition to 721 rather than as an alternative to it.
The part that makes this worth getting right
A deployed contract is not a configuration file. You can usually add features around it, and you can migrate holders to a new contract at some cost in trust and gas, but you cannot change what standard the existing tokens are. Every marketplace, wallet and indexer that has already read your collection read it as whatever you deployed.
Pick the standard for the product you will have in two years, not the one you are launching next month.
In practice the mistake runs one direction far more often than the other: teams reach for 721 because it is the famous one, then discover that their tickets, editions or game items were always a 1155 problem, and pay for that discovery in gas on every batch operation they run afterwards.
