ERC-1155 multi-token standard in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - ERC-1155 multi-token standard

Start Transaction

↓

Check Token ID

↓

Is Token Fungible?

Yes→Process Fungible Token Transfer

↓

Update Balances

↓

Is Token Non-Fungible?

Yes→Process NFT Transfer

↓

Emit Transfer Event

↓

Reject Invalid Token

↓

End Transaction

↓

End Transaction

This flow shows how ERC-1155 handles different token types in one transaction, checking token ID, type, updating balances, and emitting events.

Execution Sample

Blockchain / Solidity

function safeTransferFrom(address from, address to, uint256 id, uint256 amount, bytes data) public {
  require(to != address(0));
  balances[id][from] -= amount;
  balances[id][to] += amount;
  emit TransferSingle(msg.sender, from, to, id, amount);
}

Transfers a specified amount of a token ID from one address to another, updating balances and emitting a transfer event.

Execution Table

Step	Action	Variable/State	Value/Result	Notes
1	Check 'to' address is not zero	to	0xABC123... (valid)	Passes require check
2	Subtract amount from sender balance	balances[id][from]	100 -> 90	Sender had 100 tokens, now 90
3	Add amount to receiver balance	balances[id][to]	50 -> 60	Receiver had 50 tokens, now 60
4	Emit TransferSingle event	event	TransferSingle(msg.sender, from, to, id, amount)	Logs transfer details
5	End function	-	-	Transfer complete

💡 Function ends after updating balances and emitting event

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
balances[id][from]	100	90	90	90
balances[id][to]	50	50	60	60
to	0xABC123...	0xABC123...	0xABC123...	0xABC123...

Key Moments - 3 Insights

Why do we check if the 'to' address is zero before transferring?

Because sending tokens to the zero address would burn them unintentionally. The execution_table row 1 shows the require check preventing this.

How does ERC-1155 handle multiple token types in one contract?

It uses the token ID to distinguish tokens. The flow checks token ID and type before updating balances, as shown in the concept_flow.

What happens if the sender does not have enough tokens?

The subtraction in balances[id][from] would underflow and revert the transaction, stopping execution before emitting the event (not shown in this simple trace).

Visual Quiz - 3 Questions

Look at the execution_table, what is the sender's balance after step 2?

A 90

B 100

C 50

D 60

💡 Hint

Check the 'balances[id][from]' value in row 2 of the execution_table.

At which step is the TransferSingle event emitted?

A Step 2

B Step 4

C Step 3

D Step 5

💡 Hint

Look at the 'Action' column in the execution_table for event emission.

If the 'to' address was zero, what would happen?

A The balances would update incorrectly

B The transfer would proceed normally

C The require check would fail and stop execution

D The event would still emit

💡 Hint

Refer to step 1 in execution_table where the require check is performed.

Concept Snapshot

ERC-1155 allows multiple token types in one contract.
Use token ID to identify tokens.
safeTransferFrom updates balances for given ID and amount.
Check 'to' address is not zero to avoid burning.
Emit TransferSingle event after transfer.
Supports fungible and non-fungible tokens in one standard.

Full Transcript

ERC-1155 is a token standard that lets one contract manage many token types, both fungible and non-fungible. When transferring tokens, it first checks the recipient address is valid. Then it subtracts the amount from the sender's balance and adds it to the receiver's balance for the specific token ID. After updating balances, it emits a TransferSingle event to log the transfer. If the recipient address is zero, the transfer stops immediately to prevent token loss. This standard simplifies handling multiple tokens in one place.

Practice

1. What is the main advantage of the ERC-1155 token standard compared to ERC-20 and ERC-721?

easy

A. It only supports fungible tokens.

B. It allows managing multiple token types in a single contract.

C. It is designed exclusively for non-fungible tokens.

D. It requires a separate contract for each token type.

Solution

1. Step 1: Understand ERC-20 and ERC-721 limitations

   ERC-20 supports fungible tokens only, and ERC-721 supports non-fungible tokens but each token type needs its own contract.

2. Step 2: Identify ERC-1155 feature

   ERC-1155 allows multiple token types (fungible and non-fungible) to be managed within a single contract efficiently.

3. Final Answer:

   It allows managing multiple token types in a single contract. -> Option B

4. Quick Check:

   ERC-1155 = multi-token single contract [OK]

Hint: ERC-1155 = many tokens, one contract [OK]

Common Mistakes:

• Thinking ERC-1155 supports only one token type
• Confusing ERC-1155 with ERC-20 or ERC-721
• Believing ERC-1155 requires multiple contracts

2. Which of the following is the correct Solidity function signature to mint multiple tokens in ERC-1155?

easy

A. function mintBatch(address to, uint256[] ids, uint256[] amounts, bytes data) external;

B. function mintToken(address to, uint256 id) external;

C. function mint(address to, uint256 id, uint256 amount, bytes data) external;

D. function mintSingle(address to, uint256 id, uint256 amount) external;

Solution

1. Step 1: Recall ERC-1155 minting functions

   ERC-1155 defines mintBatch to mint multiple token types at once, taking arrays of ids and amounts.

2. Step 2: Match function signature

   function mintBatch(address to, uint256[] ids, uint256[] amounts, bytes data) external; matches the standard signature: mintBatch(address to, uint256[] ids, uint256[] amounts, bytes data).

3. Final Answer:

   function mintBatch(address to, uint256[] ids, uint256[] amounts, bytes data) external; -> Option A

4. Quick Check:

   mintBatch = batch minting function [OK]

Hint: Batch mint uses arrays of ids and amounts [OK]

Common Mistakes:

• Using single id and amount for batch mint
• Confusing mintBatch with mintSingle
• Missing bytes data parameter

3. Given the following Solidity snippet, what will be the balance of token ID 5 for address 0xABC after execution?

_mint(0xABC, 5, 10, "");
_mintBatch(0xABC, [5, 7], [5, 3], "");

medium

A. 10

B. 5

C. 15

D. 3

Solution

1. Step 1: Analyze first mint call

   The first call mints 10 tokens of ID 5 to address 0xABC.

2. Step 2: Analyze mintBatch call

   The batch mint adds 5 tokens of ID 5 and 3 tokens of ID 7 to the same address.

3. Step 3: Calculate total balance for token ID 5

   Total = 10 (first mint) + 5 (batch mint) = 15 tokens.

4. Final Answer:

   15 -> Option C

5. Quick Check:

   10 + 5 = 15 tokens [OK]

Hint: Add amounts from all mints for same token ID [OK]

Common Mistakes:

• Ignoring batch mint amounts
• Confusing token IDs in batch mint
• Assuming batch mint overwrites balance

4. Identify the error in this ERC-1155 transfer function snippet:

function safeTransferFrom(address from, address to, uint256 id, uint256 amount, bytes data) public {
    require(balanceOf(from, id) >= amount, "Insufficient balance");
    balances[from][id] -= amount;
    balances[to][id] += amount;
}

medium

A. Missing event emission after transfer.

B. Incorrect parameter types for safeTransferFrom.

C. Using 'public' instead of 'external' visibility.

D. No check if 'to' is a smart contract supporting ERC-1155.

Solution

1. Step 1: Review ERC-1155 transfer requirements

   ERC-1155 requires checking if the recipient is a contract and supports the interface to avoid tokens being locked.

2. Step 2: Identify missing safety check

   The snippet lacks the call to onERC1155Received for smart contract recipients.

3. Final Answer:

   No check if 'to' is a smart contract supporting ERC-1155. -> Option D

4. Quick Check:

   Check recipient contract support to prevent token loss [OK]

Hint: Always check recipient contract supports ERC-1155 [OK]

Common Mistakes:

• Forgetting safe transfer acceptance check
• Assuming event emission is enough
• Ignoring contract recipient handling

5. You want to create a game inventory using ERC-1155 where players can hold multiple types of items. Which approach best uses ERC-1155 features to efficiently track and transfer items?

hard

A. Deploy one ERC-1155 contract with unique IDs for each item type and use batch transfers for multiple items.

B. Deploy separate ERC-721 contracts for each item type and transfer items individually.

C. Use ERC-20 tokens for each item type and transfer amounts representing item counts.

D. Create one ERC-1155 contract but mint only one token type for all items.

Solution

1. Step 1: Understand game inventory needs

   Players hold many item types, needing efficient tracking and transfers.

2. Step 2: Evaluate ERC-1155 advantages

   ERC-1155 supports multiple token IDs in one contract and batch transfers, reducing gas and complexity.

3. Step 3: Compare options

   Deploy one ERC-1155 contract with unique IDs for each item type and use batch transfers for multiple items. uses one contract with unique IDs and batch transfers, matching ERC-1155 strengths. Others use less efficient or wrong standards.

4. Final Answer:

   Deploy one ERC-1155 contract with unique IDs for each item type and use batch transfers for multiple items. -> Option A

5. Quick Check:

   One contract + batch transfers = efficient multi-item management [OK]

Hint: Use one ERC-1155 contract with batch transfers for many items [OK]

Common Mistakes:

• Using multiple contracts unnecessarily
• Choosing ERC-20 or ERC-721 for multi-item inventory
• Minting only one token type for all items