ERC-20 fungible token standard in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - ERC-20 fungible token standard

Contract Deployment

↓

Initialize totalSupply

↓

Balances mapping setup

↓

User calls transfer

↓

Check sender balance >= amount?

No→Fail transaction

Yes↓

Subtract amount from sender

↓

Add amount to receiver

↓

Emit Transfer event

↓

Return success

↓

Other functions: approve, transferFrom, allowance

↓

Update allowances and balances accordingly

↓

Emit Approval event

↓

Return success

↓

End

This flow shows how an ERC-20 token contract is deployed, manages balances, and processes transfers and approvals step-by-step.

Execution Sample

Blockchain / Solidity

contract SimpleToken {
    mapping(address => uint) balances;
    uint totalSupply = 1000;

    constructor() {
        balances[msg.sender] = totalSupply;
    }

    function transfer(address to, uint amount) public returns (bool) {
        if (balances[msg.sender] >= amount) {
            balances[msg.sender] -= amount;
            balances[to] += amount;
            return true;
        }
        return false;
    }
}

This code defines a simple ERC-20 token transfer function that moves tokens if the sender has enough balance.

Execution Table

Step	Action	Sender balance	Amount	Receiver balance	Condition (sender balance >= amount)	Result	Return value
1	Initial balances set: sender=1000, receiver=0	1000	N/A	0	N/A	Setup complete	N/A
2	Call transfer(to=receiver, amount=200)	1000	200	0	1000 >= 200 is True	Balances updated	true
3	Subtract 200 from sender	800	200	0	N/A	Sender balance updated	N/A
4	Add 200 to receiver	800	200	200	N/A	Receiver balance updated	N/A
5	Return true to caller	800	200	200	N/A	Transfer successful	true
6	Call transfer(to=receiver, amount=900)	800	900	200	800 >= 900 is False	Transfer failed	false
7	Return false to caller	800	900	200	N/A	Transfer unsuccessful	false

💡 Execution stops when transfer returns false due to insufficient sender balance.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	After Step 7
balances[sender]	1000	1000	800	800	800	800	800
balances[receiver]	0	0	0	200	200	200	200
amount	N/A	200	200	200	200	900	900
return value	N/A	N/A	N/A	N/A	true	N/A	false

Key Moments - 3 Insights

Why does the transfer fail when the amount is 900 but the sender balance is 800?

Because the condition 'sender balance >= amount' is false (800 >= 900 is false), so the transfer does not proceed and returns false, as shown in step 6 of the execution_table.

What happens to the balances if the transfer amount is exactly equal to the sender's balance?

The transfer succeeds because the condition 'sender balance >= amount' is true when equal. The sender's balance becomes zero, and the receiver's balance increases by that amount, similar to step 2-5 but with amount equal to sender balance.

Why do we emit events like Transfer or Approval in ERC-20?

Events notify external apps about token movements or approvals. Though not shown in the simple code, emitting events after balance changes helps wallets and explorers track token activity.

Visual Quiz - 3 Questions

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

A 1000

B 200

C 800

D 0

💡 Hint

Check the 'balances[sender]' row in variable_tracker after step 4.

At which step does the transfer function return false?

A Step 5

B Step 7

C Step 3

D Step 2

💡 Hint

Look at the 'Return value' column in execution_table for the false return.

If the sender's initial balance was 500 instead of 1000, what would happen at step 2 when transferring 200?

A Transfer would succeed and sender balance becomes 300

B Transfer would succeed and sender balance becomes 700

C Transfer would fail because 500 < 200

D Transfer would fail because 200 > 500

💡 Hint

Compare the condition 'sender balance >= amount' with new balance 500 and amount 200.

Concept Snapshot

ERC-20 is a standard for fungible tokens on Ethereum.
It defines functions like transfer, approve, transferFrom, and events.
Balances are tracked in a mapping from address to uint.
Transfers check sender balance before moving tokens.
Approvals allow others to spend tokens on your behalf.
Events notify external apps of token changes.

Full Transcript

This visual execution trace shows how an ERC-20 token contract works step-by-step. First, the contract is deployed with a total supply and balances are set. When a user calls transfer, the contract checks if the sender has enough tokens. If yes, it subtracts the amount from the sender and adds it to the receiver, then returns true. If not, it returns false and the transfer fails. The variable tracker shows how balances change after each step. Key moments clarify why transfers fail or succeed and the role of events. The quiz tests understanding of balances and return values during execution.

Practice

1. What is the main purpose of the ERC-20 standard in Ethereum?

easy

A. To ensure tokens have a common set of functions for compatibility

B. To create unique non-fungible tokens

C. To define the Ethereum network consensus rules

D. To manage smart contract deployment costs

Solution

1. Step 1: Understand ERC-20 purpose

   ERC-20 defines a common interface for fungible tokens to work uniformly.

2. Step 2: Identify the correct purpose

   This standard allows wallets and apps to interact with tokens easily by using the same functions.

3. Final Answer:

   To ensure tokens have a common set of functions for compatibility -> Option A

4. Quick Check:

   ERC-20 = Common token interface [OK]

Hint: ERC-20 standardizes token functions for easy use [OK]

Common Mistakes:

• Confusing ERC-20 with NFT standards
• Thinking ERC-20 controls Ethereum network rules
• Assuming ERC-20 manages deployment costs

2. Which of the following is the correct function signature to check a token balance in ERC-20?

easy

A. function balanceOf(address owner) external view returns (uint256);

B. function getBalance(address owner) public returns (uint256);

C. function balance(address owner) external returns (bool);

D. function checkBalance(address owner) public view returns (bool);

Solution

1. Step 1: Recall ERC-20 balance function

   The standard defines balanceOf as a view function returning a uint256 balance.

2. Step 2: Match function signature

   function balanceOf(address owner) external view returns (uint256); matches the exact signature: external view returns (uint256).

3. Final Answer:

   function balanceOf(address owner) external view returns (uint256); -> Option A

4. Quick Check:

   balanceOf = correct signature [OK]

Hint: balanceOf returns uint256 and is a view function [OK]

Common Mistakes:

• Using wrong function name like getBalance
• Missing view keyword for read-only function
• Returning bool instead of uint256

3. Given this Solidity snippet from an ERC-20 token contract:

function transfer(address to, uint256 amount) public returns (bool) {
    if (balances[msg.sender] < amount) {
        return false;
    }
    balances[msg.sender] -= amount;
    balances[to] += amount;
    emit Transfer(msg.sender, to, amount);
    return true;
}

What will transfer return if the sender has 50 tokens and tries to send 60 tokens?

medium

A. true

B. false

C. It will throw an error

D. It will return zero

Solution

1. Step 1: Check sender balance condition

   The function checks if sender's balance is less than amount; if yes, returns false.

2. Step 2: Apply given values

   Sender has 50 tokens but tries to send 60, so condition is true and function returns false.

3. Final Answer:

   false -> Option B

4. Quick Check:

   Insufficient balance returns false [OK]

Hint: Transfer returns false if balance is insufficient [OK]

Common Mistakes:

• Assuming it throws error instead of returning false
• Thinking it returns true regardless
• Confusing return value with event emission

4. Identify the error in this ERC-20 approve function snippet:

function approve(address spender, uint256 amount) public returns (bool) {
    allowances[msg.sender][spender] = amount;
    emit Approval(msg.sender, spender, amount);
    return true;
}

What is the common security issue with this implementation?

medium

A. It does not emit the Approval event

B. It does not check if spender is zero address

C. It allows race condition by directly setting allowance

D. It returns false instead of true

Solution

1. Step 1: Understand approve race condition

   Directly setting allowance can cause race conditions if spender uses old and new allowance simultaneously.

2. Step 2: Identify missing mitigation

   Safe implementations require resetting allowance to zero before changing it to new value to avoid this issue.

3. Final Answer:

   It allows race condition by directly setting allowance -> Option C

4. Quick Check:

   approve race condition = direct allowance set [OK]

Hint: Always reset allowance to zero before changing it [OK]

Common Mistakes:

• Thinking missing zero address check is main issue
• Assuming Approval event is missing
• Believing return value is incorrect

5. You want to create an ERC-20 token that charges a 1% fee on every transfer and sends it to a fee collector address. Which modification to the transfer function correctly implements this?

hard

A. Send full amount to recipient, then send 1% from sender to collector

B. Add 1% to amount, send full amount to recipient, send fee separately

C. Send full amount to recipient and fee collector equally

D. Deduct 1% from amount, send fee to collector, send rest to recipient

Solution

1. Step 1: Calculate fee and net transfer

   Calculate 1% fee from amount, subtract it to get net amount to recipient.

2. Step 2: Transfer fee and net amount correctly

   Send fee to fee collector address and net amount to recipient to implement fee deduction.

3. Final Answer:

   Deduct 1% from amount, send fee to collector, send rest to recipient -> Option D

4. Quick Check:

   Fee deducted and sent correctly = Deduct 1% from amount, send fee to collector, send rest to recipient [OK]

Hint: Subtract fee from amount before sending tokens [OK]

Common Mistakes:

• Adding fee on top of amount instead of deducting
• Sending full amount to recipient and fee separately from sender
• Splitting amount equally between recipient and fee collector