Many token types in one contract

ERC-1155 lets one contract track balances for multiple token identifiers. An identifier can represent a fungible item type with many interchangeable units, while another may have a supply of one. This differs from ERC-721's ownership model for individually unique tokens. Applications identify an asset by its network, contract, and ID, then ask how many units an address holds. The shared contract structure can reduce duplication when an application manages a large family of related items.

A batch-transfer example

A game could represent health potions under one ID and admission tickets under another. A single batch transfer can send three potions and two tickets to a recipient by specifying parallel arrays of identifiers and quantities. The receiving contract must implement the appropriate acceptance behavior for safe transfers. The batch facility concerns execution and interoperability; it does not guarantee that a game continues operating, that a ticket remains redeemable, or that every item represented in the contract has equivalent economic rights.

Reading approvals and metadata

Operator approval can authorize transfers across an owner's token types in the contract, so its scope deserves attention. Metadata may be referenced through a URI and interpreted using the standard's substitution rules. A wallet showing an attractive image is therefore displaying information associated with a token, not independently verifying the item that image claims to represent. Event logs help index balances and token activity, while project documentation is needed for issuance and redemption rules.

Always separate the interface's technical capabilities from the application's promises about the items.