Reentrancy Attack: Why The DAO Caused an Ethereum Fork

This article has three layers:

1. Layer 1: The Intuition: An ATM that dispenses cash before deducting the balance
2. Layer 2: Real-World Use: The DAO, various variants, and the 2023 Curve compiler incident
3. Layer 3: Engineering details and mathematical principles: Vulnerable code, fix patterns, reentrancy guards, read-only reentrancy, and cross-contract reentrancy

Layer 1: The Intuition

1.1 An ATM that dispenses cash before deducting the balance

A buggy ATM follows this process:

1. Check if the balance is sufficient;
2. Dispense cash;
3. Deduct the amount from the balance.

A fast-acting person presses "Withdraw" again the exact moment the cash is dispensed in step 2. The machine returns to step 1 to check the balance: it hasn't been deducted yet, so there is enough! It dispenses cash again... As long as they are fast enough, they can keep withdrawing until the machine is empty.

In smart contracts, "fast-acting" doesn't require a human to press buttons: when a recipient contract receives ETH, it automatically runs a function (receive / fallback), which can be used to call the withdraw function once more.

1.2 Why it is written this way

The human intuition for writing code is "give the money first, and if successful, record it in the ledger," which is fine in standard programming. However, in smart contracts, the act of "giving it away" hands over control to the recipient, and the recipient is untrusted.

Layer 2: Real-World Use

• The DAO (2016): A decentralized investment fund that raised about 14% of the circulating ETH at the time. The attacker exploited a reentrancy vulnerability in the split function to withdraw funds repeatedly. After intense debate, the Ethereum community chose a hard fork to return the stolen funds; dissenters continued to maintain the original chain, known as Ethereum Classic. This event also sparked the long-standing "Code is Law" debate.
• Curve / Vyper (2023): In this case, the contract code itself included a reentrancy guard, but the compiler had a bug in certain versions when implementing the guard, meaning the lock effectively did not work. This demonstrates that security must be verified all the way through the toolchain.

Layer 3: Principles and Engineering

3.1 Vulnerable Code

// Vulnerable
function withdraw() external {
    uint256 amount = balances[msg.sender];
    require(amount > 0);
    (bool ok, ) = msg.sender.call{value: amount}("");   // ① Transfer first: control is handed to the recipient
    require(ok);
    balances[msg.sender] = 0;                            // ② Update balance later: too late
}

Attacker contract:

receive() external payable {
    if (address(victim).balance >= 1 ether) {
        victim.withdraw();    // withdraw one more time between ① and ②
    }
}

3.2 Fix: Checks-Effects-Interactions

function withdraw() external {
    uint256 amount = balances[msg.sender];   // Check
    require(amount > 0);
    balances[msg.sender] = 0;                // Effect: update balance first
    (bool ok, ) = msg.sender.call{value: amount}("");   // Interaction: interact with external only at the end
    require(ok);
}

When the recipient tries to reenter, the balance is already 0, and require fails directly.

3.3 Reentrancy Guard

modifier nonReentrant() {
    require(!locked);
    locked = true;
    _;
    locked = false;
}

OpenZeppelin's ReentrancyGuard follows this logic. It is a second line of defense and cannot replace the correct order of operations.

3.4 More subtle variants

3.5 Testing Methods

• Write a dedicated "malicious recipient" contract in unit tests that attempts to reenter every external function during the callback;
• Static analysis tools (such as Slither) can automatically flag code that "modifies state after an external call";
• Invariant testing: "The contract's ETH balance ≥ the sum of all user balances" must hold true under any call sequence (see Smart Contract Auditing and Formal Verification).

Summary