On June 17, 2016, an attacker drained 3.6 million ETH (worth ~$60M at the time) from The DAO — the largest crowdfunding project in history. The vulnerability? Reentrancy. It was so devastating that it split the Ethereum blockchain in two, creating Ethereum Classic.
A decade later, reentrancy keeps causing millions in losses — just in subtler forms. Here's why.
The Original: The DAO Hack
The DAO's withdraw function
Called the user's address to send ETH before updating their balance in storage
Attacker's fallback function
The receive() function in the attacker's contract immediately called withdraw() again
Recursive drain
Because the balance wasn't updated yet, each recursive call withdrew the same amount — draining the contract in a loop
3.6M ETH stolen
The attacker repeated this pattern until they had drained approximately one-third of The DAO's funds
ℹ️The Fork
The Ethereum community voted to hard-fork the blockchain to reverse the hack, returning the stolen funds. Those who disagreed continued on the original chain — now Ethereum Classic. The DAO hack didn't just change smart contract development; it changed blockchain governance forever.
Why It's Still Happening
We covered reentrancy as one of the most common DeFi vulnerabilities — appearing in about 30% of our audits. As we noted in our smart contract audit checklist, checking for reentrancy is the first item on every auditor's list. So why does it persist?
Because it keeps evolving.
The Four Generations of Reentrancy
Generation 1: Classic Single-Function (2016-2018)
The DAO pattern. An external call in the middle of a state-changing function allows the callee to re-enter the same function before state is updated.
Classic Reentrancy
Vulnerable pattern
1. Check balance. 2. Send ETH (external call). 3. Update balance. The attacker re-enters at step 2, before step 3 executes.
The fix
Checks-Effects-Interactions pattern: 1. Check balance. 2. Update balance. 3. Send ETH. Now re-entering sees the updated (zero) balance.
Detection difficulty: Low. Slither and other static analysis tools catch this reliably.
Generation 2: Cross-Function (2018-2020)
The attacker re-enters a different function that shares state with the vulnerable one:
Call function A
function withdraw() sends ETH to the attacker
Attacker re-enters function B
The fallback calls transfer() instead of withdraw()
Shared state is inconsistent
transfer() reads the balance that withdraw() hasn't updated yet — allowing the attacker to move funds that should have been deducted
Detection difficulty: Medium. Requires analyzing state dependencies across multiple functions.
Generation 3: Cross-Contract (2020-2023)
Contract A calls Contract B, which calls back into Contract A through a different entry point:
Cross-Contract Reentrancy
The pattern
Protocol has Vault and Accounting contracts. Vault calls Accounting to update shares. Accounting triggers a callback (e.g., ERC-777 token hook). The callback re-enters Vault through a different function while Accounting state is partially updated.
Why it's hard to catch
Each contract individually follows checks-effects-interactions. The vulnerability only exists in the interaction between them. Single-contract analysis misses it entirely.
Detection difficulty: High. Requires whole-protocol analysis, not just single-contract review.
Generation 4: Read-Only Reentrancy (2023-Present)
criticalThe newest and most dangerous variant. The attacker re-enters a view function that returns stale state, causing other protocols that depend on it to make incorrect calculations.
Protocol A modifies state
A lending protocol begins a withdrawal, updating internal accounting but not yet finishing the transaction
Callback triggers during execution
An ERC-777 token hook, a Balancer flash loan callback, or a Curve reentrancy triggers mid-execution
Protocol B reads Protocol A's view function
Protocol B (e.g., a price oracle integration) calls a view function on Protocol A to get the current price or TVL
View function returns stale data
The view function reads storage that is only partially updated — returning an incorrect price or balance
Protocol B acts on wrong data
Protocol B makes a decision (lending, liquidation, swapping) based on the manipulated read-only value
🛑Read-Only Reentrancy Is Invisible to Traditional Analysis
Standard reentrancy guards don't protect against read-only reentrancy because no state is modified during the re-entry. The vulnerability is that a view function returns inconsistent data during execution — and other contracts act on it. This has been exploited in Curve, Balancer, and multiple protocols that integrate with them.
Detection difficulty: Very high. Requires understanding cross-protocol dependencies and the timing of state updates.
The Dollar Cost
$60M
The DAO (2016)
$25M
dForce (2020)
$11M
Cream (2021)
$7M
Curve Read-Only (2023)
Complete Defense Strategy
Partial Protection
- •Checks-effects-interactions in each function
- •ReentrancyGuard on individual functions
- •Single-contract static analysis
- •Trusting that view functions are safe
Complete Protection
- •Checks-effects-interactions across all functions sharing state
- •Protocol-level reentrancy locks (shared across all contracts)
- •Cross-contract and cross-protocol interaction analysis
- •Reentrancy guards on view functions used by external protocols
CEI Pattern
Apply checks-effects-interactions consistently across all state-changing functions
Protocol Lock
Use a shared reentrancy lock across all contracts in your protocol
View Protection
Add reentrancy checks to view functions that external protocols depend on
Integration Audit
Audit every external protocol integration for cross-contract reentrancy
How We Catch It
Our Smart Contract Auditor uses a multi-layer approach:
- Static analysis (Slither, custom rules) catches Generation 1 and most Generation 2 reentrancy
- Cross-contract flow analysis maps state dependencies between contracts to detect Generation 3 patterns
- Integration review identifies read-only reentrancy risks in every external protocol dependency
- Human expert verification — as we discussed in How RedVolt Combines AI with Human Expertise, the AI flags potential reentrancy paths while human auditors verify exploitability and economic impact
Is your protocol safe from all four generations of reentrancy? Our Smart Contract Auditor catches known patterns automatically, and our expert review tests for the cross-contract and read-only variants that automated tools miss.