ERC-1155

What Is ERC-1155?

ERC-1155 is an Ethereum token standard that enables a single smart contract to represent and manage an unlimited number of token types. Where ERC-20 handles one fungible token per contract and ERC-721 handles one NFT collection per contract, ERC-1155 can handle currencies, equipment, collectibles, and utility tokens all within a single deployment.

The standard was created by Witek Radomski (CTO of Enjin), Andrew Cooke, Philippe Castonguay, James Therien, Eric Binet, and Ronan Sandford. First submitted as EIP-1155 in June 2018, it went through over 50 revisions and 400 community comments before reaching Final status in June 2019. The primary motivation was the gaming industry, where a single game might need thousands of distinct item types: gold coins (fungible), legendary swords (non-fungible), and health potions (semi-fungible).

Rather than deploying a separate contract for each token type, ERC-1155 consolidates everything into one contract address. Each token type is identified by a unique uint256 ID, and each ID can have its own supply: a supply of 1 creates a non-fungible token, while a higher supply creates fungible or semi-fungible tokens.

How It Works

ERC-1155 introduces several technical innovations over previous token standards. The core design centers on a mapping from token IDs to owner balances, rather than separate contracts for each asset.

Core Interface

The standard defines a minimal interface that all ERC-1155 contracts must implement:

// Transfer a single token type
safeTransferFrom(
  address _from, address _to,
  uint256 _id, uint256 _value, bytes _data
)

// Transfer multiple token types in one call
safeBatchTransferFrom(
  address _from, address _to,
  uint256[] _ids, uint256[] _values, bytes _data
)

// Query a single balance
balanceOf(address _owner, uint256 _id)
  returns (uint256)

// Query multiple balances in one call
balanceOfBatch(address[] _owners, uint256[] _ids)
  returns (uint256[])

Every transfer emits either a TransferSingle or TransferBatch event, giving indexers and block explorers a unified way to track all token movements regardless of type.

Batch Operations

Batch operations are the most significant gas optimization in ERC-1155. A single call to safeBatchTransferFrom can move 100 different token types between two addresses in one transaction. Without batching, this would require 100 separate transactions (for ERC-721) or 100 separate contract calls (for ERC-20), each incurring its own base gas cost, calldata overhead, and state-write fees.

The balanceOfBatch function provides the same efficiency for reads. It accepts parallel arrays of owners and token IDs, returning all requested balances in a single call. This is particularly useful for wallets and marketplaces that need to display a user's full inventory.

Receiver Callbacks

When tokens are transferred to a contract address, ERC-1155 requires the recipient to implement the ERC1155TokenReceiver interface. This prevents tokens from being permanently locked in contracts that cannot handle them. The specification cites the Golem contract (which holds over 350,000 locked GNT tokens) as the cautionary example that motivated this design.

Receiving contracts must implement two callback functions:

// For single transfers
onERC1155Received(
  address _operator, address _from,
  uint256 _id, uint256 _value, bytes _data
) returns (bytes4)
// Must return 0xf23a6e61

// For batch transfers
onERC1155BatchReceived(
  address _operator, address _from,
  uint256[] _ids, uint256[] _values, bytes _data
) returns (bytes4)
// Must return 0xbc197c81

If the recipient does not return the correct magic value, the transfer reverts. This is a strict safety mechanism: it protects users from sending tokens to contracts that would not know how to handle or return them.

Metadata via URI Templates

ERC-1155 handles metadata differently from ERC-721. Instead of storing a unique URI per token (as ERC-721's tokenURI does), ERC-1155 uses a template pattern with a {id} placeholder:

// Single URI template serves all token IDs
uri(uint256 _id) returns (string)

// Example template:
// https://api.example.com/tokens/{id}.json
//
// For token ID 314592, resolves to:
// https://api.example.com/tokens/
//   000000000000000000000000000000000000000000000000000000000004cce0.json

The token ID in the resolved URI must be lowercase hex, zero-padded to 64 characters, with no 0x prefix. This template approach dramatically reduces on-chain storage costs: one URI string serves all token IDs in the contract.

Semi-Fungible Tokens

One of ERC-1155's most distinctive features is native support for semi-fungible tokens: assets that start as interchangeable and later become unique. This concept does not fit cleanly into either ERC-20 (purely fungible) or ERC-721 (purely non-fungible).

Consider event tickets. An issuer mints 1,000 tokens with ID 42, all sharing the same metadata. Before the event, every general admission ticket is identical and interchangeable. When a holder redeems a ticket, the issuer burns the fungible token and mints a new token with a unique ID, creating an individualized proof of attendance. The same contract handles both phases of the token's lifecycle.

In gaming, semi-fungibility appears with consumable items. A game might mint 500 identical "health potion" tokens. Once a player uses one, the contract burns it and mints a unique "empty vial" NFT with properties like timestamp and usage history. The fungible-to-non-fungible transition happens on-chain within the same contract.

Gas Efficiency Compared to ERC-20 and ERC-721

The gas savings from ERC-1155 come from two sources: reduced deployment costs and cheaper per-operation costs through batching.

Batch transfers save approximately 50 to 70 percent in gas compared to equivalent individual ERC-721 transfers. Implementations that pack multiple balances into a single uint256 storage slot can achieve even greater savings, with benchmarks showing up to 90 percent reduction in some scenarios.

Use Cases

Gaming and Virtual Worlds

Gaming was the original motivation for ERC-1155, and it remains the dominant use case. A single game contract can manage gold coins (fungible, high supply), legendary weapons (non-fungible, supply of 1), and consumable items (semi-fungible) without deploying separate contracts. Players can trade entire inventories in one transaction through batch transfers.

Major games and platforms using ERC-1155 include Enjin (the standard's originator), The Sandbox (for land, avatars, and in-game assets), Gods Unchained (trading cards), and SkyWeaver by Horizon Games (a co-creator of the standard).

Marketplace and Collection Platforms

NFT marketplaces like OpenSea, Rarible, and Blur all support ERC-1155 tokens. Edition-based art drops are a natural fit: an artist can mint 100 copies of a piece (fungible within the edition) while maintaining uniqueness across different works, all from one contract. This reduces contract management overhead and simplifies royalty configuration.

Loyalty Programs and Rewards

Loyalty point systems benefit from ERC-1155's multi-token model. A single contract can manage points (fungible), tier badges (non-fungible), and promotional vouchers (semi-fungible, valid until redeemed). Batch transfers enable efficient bulk distribution of rewards to users.

Fractional Ownership and Tokenized Assets

ERC-1155 enables fractional ownership patterns where a unique asset (like real estate or fine art) is represented by a token ID, and multiple fungible shares of that asset are distributed to investors. This is relevant to the broader real-world asset tokenization trend across blockchains.

Approval Model

ERC-1155 uses a simplified approval system compared to ERC-20 and ERC-721. It provides only the setApprovalForAll function, which grants or revokes an operator's permission to transfer all of the owner's tokens across every ID in the contract. There is no per-token or per-amount approval mechanism.

This all-or-nothing model is simpler but carries risk: approving a contract gives it unlimited access to every token type the owner holds in that ERC-1155 contract. Users should exercise caution when granting operator permissions and revoke them when no longer needed.

Recent Developments

The ERC-1155 ecosystem continues to evolve with new extensions and related standards:

• ERC-6909 is a proposed minimal multi-token standard that removes mandatory callbacks, adds per-token-ID allowances, and reverses the balance mapping for query optimization. Uniswap v4 has adopted ERC-6909 for LP position tokens.
• ERC-2981 (NFT Royalty Standard) composes with ERC-1155 to enable per-token-ID royalty rates within a single contract, though marketplace enforcement remains inconsistent.
• OpenZeppelin provides production-ready extensions including ERC1155Supply (total supply tracking), ERC1155Burnable (burn functionality), ERC1155Pausable (circuit breaker), and ERC1155URIStorage (per-token URI overrides).

Risks and Considerations

Reentrancy via Callbacks

The mandatory receiver callbacks (onERC1155Received and onERC1155BatchReceived) create a reentrancy attack surface. Although the specification mandates that balances must be updated before callbacks are invoked, custom state variables (counters, prices, flags) that update after the callback remain vulnerable. Developers should follow the checks-effects-interactions pattern and consider using OpenZeppelin's ReentrancyGuard modifier.

All-or-Nothing Approvals

The lack of granular approvals means a compromised or malicious operator contract can drain all token types from an owner's holdings. Unlike ERC-20, where approvals can be scoped to specific amounts, ERC-1155 operators have blanket access. A thorough smart contract audit of any contract receiving operator approval is essential.

Complexity vs. Simplicity

ERC-1155's flexibility comes at the cost of implementation complexity. The callback requirements, batch operation edge cases, and metadata template system introduce more surface area for bugs than simpler single-purpose standards. Projects that need only one fungible token or one NFT collection may find ERC-20 or ERC-721 more straightforward and better supported by existing tooling.

Metadata Centralization

The URI template pattern typically points to a centralized server or content delivery network. If the metadata host goes offline or the project is abandoned, token metadata can become inaccessible. Storing metadata on decentralized systems like IPFS mitigates this risk but adds complexity.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.