Design a Semi-Fungible Token System (ERC-1155)

Problem statement

Design a semi-fungible token platform based on the ERC-1155 standard: a single smart contract that manages many token IDs at once, where some IDs behave like fungible currencies (gold coins, crafting dust, season passes with 10,000 identical copies) and others behave like unique items (one legendary sword with supply exactly one). The platform must mint and burn both kinds, execute batch transfers of mixed token types in one transaction, expose per-ID metadata with a safe URI scheme, enforce partial-supply lifecycle rules, and provide a robust indexing approach so games, wallets, and marketplaces can answer balance and ownership queries without scanning raw logs.

This is not ERC-721 with a quantity field bolted on. ERC-20 models one fungible asset per contract. ERC-721 models one unique asset per token ID, one collection per contract. ERC-1155 collapses N contracts into one: token ID is the discriminator, and each ID independently carries its own supply semantics. The EIP was drafted in June 2018 by Witek Radomski of Enjin with Eric Bin and Andrew Cooke, and Peter Johnson of Horizon (later Sequence) contributed to the multi-token transfer semantics that make batch operations atomic. It was finalized as an accepted standard in 2019 and became the backbone of blockchain gaming inventories.

Why the problem is distinctive

A payment backend retries a transfer. A game inventory cannot retry a duplicated legendary item into existence. The design therefore separates mint correctness from read latency. Mint correctness is an on-chain invariant: supply accounting, uniqueness constraints, and receiver hooks must be exactly-once under the EVM's atomic transaction semantics. Read latency is an eventually-consistent projection: indexers, caches, and metadata gateways serve game clients at interactive speed while the chain remains the only source of truth that settles disputes.

The brief requires a unified contract for multiple token IDs, minting and burning of both fungible and non-fungible items, batch transfers with event logs per token type, per-ID metadata references, gas scalability through batching, ownership security without duplication, low latency for gaming, and a UI or explorer that differentiates item types. Every one of these is addressed explicitly in the sections that follow.

Public operating baseline versus design assumptions

Public evidence establishes the category. Enjin built its platform and marketplace on ERC-1155 and reports powering game item economies across multiple chains. Horizon's SkyWeaver trading card game runs entirely on ERC-1155 on Ethereum and Polygon, and Horizon productized that experience into the Sequence wallet and relayer platform. OpenSea renders semi-fungible ERC-1155 items and reported peak monthly GMV of roughly 4.9 billion dollars in January 2022, which shows the indexing load a marketplace absorbs when token standards explode in popularity. These are cited public figures, not requirements for our system.

For capacity planning, this answer assumes a mature gaming platform with 2.5 million registered wallets, 300,000 daily active users, 150,000 on-chain operations per day on a low-fee L2, 20 million live token IDs of which 90 percent are fungible classes and 10 percent are unique items, and a five-times event peak during drops. Unless a number is tied to a citation, it is a stated design assumption.

The four architectural planes

1. Contract plane: the ERC-1155 contract itself, storage layout, batch operations, hooks, and supply invariants.
2. Indexer plane: event ingestion, reorg-aware balance projection, checkpoints, and query APIs.
3. Metadata plane: URI templates, IPFS pinning, CDN caching, and type-aware rendering.
4. Experience plane: game client, wallet SDK, relayer for gasless transactions, and marketplace or explorer UI.

A strong answer keeps these planes separate. It lets the experience plane degrade without weakening the contract plane, and it lets the metadata plane evolve rendering without touching the immutable token registry.