ERC-20 implementation in Blockchain / Solidity - Time & Space Complexity

Time Complexity: ERC-20 implementation

O(1)

Understanding Time Complexity

When working with ERC-20 tokens, it's important to understand how the time it takes to run functions changes as the number of users or transactions grows.

We want to know how the cost of operations like transferring tokens or checking balances grows with more users.

Scenario Under Consideration

Analyze the time complexity of the following ERC-20 transfer function.

function transfer(address to, uint256 amount) public returns (bool) {
    require(balanceOf[msg.sender] >= amount, "Insufficient balance");
    balanceOf[msg.sender] -= amount;
    balanceOf[to] += amount;
    emit Transfer(msg.sender, to, amount);
    return true;
}

This function moves tokens from the sender to another address and updates balances.

Identify Repeating Operations

Look for loops or repeated steps inside the function.

• Primary operation: Simple balance checks and updates.
• How many times: Each call runs these steps once, no loops or recursion.

How Execution Grows With Input

The function does the same fixed steps no matter how many users or tokens exist.

Input Size (n)	Approx. Operations
10	5 steps
100	5 steps
1000	5 steps

Pattern observation: The number of operations stays the same even if more users or tokens exist.

Final Time Complexity

Time Complexity: O(1)

This means the transfer function takes the same amount of time no matter how many users or tokens there are.

Common Mistake

[X] Wrong: "The transfer function takes longer as more users hold tokens."

[OK] Correct: The function only updates balances for two addresses, so it does not check or loop through all users.

Interview Connect

Understanding that simple token transfers run in constant time helps you explain how blockchain operations stay efficient even as networks grow.

Self-Check

"What if the transfer function needed to update a list of all token holders? How would the time complexity change?"

Practice

1. What is the main purpose of the balanceOf function in an ERC-20 token contract?

easy

A. To approve another address to spend tokens

B. To transfer tokens from one address to another

C. To check the token balance of a specific address

D. To mint new tokens to an address

Solution

1. Step 1: Understand the role of balanceOf

   The balanceOf function returns how many tokens a given address owns.

2. Step 2: Compare with other functions

   Functions like transfer move tokens, approve allows spending, and minting creates tokens. These are different from checking balance.

3. Final Answer:

   To check the token balance of a specific address -> Option C

4. Quick Check:

   balanceOf = check balance [OK]

Hint: balanceOf always returns token count for an address [OK]

Common Mistakes:

• Confusing balanceOf with transfer function
• Thinking approve checks balances
• Mixing minting with balance checking

2. Which of the following is the correct Solidity function signature for transferring tokens in an ERC-20 contract?

easy

A. function transfer(address to, uint256 amount) public returns (bool);

B. function transfer(uint256 amount, address to) public returns (bool);

C. function transfer(address to) public returns (uint256);

D. function transfer(address from, address to, uint256 amount) public;

Solution

1. Step 1: Recall ERC-20 transfer signature

   The standard transfer function takes the recipient address first, then the amount, and returns a boolean.

2. Step 2: Check each option

   function transfer(address to, uint256 amount) public returns (bool); matches the standard: transfer(address to, uint256 amount) public returns (bool). Others have wrong parameter order, missing return, or extra parameters.

3. Final Answer:

   function transfer(address to, uint256 amount) public returns (bool); -> Option A

4. Quick Check:

   transfer(to, amount) returns bool [OK]

Hint: transfer always has (address to, uint256 amount) and returns bool [OK]

Common Mistakes:

• Swapping parameter order
• Omitting return type
• Adding extra parameters not in standard

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

mapping(address => uint256) balances;

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

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

medium

A. true

B. Returns the remaining balance

C. Throws an error

D. false

Solution

1. Step 1: Check balance condition

   The function checks if balances[msg.sender] is at least amount. Here, 50 < 60, so condition fails.

2. Step 2: Determine function return

   Since condition fails, the function skips token transfer and returns false.

3. Final Answer:

   false -> Option D

4. Quick Check:

   Insufficient balance returns false [OK]

Hint: Transfer returns false if sender lacks enough tokens [OK]

Common Mistakes:

• Assuming transfer throws error on insufficient balance
• Thinking it returns true anyway
• Confusing return value with balance amount

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

mapping(address => mapping(address => uint256)) allowances;

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

medium

A. No bug, function is correct

B. Should emit an Approval event after setting allowance

C. Should check if amount is less than balance

D. Should decrease allowance instead of setting it

Solution

1. Step 1: Review ERC-20 approve requirements

   The standard requires emitting an Approval event after changing allowance for transparency.

2. Step 2: Check function code

   The function sets allowance but does not emit the Approval event, missing a key part of the standard.

3. Final Answer:

   Should emit an Approval event after setting allowance -> Option B

4. Quick Check:

   approve must emit Approval event [OK]

Hint: approve must emit Approval event to follow standard [OK]

Common Mistakes:

• Ignoring event emission
• Checking balance in approve (not required)
• Decreasing allowance instead of setting

5. You want to add a feature to your ERC-20 token that prevents transfers when the contract is paused. Which is the best way to implement this without breaking the ERC-20 standard?

hard

A. Add a paused boolean and require it false in transfer and transferFrom functions

B. Remove the transfer function and replace it with a new function that checks pause

C. Add a new function pauseTransfer that users must call before transferring

D. Modify the balanceOf function to return zero when paused

Solution

1. Step 1: Understand pause feature integration

   To pause transfers, the contract needs a state variable like paused and checks in transfer functions.

2. Step 2: Check ERC-20 compliance

   Removing or renaming transfer breaks the standard. Changing balanceOf output breaks expected behavior. Adding a separate function for pause is not standard.

3. Final Answer:

   Add a paused boolean and require it false in transfer and transferFrom functions -> Option A

4. Quick Check:

   Pause by require(!paused) in transfer functions [OK]

Hint: Use a paused flag and require it false in transfer methods [OK]

Common Mistakes:

• Removing or renaming standard functions
• Changing balanceOf behavior
• Adding extra steps users must call