What is ERC-1155?

The origin story.#

1. Jun 2018 ERC-1155 is created as a multi-token standard for contracts that need many token types and batch transfers. ↗
2. 2019 The standard becomes the default mental model for games and multi-asset collections where ERC-721's one-token transfer shape is too expensive.
3. 2023 LUKSO mainnet ships the LSP asset stack, splitting fungible and identifiable assets into LSP7 and LSP8 while sharing metadata and receiver hooks.

What ERC-1155 actually is.#

// EIP-1155 — core
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 value, bytes calldata data) external;
function safeBatchTransferFrom(address from, address to, uint256[] calldata ids, uint256[] calldata values, 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);
event URI(string value, uint256 indexed id);

// EIP-165 — required
function supportsInterface(bytes4 interfaceId) external view returns (bool);

// EIP-1155 metadata extension
function uri(uint256 id) external view returns (string memory);

// Receiver hooks
function onERC1155Received(address operator, address from, uint256 id, uint256 value, bytes calldata data)
  external returns (bytes4);
function onERC1155BatchReceived(address operator, address from, uint256[] calldata ids, uint256[] calldata values, bytes calldata data)
  external returns (bytes4);

What's broken about ERC-1155.#

1. 01

   Token IDs hide asset semantics.#

   ERC-1155 tells you that ID 42 exists and has a balance. It does not tell you whether ID 42 is a fungible currency, a semi-fungible edition, a unique game item, a claim ticket, or a packed bitfield. Every collection invents its own ID convention. Wallets, indexers, and marketplaces either treat every ID generically or learn per-contract rules.

   −

   ERC-1155 balanceOf(owner, id)

   id-local meaning ·fungibility by convention ·indexer tax

   becomes

   +

   LSP7 + LSP8 standard chosen by asset shape

   fungible in LSP7 ·identifiable in LSP8 ·interface-level semantics

   workarounds tried

   • type-bit token IDs
   • off-chain collection manifests
   • custom indexer adapters
   • per-game metadata registries

   read the deep-dive →

2. 02

   Metadata is one URI template.#

   The optional metadata extension returns uri(id), typically a template with an {id} substitution. That works for game assets, but the contract still does not expose typed fields, per-id structured data, creator metadata, verification hashes, or update semantics. The JSON remains an off-chain convention.

   −

   ERC-1155 uri(id) returns (string)

   off-chain JSON ·template convention ·untyped

   becomes

   +

   LSP4 + ERC-725Y typed asset + per-token data keys

   structured ·VerifiableURI ·contract-readable

   workarounds tried

   • centralized metadata APIs
   • IPFS JSON by token ID
   • OpenSea-style attributes
   • ERC-4906-style refetch events
3. 03

   setApprovalForAll is contract-wide.#

   The operator approval covers every token ID in the contract. That is ergonomic for marketplaces, but it couples every asset type in the collection to one blanket permission. If a game mixes currencies, rare items, badges, and claims in one ERC-1155 contract, one approval can move all of them.

   −

   ERC-1155 setApprovalForAll(operator, true)

   all ids ·forever approval ·phishable

   becomes

   +

   LSP6 AllowedCalls + controller permissions

   account scoped ·revocable ·standard vocabulary

   workarounds tried

   • per-id escrow contracts
   • marketplace allowlists
   • custom transfer validators
   • separate ERC-1155 contracts per asset family
4. 04

   The receiver surface is still asset-specific.#

   ERC-1155 improved safety by requiring receiver hooks for contract recipients, but the hook is ERC-1155-specific. A wallet or vault that handles ERC-20, ERC-721, ERC-1155, and custom assets still implements multiple receiver shapes, each with its own data model.

   −

   ERC-1155 onERC1155Received / onERC1155BatchReceived

   one token family ·batch-specific ·receiver branching

   becomes

   +

   LSP1 universalReceiver(typeId, data)

   one hook ·all assets ·typed notifications

   workarounds tried

   • holder mixins
   • adapter contracts
   • rescue functions
   • asset-specific receiver interfaces
5. 05

   One contract becomes one product boundary.#

   The reason ERC-1155 is efficient is also why it gets heavy: supply rules, transfer rules, metadata rules, permission rules, and indexer assumptions all accumulate inside one deployment. If the product's asset taxonomy changes, the token ID convention has to carry the migration.

   −

   ERC-1155 one contract, many meanings

   monolith ·branch-heavy ·adapter-heavy

   becomes

   +

   LSP7 + LSP8 split contracts by semantics

   smaller surfaces ·clear dispatch ·shared LSP substrate

   workarounds tried

   • new contract versions
   • collection registries
   • proxy upgrades
   • per-id branching

LUKSO designed it differently.#

• LSP7 Digital Asset The fungible side of the split: balances, amount-scoped operators, transfer data, and LSP1 notifications. →
• LSP8 Identifiable Digital Asset The identifiable side: bytes32 token IDs, per-token ERC-725Y data, and the same receiver-aware transfer model. →
• LSP4 Digital Asset Metadata Typed metadata for both LSP7 and LSP8 assets, including VerifiableURI references and extensible ERC-725Y keys. →
• LSP1 Universal Receiver One receiver hook for every asset family instead of ERC-721 and ERC-1155-specific callback shapes. →
• LSP6 Key Manager Move broad operator authority from token contracts to a standard account permission layer. →

ERC-1155 vs LSP7+LSP8 in one table.#

full matrix → erc-1155 vs lsp7+lsp8 →

When to use which.#

FAQ.#

• 01

  What is ERC-1155? #

  ERC-1155 is Ethereum's multi-token standard. One smart contract can manage many token IDs, and each ID can represent a fungible, non-fungible, semi-fungible, or custom asset type. The standard is widely used for games, editions, inventory systems, and collections that need batch transfer.

• 02

  How is ERC-1155 different from ERC-721? #

  ERC-721 has one owner per tokenId and is designed for identifiable NFTs. ERC-1155 has balances per owner per id, so a single token ID can have supply greater than one, and a single contract can mix many asset types. ERC-1155 also includes batch transfer and batch balance functions.

• 03

  How is ERC-1155 different from ERC-20? #

  ERC-20 is one fungible balance per contract. ERC-1155 is many balances per contract, keyed by token ID. An ERC-1155 ID can behave like a fungible token if multiple users hold units of the same ID, but that fungibility is a convention of the contract.

• 04

  Does ERC-1155 solve NFT metadata? #

  It improves the shape for multi-asset collections by defining uri(id), but it does not make metadata typed, on-chain, verified, or contract-readable. The returned URI still usually points to off-chain JSON.

• 05

  What is the LUKSO alternative to ERC-1155? #

  LUKSO does not use one multi-token standard as the primary answer. It splits by asset shape: LSP7 for fungible assets and LSP8 for identifiable assets. Both share LSP4 metadata, LSP1 receiver hooks, and LSP6 account permissions.

Keep reading.#

• digital asset → LSP7
• identifiable digital asset → LSP8
• digital asset metadata → LSP4
• universal receiver → LSP1
• key manager → LSP6
• erc-1155 vs lsp7+lsp8 (full matrix) → comparison
• all ERC ↔ LSP mappings → matrix
• start from your problem → problems