ERC-1155¶
ERC-1155 is a multi-token standard: a single contract can manage many distinct token types simultaneously (some fungible, some non-fungible, in any combination) where ERC-20 and ERC-721 each require a separate contract deployment per token type. This chapter covers the interface and the specific efficiency gain (batching) that motivated it.
The core interface¶
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
interface IERC1155 {
function balanceOf(address account, uint256 id) external view returns (uint256);
function balanceOfBatch(
address[] calldata accounts,
uint256[] calldata ids
) external view returns (uint256[] memory);
function setApprovalForAll(address operator, bool approved) external;
function isApprovedForAll(address account, address operator) external view returns (bool);
function safeTransferFrom(
address from,
address to,
uint256 id,
uint256 amount,
bytes calldata data
) external;
function safeBatchTransferFrom(
address from,
address to,
uint256[] calldata ids,
uint256[] calldata amounts,
bytes calldata data
) external;
event TransferSingle(address indexed operator, address indexed from, address indexed to, uint256 id, uint256 value);
event TransferBatch(address indexed operator, address indexed from, address indexed to, uint256[] ids, uint256[] values);
event ApprovalForAll(address indexed account, address indexed operator, bool approved);
}
Verified: this compiles cleanly with solc 0.8.26.
One contract, many token types¶
Notice balanceOf here takes two parameters (an account and a token ID) unlike ERC-20's single-parameter version. This single contract can represent, simultaneously: a fungible in-game currency (many different addresses each holding a quantity of id = 1), a limited-edition collectible (id = 2, with a fixed, small total quantity, functioning much like an ERC-721 token even though it's implemented through the same interface), and any number of other distinct types. Each id effectively functions as its own independent token, all managed by one deployed contract.
Batching: the real, practical motivation¶
safeBatchTransferFrom and balanceOfBatch let many token types be transferred or queried in a single transaction, directly analogous to the on-chain fee savings demonstrated with real numbers in Transaction Batching, a game distributing dozens of different in-game item types to a player in one transaction pays a fraction of what dozens of separate ERC-721 or ERC-20 transfers, each with its own fixed transaction overhead, would cost. This is ERC-1155's most concrete, practical advantage over deploying many separate single-purpose token contracts: real, measurable gas savings for any application managing multiple token types that need to move together.
Common misconceptions¶
ERC-1155 does not replace ERC-20 or ERC-721 as "the better standard" in every case, a project genuinely needing only one fungible token, with no other token types to manage, generally has no reason to add the complexity of the multi-token model; ERC-1155's advantages are specifically about managing many distinct token types efficiently, not about being a strictly superior interface for a single-token use case.
safeTransferFrom in ERC-1155 always requires the recipient contract check, unlike ERC-721, which (as covered in ERC-721) offers both a checked (safeTransferFrom) and unchecked (transferFrom) path; ERC-1155 has no unchecked transferFrom equivalent at all, meaning every transfer to a contract address goes through the onERC1155Received (or onERC1155BatchReceived) callback check by design, a deliberately more consistent safety requirement than ERC-721's two-tier approach.