​ERC-1155 is a multi-token standard that lets a single smart contract manage an unlimited number of token IDs, each with its own supply. Authored by Witek Radomski, Andrew Cooke, and the Enjin team and finalized as EIP-1155 in June 2019, the standard reduces gas costs by ~60% for batch transfers compared to deploying one ERC-721 per item type. Each token ID can be fungible (millions of identical copies), non-fungible (a single unique item), or semi-fungible (a numbered edition with a fixed cap).
​

This article explains the ERC-1155 interface, how batch operations save gas, when ERC-1155 beats ERC-721 for production deployments, and the practical limits of the standard. It also covers the ERC-1155 metadata extension and the safe-transfer hooks that prevent locked tokens.
​

ERC-1155 was originally designed for game items: a single contract holds the entire item catalog of a game, with each item type assigned a token ID. A game with 10,000 sword variants and 10,000,000 gold pieces deploys once, not 10,001 times. The contract's balanceOf(address, id) returns how many of token id address holds, replacing ERC-20's per-contract balanceOf(address) and ERC-721's per-token ownerOf(tokenId).
​

Adoption grew beyond gaming. By April 2026, ERC-1155 contracts on Ethereum, Polygon, and Arbitrum collectively hold billions of token IDs across NFT collections, in-game items, tokenized receipts, and edition drops. OpenSea's overview of ERC-721 vs ERC-1155 documents the marketplace adoption pattern.
​

The contract maintains a two-dimensional balance map: balances[id][address]. Standard operations:

The single approval semantics matter: ERC-721 marketplaces require either per-token approval or a full-collection approval. ERC-1155 uses the full-collection model by default, which is why marketplaces like OpenSea and Rarible can list all of a user's ERC-1155 items after one approval transaction.
​

An ERC-721 contract transferring 100 distinct tokens costs ~21,000 gas per call plus storage updates — roughly 5,000,000 gas total. An ERC-1155 safeBatchTransferFrom with the same 100 tokens uses one calldata blob and a single function frame, dropping cost to ~1,800,000 gas. Enjin's original whitepaper claimed ~60% savings; production benchmarks vary between 50% and 70% depending on how many of the IDs share storage slots.
​

The savings compound for in-game state changes. A guild trade moving 50 items between two players costs ~$2 in gas on Polygon as ERC-1155 versus ~$8 as 50 separate ERC-721 transfers. For high-frequency item economies, the difference is what makes the use case viable.
​

Token IDs are uint256 values. Production contracts use the 256-bit space to encode metadata. Common patterns:

The standard you pick depends on supply per item, marketplace expectations, and gas budget. Build with the matrix below.

OpenSea, Blur, Magic Eden, and Rarible all index ERC-1155. Some smaller marketplaces and aggregators historically had weaker support; check before choosing.
​

ERC-1155 is the dominant standard in NFT subcategories where editions or batches matter.
​

Zora's open-edition contracts, Manifold's editions, and Highlight's drops all use ERC-1155. A drop of 50,000 identical NFTs uses one token ID and one supply counter rather than 50,000 ERC-721 mints. This is what made open editions economically viable; ERC-721 open editions on mainnet routinely cost more in gas than the mint price.
​

Enjin Coin, Sandbox assets, and Gala Games items are ERC-1155. Each game's catalog deploys as one contract, with token IDs partitioned across item types. Inventory transfers between players use safeBatchTransferFrom.
​

POAP (Proof of Attendance Protocol) issues one ERC-1155 token ID per event, with one copy minted to each attendee. The contract on Gnosis Chain has issued more than 10 million POAPs across 100,000+ events, per POAP's public stats page.
​

Some DeFi protocols use ERC-1155 to represent positions. Uniswap v4's hook system explored ERC-1155 receipts for liquidity positions before adopting a different approach. Uniswap v4 docs describe the position-tracking model.
​

ERC-1155 borrowed the safe-transfer pattern from ERC-721: when a token is sent to a contract, the receiving contract must implement onERC1155Received (or onERC1155BatchReceived for batches) and return a specific selector. If it doesn't, the transfer reverts.
​

This prevents tokens being sent to contracts that can't handle them — a common cause of permanently locked ERC-20 tokens. The downside: a transfer to a contract that wasn't deployed with ERC-1155 awareness will revert, even if a human user intended the action. Marketplaces and bridges that want to receive ERC-1155 tokens implement the hook.
​

Stablecoin orchestration platforms working with tokenized real-world assets — invoices, receipts, share certificates — increasingly rely on ERC-1155 because issuers want one contract per asset class rather than per individual asset. A treasury platform routing settlement against a tokenized invoice batch reads ERC-1155 balances directly. Read the stablecoin automation platforms overview for how multi-token primitives compose with treasury workflows. For the broader ERC catalog, see the essential ERC standards builders should know.
​

Yes. Each token ID has its own supply. A token ID with supply of 1 behaves as a non-fungible token. A token ID with supply of 1,000,000 behaves as a fungible token. A semi-fungible token has a fixed cap (e.g., 100 numbered editions). The same contract can hold all three at once.
​

The batch transfer function processes multiple token IDs in a single transaction, sharing calldata, function-call overhead, and storage write packing. Per-token overhead drops from ~21,000 gas to ~5,000 gas in batches, yielding 50–70% savings on large transfers.
​

Not natively. Royalties on ERC-1155 (and ERC-721) come from the separate EIP-2981 NFT Royalty Standard, which any token contract can implement. Marketplaces query royaltyInfo(tokenId, salePrice) and route the royalty share to the recipient.
​

Externally-owned accounts (EOAs) hold ERC-1155 tokens without any special handling. Smart-contract wallets must implement onERC1155Received and onERC1155BatchReceived to accept transfers. Most production smart wallets (Safe, Coinbase Smart Wallet) implement these hooks by default.
​

Yes. ERC-1155 is an EVM-level interface and works on any EVM-compatible chain (Ethereum, Polygon, Arbitrum, Base, Optimism, BNB Chain). Cross-chain transfers require a separate bridge or messaging layer; the standard itself does not address cross-chain coordination.
​