Understanding Reentrancy Attacks in Smart Contracts (The DAO Hack Explained)

What Is a Reentrancy Attack?

1. A reentrancy attack occurs when an external contract calls back into the current contract before the initial execution is complete.

2. This vulnerability arises due to improper state management—specifically, when state variables are updated after external calls rather than before.

3. The attacker deploys a malicious contract containing a fallback function that recursively invokes the vulnerable function in the target contract.

4. Each recursive call re-enters the same logic path, draining funds repeatedly without the balance being updated until the entire call stack unwinds.

5. Such attacks exploit Ethereum’s synchronous, single-threaded execution model where external calls retain control flow within the calling context.

The DAO Incident: A Historical Breakdown

1. The DAO was a decentralized autonomous organization launched in 2016 on Ethereum, designed as a venture capital fund governed by smart contract rules.

2. Its code allowed token holders to split from the DAO and reclaim ether by calling a splitDAO function.

3. That function transferred ether to the requester’s address before updating the internal balance, creating a classic reentrancy window.

4. An attacker deployed a contract with a fallback function that triggered splitDAO again upon receiving funds.

5. Over multiple nested calls, more than 3.6 million ETH—worth over $50 million at the time—was siphoned before the transaction reverted or halted.

How Ethereum’s Execution Model Enables Reentrancy

1. Every external call in Solidity executes in the same transactional context, preserving memory, storage, and call stack visibility.

2. There is no automatic reentrancy guard unless explicitly implemented via patterns like Checks-Effects-Interactions.

3. Gas limits do not prevent recursion; they only constrain total computation, and fallback functions require minimal gas to execute.

4. The EVM does not enforce isolation between caller and callee—state changes made by the callee are visible to the caller during its ongoing execution.

5. Developers often underestimate how deeply interdependent contract interactions can become, especially when third-party tokens or oracles are involved.

Common Code Patterns That Invite Reentrancy

1. Updating balances or flags after sending ether or calling external contracts instead of before.

2. Using call.value()() without validating return values or limiting recursion depth.

3. Relying on this.balance for accounting instead of tracking balances in storage variables.

4. Implementing withdrawal patterns without locks, mutexes, or reentrancy modifiers such as OpenZeppelin’s ReentrancyGuard.

5. Failing to audit inherited logic—especially when using proxy patterns or upgradable contracts where delegatecall preserves context.

Frequently Asked Questions

Q: Can reentrancy happen in ERC-20 transfers?A: Standard ERC-20 transfer functions do not trigger external calls, so native reentrancy is not possible. However, extensions like transferFrom combined with hooks (e.g., in ERC-777) introduce callback surfaces where reentrancy may occur.

Q: Was the DAO hack reversible because of a hard fork?A: Yes. The Ethereum community executed a hard fork to restore stolen funds by rewriting the chain history, resulting in Ethereum and Ethereum Classic splitting.

Q: Do modern Solidity versions prevent reentrancy by default?A: No. Solidity v0.8.x includes safer arithmetic and revert behavior but does not auto-inject reentrancy protection. Developers must still apply defensive patterns manually.

Q: Is using require(msg.sender.call{value: amount}('')) safer than address.send()?A: Neither is inherently safe. Both allow reentrancy if used before state updates. The critical factor is interaction ordering—not the specific call mechanism.