4.3 ERC-1155: The Multi-Token Standard
The $25,000 Deployment Problem
Gods Unchained needed 300+ unique trading cards for their blockchain game. Under ERC-721, that meant 300 separate smart contracts. At 2020 gas prices, deployment cost $75,000. Equipping a deck with 30 cards required 30 transactions at $5-15 each. Players paid more in gas fees than they spent buying the actual cards.
The Sandbox faced worse economics. Their voxel-based metaverse needed fungible tokens for in-game currency, semi-fungible tokens for common assets like trees and rocks, and unique NFTs for land parcels and rare items. Managing this under separate ERC-20 and ERC-721 contracts meant:
Deploy ERC-20 for SAND currency: $1,200 in gas
Deploy 50+ ERC-721 contracts for different item types: $60,000+
Players approve each contract separately: $3 per approval × 50 contracts = $150 per player
Transfer a bundle of 10 items: $30-50 depending on congestion
These costs bankrupted the entire play-to-earn model. When gas fees exceed rewards, games become pay-to-lose. Early blockchain games either moved to sidechains, hemorrhaged users, or waited for someone to fix the underlying standard.
Enjin fixed it. Their team proposed ERC-1155 in June 2018, specifically designed to solve gaming's multi-token nightmare [1]. The standard reached final approval in June 2019 [2]. Within a year, major projects began migrating from ERC-721 to take advantage of the cost savings.
One Contract, Unlimited Token Types
ERC-1155's breakthrough: a single smart contract manages every token type in your ecosystem. Fungible currencies, semi-fungible consumables, and unique collectibles all live in one place.
The technical shift starts with how ownership gets tracked. ERC-721 stores a simple mapping: token ID points to owner address. One token, one owner. ERC-1155 uses nested mappings: owner address points to token ID points to balance. This structure lets one address hold multiple copies of the same token type while also holding unique items.
For a game, this means:
Token ID 1: Gold coins (supply: 1,000,000,000). Fungible.
Token ID 2: Health potions (supply: 50,000). Semi-fungible within batches.
Token ID 3: Legendary sword named "Frostbite" (supply: 1). Unique NFT.
Token ID 4-10,000: Other unique items, each with supply of 1.
One contract. One deployment cost. One approval per marketplace. Everything tracked through a single interface.
The standard makes semi-fungibility practical on Ethereum. Now projects can implement it at scale. Concert tickets demonstrate this perfectly. Section A, Row 5 includes 20 identical seats. Before the event, these 20 tickets are fungible. Trade seat 12 for seat 18, and nothing changed. After the concert, each ticket becomes a unique collectible with its own history. Who attended? Which songs were performed? The token transforms from fungible to non-fungible without changing contracts or standards.
Batch Operations: The Gas Efficiency Breakthrough
Batch transfers define ERC-1155's practical advantage. The standard includes safeBatchTransferFrom, which moves multiple token types in a single transaction.
Example trade between players:
Player A sends: 500 gold coins (ID: 1), 10 health potions (ID: 2), 1 legendary sword (ID: 3)
Player B sends: 1,000 gold coins (ID: 1), 5 mana potions (ID: 4), 1 rare shield (ID: 5)
ERC-721 approach: 6 separate transactions (one per item), costing $18-30 total. ERC-1155 approach: 1 transaction handling all items, costing $5-8.
The gas savings compound. Marketplace approvals work the same way. Under ERC-721, approving OpenSea to sell your collection requires one transaction per contract. If you own items from 30 different collections, that's 30 approvals at $3 each, totaling $90. ERC-1155 grants approval once per contract, which now manages hundreds or thousands of token types. One approval, one gas fee.
Balance queries improve similarly. The balanceOfBatch function checks multiple token IDs for multiple addresses in one call. A wallet displaying your inventory makes one request instead of hundreds. Block explorers tracking collection statistics query once instead of iterating through separate contracts.
Technical Implementation
Contract Architecture
The core data structure stores balances as mapping(address => mapping(uint256 => uint256)). Translation: for each owner address, track their balance of each token ID.
This nested mapping handles all token types efficiently. A player's inventory might contain:
Address 0x123... → Token ID 1 → Balance: 50,000 (gold coins)
Address 0x123... → Token ID 2 → Balance: 25 (health potions)
Address 0x123... → Token ID 3 → Balance: 1 (unique sword)
One data structure. Clean. Efficient. Scalable to millions of token types per contract.
Minting Logic
Developers control supply at the token ID level. Mint 1 billion units of token ID 1 for currency. Mint 100 units of token ID 2 for limited edition items. Mint 1 unit of token ID 3 for a unique collectible. Same contract, different economics per token type.
The standard doesn't track total supply per token ID by default. Many production contracts add optional totalSupply(id) functions for this. Check a project's specific implementation to see what query functions are available beyond the mandatory ERC-1155 interface.
This flexibility enables complex game mechanics. A crafting system might burn 3 common ingredients (token IDs 10, 11, 12) to mint 1 rare weapon (token ID 500). All operations happen within one contract through standardized functions.
Metadata Structure
ERC-1155 optimizes metadata storage through a base URI pattern. Instead of storing complete URIs for every token, the contract stores one template: https://api.game.com/metadata/{id}.json
The ERC-1155 specification standardizes only the URI template with {id} substitution. How contracts handle metadata beyond this placeholder is implementation-specific. Projects decide whether to use centralized servers, IPFS, or on-chain storage based on their requirements.
When querying token ID 42, the system substitutes {id} with the hexadecimal representation of 42 (0x2a), constructing the full URI automatically. This saves storage costs for collections with thousands of tokens sharing the same metadata server.
For tokens with unique metadata, the URI can point to specific files. The standard accommodates both patterns without requiring separate implementations.
Safety Mechanisms
Safe transfer rules prevent asset loss. When tokens transfer to a contract address, that contract must implement IERC1155Receiver and return a specific value confirming it accepts the transfer. If the receiving contract lacks this interface or rejects the tokens, the transaction reverts.
This protection extends to batch transfers. Send 50 different items to a contract in one transaction, and if that contract can't handle even one item type, the entire batch reverts. No partial transfers. No locked assets.
Want to build a multi-token game economy?
Our hands-on tutorial walks you through deploying an ERC-1155 contract managing fungible currencies, semi-fungible items, and unique collectibles in one deployment. You'll see why one contract beats dozens and how batch operations slash gas costs by 50-80%.
Read the tutorial: Build a Multi-Token Game Economy with ERC-1155 →
The Economics: Real Cost Comparisons
Numbers from 2020-2021 when gas averaged 50-100 gwei, showing the period when ERC-1155 adoption accelerated:
Deploy 50 item types
50 contracts × $1,200 = $60,000
1 contract = $800
99%
Approve marketplace
50 approvals × $3 = $150
1 approval = $3
98%
Transfer 10 items
10 tx × $5 = $50
1 tx = $8
84%
Mint 1,000 units (semi-fungible)
1,000 tx × $5 = $5,000
1 tx = $8
99.8%
These savings matter most for gaming, where frequent, small-value transactions define the user experience. A $5 gas fee to use a $0.50 health potion breaks game economics. A $0.05 gas fee for batched inventory management works.
Current gas prices in late 2024 run lower (5-20 gwei typically), but the percentage savings remain identical. The architectural efficiency persists regardless of absolute gas costs.
Real-World Applications
The Sandbox: Virtual World Economics
The Sandbox launched in 2020 with ERC-1155 managing their entire asset ecosystem. The numbers validate the choice.
Over 166,000 LANDs exist as unique NFTs (token supply: 1 per LAND) [3]. More than 75 million voxel ASSETS circulate as semi-fungible tokens, with common trees and rocks having supplies in the thousands while rare items exist in limited quantities [4]. SAND, the platform currency, operates as an ERC-20 token separately, though LAND transactions typically involve both standards.
The multi-token approach enables their creator economy. An artist designs a custom tree model and mints 100 copies as a semi-fungible token. Builders buy these trees for their LANDs. If the design becomes popular, secondary markets develop. The same contract manages both the unique LAND parcels and the semi-fungible decorative items placed on them.
Transaction volume peaked at 2.5 million+ in 2021 [5]. The batch transfer capability meant multiple asset sales, often bundling LANDs with equipped items, processed in single transactions. This would have been prohibitively expensive under ERC-721's one-item-per-transaction model.
Gods Unchained: Trading Card Economics
Gods Unchained operates as a competitive trading card game where cards are ERC-1155 tokens. The standard fits perfectly: common cards have large supplies (thousands of identical copies), rare cards have limited supplies (hundreds), and legendary cards approach unique status (dozens or single digits).
The game has minted over 38 million cards across 1,500+ unique card types [6]. Players trade complete decks of 30 cards in single transactions. Opening a pack of 5 cards requires one mint transaction, not five. Building the entire card economy on ERC-721 would have cost players millions in aggregate gas fees.
Card quality creates another layer. The same card design exists in different qualities: Meteorite (common), Shadow (rare), Gold (epic), Diamond (legendary). These quality tiers represent different token IDs, all managed in one contract. A player might own 50 Meteorite copies of one card while hunting for a single Diamond version.
The game also demonstrates ERC-1155's upgrade pattern. Players "forge" lower-quality cards into higher-quality versions by burning multiple common copies to mint one rare. This burning mechanism works seamlessly within the standard's transfer and mint functions.
Enjin Platform: Multi-Game Infrastructure
Enjin built their entire gaming platform around ERC-1155, supporting over 2 billion digital assets across multiple games by 2024 [7]. The multiverse concept works because the standard enables true interoperability.
A sword from Game A carries stats and artwork defined by its metadata. Game B can recognize that same sword token and give it different stats or appearance while respecting the underlying ownership. Both games interact with the same ERC-1155 contract. The sword exists once on-chain but functions across multiple virtual worlds.
This interoperability requires coordination between game developers, not just technical compatibility. The standard provides the rails. Projects must agree on how to interpret each other's tokens. When they do, assets genuinely become portable across ecosystems.
Evolution of NFT Thinking
ERC-1155 changed how the industry conceptualizes digital assets. Three shifts matter:
Semi-Fungibility Became Real: Before ERC-1155, assets were either completely unique (ERC-721) or completely interchangeable (ERC-20). The middle ground didn't exist technically. Now it does. Event tickets, limited edition prints, consumable game items, all occupy this space. The standard made the concept implementable, not just theoretical.
Batch Operations Set Expectations: Once users experienced transferring complete inventories in one transaction, single-item transfers felt broken. ERC-721 didn't stop working. User expectations shifted. New NFT projects must justify why they're not using batch-capable standards. The burden of proof reversed.
Contract Efficiency Matters: Early NFT projects deployed new contracts freely. Each collection, each token type, separate deployments. ERC-1155 demonstrated that consolidation reduces costs without sacrificing functionality. This thinking influenced Layer 2 design, where batching and efficiency became core requirements, not optimizations.
The standard also revealed limits. Gaming projects initially hoped ERC-1155 would make Ethereum L1 viable for mainstream games. The cost savings helped but weren't enough. A $5 transaction beats a $50 transaction, but free or near-free transactions beat both. This realization accelerated Layer 2 adoption and alternative chain exploration. ERC-1155 solved problems within Ethereum's constraints without removing those constraints.
When to Use ERC-1155 vs ERC-721
The decision depends on your specific requirements, not abstract technical superiority.
Choose ERC-721 when:
Every token is unique and high-value. Art collections, rare collectibles, virtual real estate where each piece differs meaningfully. The simplicity of "one contract, one collection type" fits better than ERC-1155's flexibility.
Maximum marketplace compatibility matters. Major marketplaces like OpenSea, LooksRare, and others support both ERC‑721 and ERC‑1155, but infrastructure and tooling are still generally more mature and battle‑tested for ERC‑721 collections. Support exists for ERC-1155 but remains less mature. If you're launching a profile picture project targeting collectors who use established platforms, ERC-721 is the safer choice.
Simplicity beats optimization. ERC-721's straightforward model (one token ID per unique item) is easier to explain, audit, and understand. If you're not managing hundreds of token types or doing frequent batch operations, the additional complexity of ERC-1155 provides no benefit.
Choose ERC-1155 when:
Managing multiple token types in one ecosystem. Games with currencies, consumables, and unique items. Platforms with membership tiers plus unique collectibles. Any project juggling fungible, semi-fungible, and non-fungible tokens benefits from consolidation.
Batch operations are common. Marketplace bundles, inventory management, multi-asset crafting systems. If users regularly interact with multiple token types simultaneously, ERC-1155's batch functions save them real money.
Cost optimization is critical. The 97-99% savings on deployment and approval costs matter most for projects with tight budgets or user bases sensitive to gas fees. Gaming projects especially benefit.
Semi-fungibility is core to your model. Limited edition prints, event tickets, consumable items with identical copies. ERC-1155 natively supports this middle ground that ERC-721 handles awkwardly.
Choose neither when:
Building on Layer 2 changes the calculation. When transactions cost $0.01-0.10, the absolute savings shrink. But batch operations still reduce calldata costs and aggregate fees, which matters for high-volume applications processing thousands of transactions daily. The percentage advantage narrows, not disappears.
Alternative chains offer different trade-offs entirely. Solana's approach to NFTs, explored in the next section, takes a completely different architectural path that makes the ERC-721 vs ERC-1155 debate irrelevant.
Beyond Ethereum's Architecture
ERC-1155 solved Ethereum's multi-token problem through elegant contract design. It proved that NFTs could power gaming and complex applications, not just art collecting. The 84-99% cost reduction made previously impossible economics viable.
But optimization within constraints isn't the same as removing constraints.
An ERC-1155 batch transfer costs $5-8. Better than $50, but still expensive compared to Web2 gaming where players expect instant, free inventory management. Deploy a contract with 1,000 token types on Ethereum mainnet: $800. Deploy the same on Layer 2: $50-100. Both beat ERC-721's costs. Neither approaches the fractions-of-a-cent transactions that mainstream gaming requires.
Solana took a fundamentally different approach. Rather than optimizing smart contract architecture within Ethereum's constraints, the Metaplex standard reimagined NFTs from the ground up for a blockchain designed for speed. No gas auctions. No congestion pricing. No choosing between decentralization and performance.
The trade-offs matter. Understanding when ERC-1155's savings justify staying on Ethereum versus when Solana's architecture makes more sense determines which standard fits your application. The next section examines how Solana's Metaplex standard handles NFTs when performance becomes the primary design constraint.
References
[1] Witek Radomski, "ERC-1155: The Crypto Item Standard" - https://blog.enjin.io/erc-1155-crypto-items-standard/
[2] Ethereum, "ERC-1155: Multi Token Standard" - https://eips.ethereum.org/EIPS/eip-1155
[3] The Sandbox, "LAND Statistics" - https://www.sandbox.game/en/
[4] The Sandbox, "ASSETS Marketplace Data" - https://www.sandbox.game/en/assets/
[5] Dune Analytics, "The Sandbox Metrics Dashboard" - https://dune.com/
[6] Gods Unchained, "Card Statistics" - https://godsunchained.com/
[7] Enjin, "Platform Statistics 2024" - https://enjin.io/
Last updated