Withdrawal patterns in Blockchain / Solidity - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Understanding withdrawal pattern output

What is the output of this Solidity contract snippet when calling withdraw() after depositing 5 ether?

Blockchain / Solidity

pragma solidity ^0.8.0;

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

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

    function withdraw() public {
        uint amount = balances[msg.sender];
        require(amount > 0, "No balance to withdraw");
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");
        balances[msg.sender] = 0;
    }
}

A The contract runs out of gas and reverts

B The contract throws an error because balances[msg.sender] is not updated before transfer

C The user balance remains 5 ether after withdrawal

D The user receives 5 ether and their balance resets to 0

💡 Hint

Think about the order of state update and transfer in the withdrawal function.

The contract sends the ether first and then sets the user's balance to zero. Since the transfer is done via call and the balance is reset after, the user receives the full amount and the balance is cleared.

🧠 Conceptual

intermediate

Why use withdrawal pattern in smart contracts?

Which of the following best explains why the withdrawal pattern is recommended over direct transfers in smart contracts?

A It prevents reentrancy attacks by letting users withdraw funds themselves

B It reduces gas costs by batching transfers automatically

C It allows contracts to send ether to multiple users simultaneously

D It guarantees instant transfer of ether without delays

💡 Hint

Think about security risks when sending ether directly.

Withdrawal pattern avoids reentrancy attacks by letting users pull their funds instead of contracts pushing funds directly, which can trigger malicious fallback functions.

🔧 Debug

advanced

Identify the bug in this withdrawal pattern implementation

What is the main bug in this Solidity withdrawal function?

Blockchain / Solidity

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

A The call method is deprecated and should use transfer instead

B The balance is set to zero after sending ether, risking reentrancy attack

C The function does not check if msg.sender is a contract

D The require statement should be after setting balance to zero

💡 Hint

Consider what happens if the recipient is a contract with fallback code.

Setting the balance to zero after sending ether allows a malicious contract to reenter the withdraw function before balance is cleared, draining funds.

📝 Syntax

advanced

Which option correctly implements a safe withdrawal pattern?

Choose the correct Solidity code snippet that safely implements the withdrawal pattern preventing reentrancy.

A

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

B

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

C

function withdraw() public {
    uint amount = balances[msg.sender];
    balances[msg.sender] = 0;
    (bool success, ) = msg.sender.transfer(amount);
    require(success);
}

D

function withdraw() public {
    uint amount = balances[msg.sender];
    require(amount > 0);
    balances[msg.sender] = 0;
    msg.sender.transfer(amount);
}

💡 Hint

Remember to update state before external calls and use recommended call syntax.

Option A sets the balance to zero before calling external address, preventing reentrancy. It uses call with require to check success, which is the recommended pattern.

🚀 Application

expert

Calculate total withdrawn after multiple withdrawals

Given this contract snippet, what is the total ether withdrawn by user after calling withdraw() twice, assuming deposit() was called once with 3 ether?

Blockchain / Solidity

pragma solidity ^0.8.0;

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

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

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

A 0 ether

B 6 ether

C 3 ether

D Reverts on second withdrawal

💡 Hint

Consider the balance after the first withdrawal and what happens on the second call.

After the first withdrawal, the balance is set to zero. The second withdrawal call fails the require check and reverts, so total withdrawn is 3 ether.

Practice

1. What is the main purpose of using a withdrawal pattern in blockchain smart contracts?

easy

A. To let users safely withdraw their funds by calling a function

B. To automatically send funds to users without their request

C. To increase the contract's balance automatically

D. To prevent users from withdrawing funds

Solution

1. Step 1: Understand withdrawal pattern purpose

   The withdrawal pattern lets users request their funds instead of sending automatically.

2. Step 2: Identify safety benefits

   This prevents security issues like reentrancy by updating balances before sending.

3. Final Answer:

   To let users safely withdraw their funds by calling a function -> Option A

4. Quick Check:

   Withdrawal pattern = user-initiated safe withdrawal [OK]

Hint: Withdrawal pattern means user calls to get funds safely [OK]

Common Mistakes:

• Thinking funds are sent automatically
• Confusing withdrawal with deposit
• Ignoring security benefits

2. Which of the following Solidity code snippets correctly implements the withdrawal pattern?

easy

A. function withdraw() public { payable(msg.sender).transfer(balances[msg.sender]); balances[msg.sender] = 0; }

B. function withdraw() public { payable(msg.sender).transfer(1 ether); }

C. function withdraw() public { uint amount = balances[msg.sender]; balances[msg.sender] = 0; payable(msg.sender).transfer(amount); }

D. function withdraw() public { balances[msg.sender] += 1 ether; }

Solution

1. Step 1: Check balance update before transfer

   function withdraw() public { uint amount = balances[msg.sender]; balances[msg.sender] = 0; payable(msg.sender).transfer(amount); } sets balance to zero before sending funds, preventing reentrancy.

2. Step 2: Verify other options

   function withdraw() public { payable(msg.sender).transfer(balances[msg.sender]); balances[msg.sender] = 0; } sends funds before zeroing balance (unsafe). Options C and D do not handle balances properly.

3. Final Answer:

   function withdraw() public { uint amount = balances[msg.sender]; balances[msg.sender] = 0; payable(msg.sender).transfer(amount); } -> Option C

4. Quick Check:

   Update balance before transfer = function withdraw() public { uint amount = balances[msg.sender]; balances[msg.sender] = 0; payable(msg.sender).transfer(amount); } [OK]

Hint: Set balance to zero before sending funds [OK]

Common Mistakes:

• Sending funds before updating balance
• Not updating balance at all
• Sending fixed amounts ignoring user balance

3. What will be the output if a user calls withdraw() twice in a row on this contract snippet?

mapping(address => uint) balances;

function withdraw() public {
  uint amount = balances[msg.sender];
  balances[msg.sender] = 0;
  payable(msg.sender).transfer(amount);
}

medium

A. The user receives funds both times

B. The user receives double the funds on second call

C. The contract throws an error on second call

D. The user receives funds only the first time, second call sends zero

Solution

1. Step 1: Analyze first withdraw call

   First call reads balance, sends funds, then sets balance to zero.

2. Step 2: Analyze second withdraw call

   Second call reads balance which is now zero, so sends zero funds.

3. Final Answer:

   The user receives funds only the first time, second call sends zero -> Option D

4. Quick Check:

   Balance zero after first withdraw = second call sends zero [OK]

Hint: Balance zeroed after first withdraw means second sends zero [OK]

Common Mistakes:

• Assuming funds sent twice
• Expecting error on second call
• Thinking balance resets automatically

4. Identify the bug in this withdrawal function:

function withdraw() public {
  payable(msg.sender).transfer(balances[msg.sender]);
  balances[msg.sender] = 0;
}

medium

A. Balance is never updated

B. Balance is updated after transfer, risking reentrancy attack

C. Function does not send funds

D. Function uses wrong address type

Solution

1. Step 1: Check order of operations

   The function sends funds before setting balance to zero.

2. Step 2: Understand security risk

   This allows reentrancy attacks where attacker calls withdraw repeatedly before balance is zeroed.

3. Final Answer:

   Balance is updated after transfer, risking reentrancy attack -> Option B

4. Quick Check:

   Update balance before transfer to prevent reentrancy [OK]

Hint: Always update balance before sending funds [OK]

Common Mistakes:

• Updating balance after transfer
• Ignoring reentrancy risks
• Not using payable correctly

5. You want to implement a withdrawal pattern that also logs each withdrawal event with amount and user address. Which of the following Solidity code snippets correctly does this safely?

hard

A. event Withdraw(address indexed user, uint amount);
function withdraw() public {
uint amount = balances[msg.sender];
balances[msg.sender] = 0;
payable(msg.sender).transfer(amount);
emit Withdraw(msg.sender, amount);
}

B. event Withdraw(address indexed user, uint amount);
function withdraw() public {
payable(msg.sender).transfer(balances[msg.sender]);
emit Withdraw(msg.sender, balances[msg.sender]);
balances[msg.sender] = 0;
}

C. event Withdraw(address indexed user, uint amount);
function withdraw() public {
emit Withdraw(msg.sender, balances[msg.sender]);
balances[msg.sender] = 0;
payable(msg.sender).transfer(balances[msg.sender]);
}

D. event Withdraw(address indexed user, uint amount);
function withdraw() public {
balances[msg.sender] = 0;
emit Withdraw(msg.sender, balances[msg.sender]);
payable(msg.sender).transfer(balances[msg.sender]);
}

Solution

1. Step 1: Check balance update and transfer order

   event Withdraw(address indexed user, uint amount); function withdraw() public { uint amount = balances[msg.sender]; balances[msg.sender] = 0; payable(msg.sender).transfer(amount); emit Withdraw(msg.sender, amount); } updates balance before transfer, preventing reentrancy.

2. Step 2: Verify event emits correct amount

   event Withdraw(address indexed user, uint amount); function withdraw() public { uint amount = balances[msg.sender]; balances[msg.sender] = 0; payable(msg.sender).transfer(amount); emit Withdraw(msg.sender, amount); } emits event after transfer with correct amount saved before zeroing balance.

3. Step 3: Check other options

   The other snippets emit event with wrong amount or update balance after transfer, causing errors or security risks.

4. Final Answer:

   event Withdraw(address indexed user, uint amount); function withdraw() public { uint amount = balances[msg.sender]; balances[msg.sender] = 0; payable(msg.sender).transfer(amount); emit Withdraw(msg.sender, amount); } -> Option A

5. Quick Check:

   Update balance, transfer, then emit event with saved amount [OK]

Hint: Save amount first, update balance, transfer, then emit event [OK]

Common Mistakes:

• Emitting event before saving amount
• Updating balance after transfer
• Emitting event with zero amount