Checks-Effects-Interactions pattern in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Checks-Effects-Interactions pattern

Start Function Call

↓

Perform Checks

↓

Update State (Effects)

↓

Interact with External Contracts

↓

End Function

This pattern ensures safety by first checking conditions, then updating contract state, and finally interacting with other contracts.

Execution Sample

Blockchain / Solidity

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

Withdraw function that first checks balance, then updates it, and finally sends Ether to the user.

Execution Table

Step	Action	Evaluation/State	Result/Effect
1	Check if user balance >= amount	balances[msg.sender] = 100, amount = 50	True, continue
2	Subtract amount from user balance	balances[msg.sender] = 100 - 50	balances[msg.sender] = 50
3	Send Ether to user (external call)	Call msg.sender with 50 Ether	Ether sent successfully
4	Require success of external call	success = true	Function completes successfully

💡 Execution stops after successful external call and state update

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
balances[msg.sender]	100	100	50	50	50
amount	50	50	50	50	50
success	undefined	undefined	undefined	true	true

Key Moments - 3 Insights

Why do we update the balance before sending Ether?

Updating the balance first (Step 2) prevents reentrancy attacks by ensuring the contract state is correct before external calls (Step 3). See execution_table rows 2 and 3.

What happens if the check fails?

If the check in Step 1 fails, the function stops immediately and no state changes or external calls happen, preventing unsafe operations.

Why do we require success after the external call?

Requiring success (Step 4) ensures the external call did not fail silently, so the function only completes if Ether was sent properly.

Visual Quiz - 3 Questions

Look at the execution_table, what is the balance after Step 2?

A 100

B 0

C 50

D Undefined

💡 Hint

Check the 'balances[msg.sender]' value in variable_tracker after Step 2

At which step does the contract interact with an external address?

A Step 3

B Step 2

C Step 1

D Step 4

💡 Hint

Look at the 'Action' column in execution_table for external calls

If the check in Step 1 fails, what happens next?

A State updates and external call still happen

B Function stops immediately, no changes

C Only external call happens

D Balance is set to zero

💡 Hint

Refer to key_moments about what happens if the check fails

Concept Snapshot

Checks-Effects-Interactions pattern:
1. Checks: Verify conditions first (e.g., require statements).
2. Effects: Update contract state variables next.
3. Interactions: Finally, call external contracts.
This order prevents reentrancy and ensures safe state changes.

Full Transcript

The Checks-Effects-Interactions pattern is a safety method in blockchain programming. First, the contract checks if conditions are met, like if the user has enough balance. Then, it updates its own state, such as subtracting the withdrawn amount. Lastly, it interacts with external contracts, for example sending Ether. This order helps avoid security problems like reentrancy attacks. In the example, the function withdraw checks the balance, updates it, then sends Ether. If any check fails, the function stops immediately. This pattern is important for writing safe smart contracts.

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