Checks-Effects-Interactions pattern in Blockchain / Solidity - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of a simple withdrawal function using Checks-Effects-Interactions

What is the output when calling withdraw(50) on this contract if the initial balance is 100?

Blockchain / Solidity

contract SimpleBank {
    mapping(address => uint) public balances;

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

    function withdraw(uint amount) public returns (string memory) {
        require(balances[msg.sender] >= amount, "Insufficient balance"); // Check
        balances[msg.sender] -= amount; // Effect
        (bool success, ) = msg.sender.call{value: amount}(""); // Interaction
        require(success, "Transfer failed");
        return "Withdrawal successful";
    }

    receive() external payable {}
}

A Revert with "Transfer failed"

B Revert with "Insufficient balance"

C "Withdrawal successful"

D No output, transaction runs out of gas

💡 Hint

Think about the order: check balance, update balance, then send funds.

The function first checks if the sender has enough balance, then reduces it, and finally sends the amount. Since the initial balance is 100 and withdrawal is 50, all steps succeed and the function returns "Withdrawal successful".

❓ Predict Output

intermediate

Effect of changing order in Checks-Effects-Interactions

What happens if the withdraw function sends funds before updating the balance?

Blockchain / Solidity

function withdraw(uint amount) public returns (string memory) {
    require(balances[msg.sender] >= amount, "Insufficient balance"); // Check
    (bool success, ) = msg.sender.call{value: amount}(""); // Interaction
    require(success, "Transfer failed");
    balances[msg.sender] -= amount; // Effect
    return "Withdrawal successful";
}

A Safe because balance is checked first

B Vulnerable to reentrancy attack, balance not updated before sending funds

C Transaction always reverts due to order

D No difference from original function

💡 Hint

Consider what happens if the receiver calls back into withdraw before balance changes.

Sending funds before updating balance allows the receiver to call withdraw again before balance is reduced, causing multiple withdrawals and a reentrancy attack.

🔧 Debug

advanced

Identify the bug in this contract violating Checks-Effects-Interactions

Which line causes a security risk violating the Checks-Effects-Interactions pattern?

Blockchain / Solidity

contract Vulnerable {
    mapping(address => uint) public balances;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint amount) public {
        require(balances[msg.sender] >= amount, "Insufficient balance");
        (bool sent, ) = msg.sender.call{value: amount}("");
        require(sent, "Failed to send Ether");
        balances[msg.sender] -= amount;
    }
}

A Line with call to msg.sender.call{value: amount}("")

B Line with require(balances[msg.sender] >= amount, "Insufficient balance")

C Line with balances[msg.sender] -= amount

D Line with balances[msg.sender] += msg.value

💡 Hint

Look for interaction before effect.

The call to send Ether happens before updating the balance, allowing reentrancy attacks. The effect (balance update) should happen before interaction.

🧠 Conceptual

advanced

Why is Checks-Effects-Interactions pattern important?

Which statement best explains the main reason for using the Checks-Effects-Interactions pattern in smart contracts?

A To prevent reentrancy attacks by updating state before external calls

B To reduce gas costs by minimizing external calls

C To allow multiple external calls before state changes

D To make contracts compatible with all Ethereum clients

💡 Hint

Think about what kind of attack this pattern helps avoid.

Updating the contract's state before making external calls prevents attackers from exploiting reentrancy by calling back into the contract before state changes.

🚀 Application

expert

How many times can a reentrant call withdraw funds in this contract?

Given this contract, how many times can a malicious contract reenter and withdraw funds before balance updates?

Blockchain / Solidity

contract ReentrancyExample {
    mapping(address => uint) public balances;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint amount) public {
        require(balances[msg.sender] >= amount, "Insufficient balance");
        (bool sent, ) = msg.sender.call{value: amount}("");
        require(sent, "Failed to send Ether");
        balances[msg.sender] -= amount;
    }
}

A Exactly twice, due to call stack limits

B Only once, because require prevents multiple calls

C Zero times, function reverts immediately

D Multiple times until contract runs out of gas or balance

💡 Hint

Consider that balance is updated after sending funds.

Because balance is updated after sending funds, the attacker can reenter multiple times withdrawing repeatedly until funds or gas run out.

Practice

1.

What is the main purpose of the Checks-Effects-Interactions pattern in smart contracts?

easy

A. To reduce the gas cost of transactions

B. To prevent reentrancy attacks by ordering operations safely

C. To increase the speed of contract execution

D. To allow contracts to call external APIs

Solution

1. Step 1: Understand the pattern's purpose

   The Checks-Effects-Interactions pattern is designed to prevent security issues by ordering operations carefully.

2. Step 2: Identify the main security benefit

   By checking conditions first, updating state second, and interacting last, it prevents reentrancy attacks.

3. Final Answer:

   To prevent reentrancy attacks by ordering operations safely -> Option B

4. Quick Check:

   Pattern purpose = Prevent reentrancy [OK]

Hint: Remember: check first, update second, interact last [OK]

Common Mistakes:

• Thinking it speeds up contract execution
• Believing it reduces gas costs
• Assuming it enables external API calls

2.

Which of the following Solidity code snippets correctly follows the Checks-Effects-Interactions pattern?

function withdraw(uint amount) public {
  require(balances[msg.sender] >= amount);
  (bool success, ) = msg.sender.call{value: amount}('');
  require(success);
  balances[msg.sender] -= amount;
}

easy

A. Yes, it checks, then interacts, then effects

B. Yes, it updates state before checks

C. No, it interacts before updating state

D. No, it updates state before interaction

Solution

1. Step 1: Analyze the order of operations

   The code first checks the balance, then calls the external address, then updates the balance.

2. Step 2: Compare with pattern order

   The pattern requires checks, then effects (state update), then interactions. Here, interaction happens before effects.

3. Final Answer:

   No, it interacts before updating state -> Option C

4. Quick Check:

   Interaction before effect = Incorrect order [OK]

Hint: State update must come before external calls [OK]

Common Mistakes:

• Ignoring the order of state update and interaction
• Thinking checks alone are enough
• Confusing effects with interactions

3.

What will be the output of the following Solidity function if balances[msg.sender] is 100 and amount is 50?

function withdraw(uint amount) public {
  require(balances[msg.sender] >= amount);
  balances[msg.sender] -= amount;
  (bool success, ) = msg.sender.call{value: amount}('');
  require(success);
}

Assume the call succeeds.

medium

A. The balance becomes 50 and 50 ether is sent

B. The balance remains 100 and 50 ether is sent

C. The balance becomes 50 but no ether is sent

D. Transaction reverts due to incorrect order

Solution

1. Step 1: Check balance and update state

   The require passes since 100 >= 50, then balance is reduced to 50.

2. Step 2: Send ether and confirm success

   The call sends 50 ether and returns success, so require(success) passes.

3. Final Answer:

   The balance becomes 50 and 50 ether is sent -> Option A

4. Quick Check:

   Balance updated then ether sent = Correct [OK]

Hint: State updates before sending ether means balance changes [OK]

Common Mistakes:

• Thinking balance stays the same after withdrawal
• Assuming call fails without reason
• Confusing order causing revert

4.

Identify the bug in this Solidity function violating the Checks-Effects-Interactions pattern:

function withdraw(uint amount) public {
  (bool success, ) = msg.sender.call{value: amount}('');
  require(success);
  require(balances[msg.sender] >= amount);
  balances[msg.sender] -= amount;
}

medium

A. It correctly follows the pattern

B. It updates balance before checking conditions

C. It does not check for call success

D. It calls external address before checking balance

Solution

1. Step 1: Review order of operations

   The function calls the external address first, then checks balance, then updates state.

2. Step 2: Compare with pattern rules

   Pattern requires checks first, then effects, then interactions. Here, interaction is first, violating the pattern.

3. Final Answer:

   It calls external address before checking balance -> Option D

4. Quick Check:

   Interaction before checks = Bug [OK]

Hint: Always check before calling external contracts [OK]

Common Mistakes:

• Ignoring the order of require and call
• Assuming call success check is missing
• Thinking balance update order is wrong

5.

You want to write a Solidity function that sends a reward to a user only if they have enough points. Which code snippet correctly applies the Checks-Effects-Interactions pattern?

function rewardUser(address user, uint points) public {
  // Option A
  require(userPoints[user] >= points);
  userPoints[user] -= points;
  (bool sent, ) = user.call{value: points * 1 ether}('');
  require(sent);

  // Option B
  (bool sent, ) = user.call{value: points * 1 ether}('');
  require(sent);
  require(userPoints[user] >= points);
  userPoints[user] -= points;

  // Option C
  userPoints[user] -= points;
  require(userPoints[user] >= 0);
  (bool sent, ) = user.call{value: points * 1 ether}('');
  require(sent);

  // Option D
  require(userPoints[user] >= points);
  (bool sent, ) = user.call{value: points * 1 ether}('');
  require(sent);
  userPoints[user] -= points;
}

hard

A. Option A

B. Option B

C. Option C

D. Option D

Solution

1. Step 1: Analyze the order of operations

   The correct snippet first requires userPoints[user] >= points (checks), then subtracts points (effects), then sends ether via call (interactions).

2. Step 2: Identify violations in others

   The second snippet interacts before checks; the third updates state before checks; the fourth interacts before effects.

3. Final Answer:

   Option A -> Option A

4. Quick Check:

   Checks -> Effects -> Interactions = Correct snippet [OK]

Hint: Check first, update second, call last for safety [OK]

Common Mistakes:

• Calling external before checking conditions
• Updating state before checks
• Mixing order of effects and interactions