Track 5 · Tokens · lesson 8
ERC-1155
12 min
A game has 200 item types. Under ERC-721 that is 200 deployed contracts, or one collection where every sword is a distinct token with its own id and no way to say "give me fifty".
ERC-1155 solves both: one contract, many token types, each with quantities.
mapping(uint256 => mapping(address => uint256)) balanceOf;
// id account amount
One extra mapping level. That is the whole idea.
Nudge
Show me the approach
Show me the code
Explain the solution
Fungible and non-fungible in one contract
Because each id has quantities, an id can behave either way:
- id 1 = gold coins, supply 1,000,000 → fungible, like ERC-20.
- id 2 = the legendary sword, supply 1 → non-fungible, like ERC-721.
Same contract, same functions, same events. The distinction is a choice about supply, not a different standard.
The real selling point is batching. safeBatchTransferFrom moves many ids
in a single call.
A game handing a player ten different rewards pays for one transaction rather than ten. At scale that is not a nicety — it is the difference between a playable game and an unplayable one.
Predict
Why does ERC-1155 have no `ownerOf(id)` function?
Choosing between the three
| Use case | Standard | |---|---| | A currency or share | ERC-20 | | One unique thing with an identity | ERC-721 | | Many types, some unique, some in quantity | ERC-1155 |
If you would deploy more than a handful of ERC-721 contracts that share a purpose, you probably want ERC-1155 instead.
Check
What is ERC-1155's main practical advantage?
Worth remembering
- ERC-1155 indexes balances by id and then by account — one extra mapping level.
- The same contract holds fungible and non-fungible ids; supply is what distinguishes them.
- Batch transfers are the real advantage — many ids in one transaction.
- There is no `ownerOf` because an id can have many holders.
- Reach for it when you would otherwise deploy many related ERC-721 contracts.