# Table of Contents
**TOPIC - EIP-1155: The Multi Token Standard**

**1.0 Definition of Terms**

**2.0 Introduction and History**

**3.0 Alignment with Previous and Subsequent Tokens**

* **Alignment with Previous Standards**

* **Alignment with Subsequent Standards**

**4.0 Problems Associated with the Previous Tokens**

**5.0 Why the Proposal Was Needed**

**6.0 The Purpose**

**7.0 Types (In Terms of EIP Classifications)**

**8.0 How They Are Created (EIP Lifecycle)**

**9.0 Technical Functionalities**

* **Token Management**

* **Core Transfer Functions**

* **Query Functions**

* **Approval**

* **URI & Metadata**

* **Hooks & Interfaces**

* **Events**

**10.0 Limitations**

**11.0 Solutions**

**12.0 Conclusion**

**References**

# **EIP-1155: THE MULTI TOKEN STANDARD**
*A Detailed Analysis and Class Presentation on Ethereum's Most Versatile Token Standard*

# 1.0 Definition of Terms
To understand EIP-1155, it’s essential to first define the foundational concepts:

1. EIP (Ethereum Improvement Proposal): A formalized process through which upgrades or changes are proposed for the Ethereum ecosystem. Each EIP undergoes review before being finalized or rejected.

2. ERC (Ethereum Request for Comment): A category within EIPs that defines application-layer standards, particularly token standards like ERC-20 and ERC-721.

3. Token Standard: A set of rules that a smart contract must follow to define and manage tokens on the Ethereum network.

4. Fungible Token: Tokens that are identical and interchangeable, such as Ethereum (ETH) or DAI. This is what ERC-20 represents.

5. Non-Fungible Token (NFT): A unique digital asset that cannot be interchanged. These tokens have individual characteristics and are best represented by ERC-721.

6. Semi-Fungible Token: A token that behaves like a fungible token initially but becomes unique once used (e.g., event tickets, upgradable game items).

7. Smart Contract: A program stored on the Ethereum blockchain that runs automatically when conditions are met. Used to create and manage tokens.

8. Metadata: Data associated with a token, typically including name, image, description, and other attributes. Often stored off-chain using IPFS or similar systems.

9. Royalties: Payments made automatically to content creators when a digital asset is resold. Supported through standards like ERC-2981.

# 2.0 Introduction and History
EIP-1155, titled “Multi Token Standard,” was introduced in June 2018 by Witek Radomski, the CTO of Enjin. The need for this proposal emerged from the growing complexity of managing multiple asset types in blockchain applications, particularly in gaming environments.

Before EIP-1155, developers had to deploy and maintain multiple smart contracts for different token types — ERC-20 for fungible tokens and ERC-721 for NFTs. This led to inefficiency, high gas costs, and complexity when building large-scale applications with mixed assets.

Enjin, a company focused on blockchain gaming, needed a solution that could manage a wide variety of token types — from in-game currency to unique items — without overcomplicating the backend. The result was EIP-1155, a unified token standard capable of handling fungible, non-fungible, and semi-fungible tokens in a single contract.

It was finalized in June 2019 and rapidly gained adoption across NFT platforms, games, and marketplaces due to its efficiency and flexibility.

# 3.0 Alignment with Previous and Subsequent Tokens
EIP-1155 was created to improve upon and work alongside existing token standards while aligning with future developments in Ethereum.

**Alignment with Previous Standards**
* ERC-20 (Fungible Tokens):
Used for digital currencies like DAI or USDC, where all tokens are identical. EIP-1155 mimics this functionality but introduces the ability to batch-transfer multiple token types and manage them within one contract, reducing deployment costs.

* ERC-721 (Non-Fungible Tokens):
Used for unique assets like CryptoKitties or Bored Apes. ERC-721 allows each token to be different. EIP-1155 goes further by managing NFTs and fungible tokens in one place — a crucial benefit for applications like games or marketplaces.

**Alignment with Subsequent Standards**
* ERC-2981 (NFT Royalty Standard):
ERC-1155 doesn't have built-in royalty support. However, it can be extended to support ERC-2981, which defines a standard way to retrieve royalty info for NFTs. This allows EIP-1155 tokens to integrate with platforms like OpenSea that honor royalties on resale.

* ERC-6551 (Token-Bound Accounts):
A newer proposal allowing NFTs to own assets. It can be layered on top of ERC-1155 NFTs for use cases like composable avatars or item bundles.

# 4.0 Problems Associated with the Previous Tokens
Before EIP-1155, the Ethereum ecosystem was dominated by two main token standards — ERC-20 for fungible tokens and ERC-721 for NFTs. However, these came with several limitations:

**Multiple Contracts per Token Type:**

Developers had to deploy a separate contract for each asset type, leading to high overhead and complexity.

**No Batch Transfers:**

Each transaction could only handle one token at a time. Transferring 100 items required 100 transactions.

**High Gas Costs:**

Because of the multiple transactions and contract calls, users paid more gas, especially during network congestion.

**Complex Inventory Logic:**

Applications with mixed asset types (e.g., games, marketplaces) had to implement complex logic to integrate ERC-20 and ERC-721 together.

**No Support for Hybrid Tokens:**

Neither ERC-20 nor ERC-721 could represent semi-fungible tokens, which act fungible at first but become non-fungible later.

These limitations made it difficult to scale decentralized applications with diverse asset requirements.

# 5.0 Why the Proposal Was Needed
EIP-1155 was proposed to solve real inefficiencies and technical constraints in Ethereum’s token management model. Specifically, it was needed to:

* Unify Token Logic: Reduce the number of smart contracts and interfaces developers needed to maintain.

* Enable Batch Processing: Lower transaction fees and improve performance by allowing batch minting, transfers, and burning.

* Support for New Use Cases: Provide a flexible standard that could support semi-fungible tokens and large inventories typical of games and collectibles.

* Optimize Developer Experience: Streamline the way tokens are created, stored, and interacted with.

* Boost User Experience: Allow cheaper, faster, and smoother interactions for end-users on marketplaces, games, and dApps.

# 6.0 The Purpose
EIP-1155’s core purpose is to:

* Introduce a unified token standard that supports multiple asset types — fungible, non-fungible, and semi-fungible.

* Improve gas efficiency by enabling batch transactions (e.g., sending or minting multiple tokens in a single call).

* Reduce smart contract duplication by allowing all asset types to live under one contract.

* Provide a flexible framework for building next-gen Ethereum applications, particularly in gaming, collectibles, and metaverse platforms.

* Support composability and interoperability with other standards and platforms in the Ethereum ecosystem.

# 7.0 Types (In Terms of EIP Classifications)
Ethereum Improvement Proposals fall under three primary types:

**EIP Type**
**Standards Track**-Introduces new features to the Ethereum platform (it has to do with sometechnicalities)
**Meta**-Proposes changes to the EIP process or Ethereum governance
**Informational**-Provides general guidance or best practices

➤ EIP-1155 is a Standards Track EIP, specifically under the ERC (Ethereum Request for Comments) subcategory.

# 8.0 How They Are Created (EIP Lifecycle)
The Ethereum community follows a formal process to evaluate and approve EIPs:

**Proposal Stage:**

A developer drafts an EIP with technical specs and rationale. Witek Radomski submitted EIP-1155 to address gaming-related token inefficiencies.

**Draft Stage:**

The proposal is submitted to Ethereum's GitHub repo and forums like Ethereum Magicians for open discussion.

**Review Stage:**

Experts and core developers review the technical and economic implications, suggesting changes or optimizations.

**Last Call:**

A final comment period to catch unresolved issues or needed edits.

**Final:**

If accepted, the EIP is given “Final” status and becomes a formal Ethereum standard. EIP-1155 reached this stage in June 2019.

Once finalized, tools like OpenZeppelin and Enjin SDK allow developers to start implementing the standard.

# 9.0 Technical Functionalities
**Token Management**
Supports multiple token types (fungible, non-fungible, semi-fungible) using unique uint256 IDs.

**Core Transfer Functions**
* **safeTransferFrom**(address from, address to, uint256 id, uint256 amount, bytes data)

* **safeBatchTransferFrom**(address from, address to, uint256[] ids, uint256[] amounts, bytes data)

**Query Functions**
* **balanceOf**(address account, uint256 id)
Returns how many units of a specific token a user holds.

* **balanceOfBatch**(address[] accounts, uint256[] ids)
Returns balances for multiple tokens across multiple users in one call.

**Approval**
* **setApprovalForAll**(address operator, bool approved)
Allows an operator to manage all of the caller's tokens.

**URI & Metadata**
* **uri(uint256 id)** returns the URI for metadata, with {id} as a placeholder for token-specific data.

**Hooks & Interfaces**
**onERC1155Received** and **IERC1155BatchReceiver** handle safe receipt of tokens. (safe transfer mechanism)

**Events**

**TransferSingle**
* **event TransferSingle**(address indexed operator,address indexed from,address indexed to,uint256 id,uint256 value
);
* Emitted when a single token type is transferred. Includes operator, sender, receiver, token ID, and amount.

**TransferBatch**
* **event TransferBatch**(address indexed operator,address indexed from,address indexed to,uint256[] ids,uint256[] values
);
* Emitted during batch transfers of multiple token types. Tracks arrays of token IDs and amounts.

**ApprovalForAll**
* **event ApprovalForAll**(address indexed account,address indexed operator,bool approved
);

* Logs when an account gives or revokes transfer rights to an operator for all tokens.

# 10.0 Limitations
* **Higher Complexity:** More challenging for beginner developers compared to ERC-20 or ERC-721.

* **No Built-in Royalties:** Needs manual implementation or ERC-2981 extension.

* **Token Type Ambiguity:** Token IDs don’t inherently indicate fungibility — this must be enforced at the contract level.

**Platform Support Still Catching Up**: Some wallets and dApps still prioritize ERC-721.

**Off-Chain Metadata Reliance:** Metadata is often stored off-chain via IPFS or centralized servers, which can lead to availability issues.

# 11.0 Solutions
**Tooling:** Use OpenZeppelin contracts, Enjin SDK, or Thirdweb to simplify development.

**Royalty Integration:** Add ERC-2981 support for on-chain royalty tracking.

**ID Scheme Best Practices:** Use developer conventions (e.g., even IDs = fungible, odd IDs = NFTs) for clarity.

**Growing Ecosystem Support:** Platforms like OpenSea and Immutable X now fully support EIP-1155.

**Use of IPFS/Arweave:** Ensures token metadata is decentralized and permanent.

**Layer-2 Integration:** Leverages cheaper gas and faster execution on Layer-2s like Polygon.

# 12.0 Conclusion

EIP-1155 is a revolutionary token standard that solves the inefficiencies of its predecessors. By enabling a single contract to support multiple token types and introducing batch operations, it has become the go-to standard for scalable, asset-rich applications.

From gaming and collectibles to digital identity and ticketing, EIP-1155 offers unmatched flexibility and efficiency. Though complex, it is supported by powerful tools and is compatible with modern extensions like ERC-2981.

In an Ethereum ecosystem that demands versatility, composability, and scalability, EIP-1155 isn’t just a standard — it’s the foundation of the multi-token future.

# References
1. EIP-1155: Multi Token Standard
Ethereum Improvement Proposals. Witek Radomski, June 2018.
https://eips.ethereum.org/EIPS/eip-1155

2. ERC-20 Token Standard
Fabian Vogelsteller, Vitalik Buterin.
https://eips.ethereum.org/EIPS/eip-20

3. ERC-721: Non-Fungible Token Standard
William Entriken, Dieter Shirley, Jacob Evans, Nastassia Sachs.
https://eips.ethereum.org/EIPS/eip-721

4. ERC-2981: NFT Royalty Standard
Blaine Malone, James Seibel.
https://eips.ethereum.org/EIPS/eip-2981

5. Ethereum EIP Process
GitHub – Ethereum EIPs Repository.
https://github.com/ethereum/EIPs

6. OpenZeppelin Contracts Documentation
https://docs.openzeppelin.com/contracts

7. Enjin Platform and SDK
https://enjin.io/products/platform

8. Ethereum Magicians Forum — Discussion on EIP-1155
https://ethereum-magicians.org/t/eip-1155-multi-token-standard

9. OpenSea Developer Docs — Multi-Token Support
https://docs.opensea.io/docs/metadata-standards

10. IPFS for Decentralized Metadata
Protocol Labs.
https://docs.ipfs.tech