Withdrawal patterns in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Withdrawal patterns

User requests withdrawal

↓

Check user balance

↓

Is balance sufficient?

No→Reject withdrawal

Yes↓

Lock funds

↓

Process withdrawal transaction

↓

Confirm transaction success?

No→Unlock funds, notify failure

Yes↓

Update user balance

↓

Notify user of success

↓

END

This flow shows how a withdrawal request is handled step-by-step, checking balance, locking funds, processing, and confirming success.

Execution Sample

Blockchain / Solidity

def withdraw(user, amount):
    if user.balance < amount:
        return "Insufficient funds"
    user.lock_funds(amount)
    success = blockchain.send_transaction(user.address, amount)
    if not success:
        user.unlock_funds(amount)
        return "Transaction failed"
    user.balance -= amount
    return "Withdrawal successful"

This code handles a withdrawal by checking balance, locking funds, sending transaction, and updating balance.

Execution Table

Step	Action	Condition/Evaluation	Result/State Change	Output
1	Check if user.balance < amount	user.balance=100, amount=50	Condition False (100 >= 50)	Continue
2	Lock funds	Lock 50 units	Funds locked: 50	No output
3	Send transaction	Simulate blockchain.send_transaction	Transaction success = True	No output
4	Check transaction success	success == True	Proceed to update balance	No output
5	Update user.balance	user.balance = 100 - 50	user.balance = 50	No output
6	Return success message	N/A	N/A	Withdrawal successful
7	End	N/A	N/A	Process complete

💡 Withdrawal completes successfully after balance check, locking funds, transaction success, and balance update.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 5	Final
user.balance	100	100	100	100	50	50
amount	50	50	50	50	50	50
funds_locked	0	0	50	50	50	50
transaction_success	N/A	N/A	N/A	True	True	True

Key Moments - 3 Insights

Why do we lock funds before sending the transaction?

Locking funds prevents the user from spending the same amount twice while the transaction is pending, as shown in step 2 of the execution_table.

What happens if the transaction fails after locking funds?

If the transaction fails, the locked funds are unlocked to restore the user's balance, as explained in the code and implied in the flow after the transaction check.

Why do we update the user balance only after confirming transaction success?

Updating balance only after success ensures the user’s balance reflects actual funds spent, preventing errors or double spending, as seen in step 5 of the execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, what is the user.balance after step 5?

A 0

B 50

C 100

D 150

💡 Hint

Check the 'Result/State Change' column at step 5 in the execution_table.

At which step is the transaction success evaluated?

A Step 4

B Step 2

C Step 3

D Step 5

💡 Hint

Look for the step where 'Check transaction success' is performed in the execution_table.

If the user.balance was 40 and amount 50, what would happen at step 1?

A Funds locked anyway

B Condition False, withdrawal proceeds

C Condition True, withdrawal rejected

D Transaction sent immediately

💡 Hint

Refer to the condition check in step 1 of the execution_table and variable_tracker for balance values.

Concept Snapshot

Withdrawal Patterns in Blockchain:
- Check user balance before withdrawal
- Lock funds to prevent double spending
- Send transaction to blockchain
- Confirm transaction success
- Update user balance only after success
- Unlock funds if transaction fails

Full Transcript

This visual execution trace shows how a withdrawal request is processed in blockchain systems. First, the user's balance is checked to ensure sufficient funds. If enough, the requested amount is locked to prevent spending it elsewhere. Then, a transaction is sent to the blockchain network. If the transaction succeeds, the user's balance is updated by subtracting the withdrawn amount. If the transaction fails, the locked funds are released back to the user. This process ensures security and consistency in handling withdrawals.

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