The DAO reentrancy exploit — Ethereum — 2016-06-17

Summary

On 17 June 2016, an attacker exploited a reentrancy flaw in The DAO — a high-profile, ETH-denominated investment-vehicle smart contract that had raised approximately 12.7M ETH (~$150M at the time) in a public crowdsale weeks earlier. The vulnerability was in The DAO's splitDAO withdrawal path: the contract sent ETH to the recipient via an external call before zeroing the recipient's internal balance. The attacker's contract used the inbound external call to re-enter splitDAO against still-non-zero internal accounting, repeatedly, draining ~3.6M ETH into a "child DAO" controlled by the attacker over a sustained extraction window.

The Ethereum community responded with a contentious public debate over whether to perform a hard fork to revert the withdrawals. The fork executed at block 1,920,000 on 20 July 2016. A minority of validators rejected the fork on "code is law" grounds and continued the unforked chain as Ethereum Classic. The DAO incident is OAK's foundational T9.005 reference because it (a) is the historical origin of the reentrancy vulnerability class as a recognised category, (b) directly produced the now-standard checks-effects-interactions discipline and OpenZeppelin's ReentrancyGuard pattern, and (c) is the precipitating event for the modern smart-contract auditing industry.

Timeline (UTC)

When	Event	OAK ref
2016-04-30	The DAO smart contract deployed on Ethereum mainnet; crowdsale opens	T9.005 surface created
2016-05-28	Crowdsale closes having raised 12.7M ETH ($150M at then-prevailing prices)	(context)
2016-06-09	Independent researchers (Daian, others) publicly flag a "recursive call" vulnerability class affecting splitDAO-style withdrawal patterns; The DAO not yet patched	pre-event signal
2016-06-17	Attacker initiates exploit; recursive re-entry into splitDAO drains ~3.6M ETH into an attacker-controlled child DAO over the extraction window	T9.005 extraction
2016-06-17 (same day)	Vitalik Buterin and Ethereum Foundation publicly acknowledge the incident; community debate over response begins	(governance)
2016-06-17 to 2016-07-20	Attacker funds locked in 28-day child-DAO holding period (a structural delay native to The DAO, not a defender intervention); public debate over soft-fork vs hard-fork response	(governance window)
2016-07-20	Hard fork at block 1,920,000 reverts the attacker's withdrawals; refund contract distributes recovered ETH to original DAO token holders	resolution
2016-07-20 onward	Minority chain rejects the fork and persists as Ethereum Classic (ETC)	(precedent)

What defenders observed and learned

• The vulnerability was publicly flagged before extraction; the protocol did not patch in time. The recursive-call class had been described in writing days before the attack and splitDAO was specifically discussed in the pre-event window. The defender lesson is structural rather than detection-focused: in 2016 there was no industry-standard process for moving from "vulnerability publicly flagged" to "deployed protocol patched," and there was no equivalent of today's responsible-disclosure / emergency-pause toolkit. The DAO had no upgrade path and no pause function. This is the foundational case for why those tools exist now.
• Single-transaction call-trace shape was the unambiguous on-chain signal. The extraction transactions show the canonical T9.005 fingerprint — repeated re-entries into the same function selector on the same contract before the originating call returns. In 2016, no live monitoring infrastructure was watching for this pattern; today, this exact fingerprint is the baseline T9.005 detection signal in Forta, OpenZeppelin Defender, BlockSec PhalconHQ, and similar runtime-monitoring stacks.
• Modern smart-contract security practice begins here. The post-incident industry response produced (i) checks-effects-interactions as a stated coding discipline, (ii) the ReentrancyGuard pattern that OpenZeppelin later canonicalised, (iii) the pre-deployment static-analysis category that became Slither / MythX / Securify / Mythril, and (iv) the modern audit-firm market itself. Defenders today inherit a stack of mitigations that did not exist before this case.
• Governance response is part of the loss model. The hard fork reverted the attacker's withdrawals, but produced a permanent chain split (ETC) and a precedent that has been invoked in every subsequent debate over whether to fork in response to a major loss. No subsequent Ethereum incident has produced a similar fork — the precedent is, in practice, "we did this once and the cost was a chain split." Defenders should treat hard-fork reversal as a non-repeatable response option for incident-modelling purposes.

What this example tells contributors writing future Technique pages

• Use historical-anchor framing for foundational cases. Some Techniques have a "year-zero" incident that defines the class and shaped every mitigation that followed. T9.005 is the clearest example: every modern reentrancy mitigation traces directly to The DAO. Technique pages should name the historical anchor explicitly and explain what current practice inherits from it. This is not the same role as a recent canonical example (compare Cream Finance 2021 for T9.005's modern variant); both roles are useful and they are not interchangeable.
• The cost-of-catching-it asymmetry is the core argument for pre-deployment controls. The DAO's reentrancy bug would have been caught by any 2020-era static analyser in seconds. The cost of catching it in audit (low thousands of USD) versus the cost of not catching it in production (~$60M at the time, ~$5B+ at 2024 ETH prices, plus a permanent chain split) is the canonical illustration of why the smart-contract security industry is structured around pre-deployment controls. Technique pages whose mitigation surface is primarily pre-deployment (T9.005, T9.003, others) should reference this asymmetry rather than re-arguing it.
• Design-pattern legacy is a first-class outcome. ReentrancyGuard and checks-effects-interactions are not just mitigations for T9.005 — they are artefacts of T9.005, in the sense that the technique's history is the reason these patterns exist as named conventions. Technique pages should distinguish between (a) generic security hygiene that happens to apply, and (b) named patterns that exist because of a specific historical incident. The latter belongs in the Discussion section as part of the technique's lineage.
• Preserve the "at the time" qualifier on historical loss numbers. The DAO loss is ~$60M at the time of the event and ~$5B+ at 2024 ETH prices. Both numbers are correct; neither is correct without its qualifier. Future contributors writing examples that span large price-history windows (long-locked stolen funds, pre-2018 ETH-denominated incidents, BTC-denominated 2010s incidents) should preserve both numbers and label them.

Public references

• Daian, Phil. Analysis of the DAO Exploit. Hacking Distributed, 2016-06-18 — [daoreentrancy2016retrospective]. Canonical retrospective; the original publicly-cited technical breakdown of the reentrancy mechanism.
• Buterin, Vitalik. Hard Fork Completed. Ethereum Foundation Blog, 2016-07-20 — [ethfoundationdaohardfork2016]. The Ethereum Foundation's contemporaneous announcement of the hard fork at block 1,920,000.
• Atzei, N.; Bartoletti, M.; Cimoli, T. A Survey of Attacks on Ethereum Smart Contracts. POST 2017 — [atzei2017survey]. The first peer-reviewed taxonomy of Ethereum smart-contract attacks; canonical academic placement of The DAO as the exemplar reentrancy case.
• Zhou, L. et al. SoK: Decentralized Finance (DeFi) Attacks. IEEE S&P 2023 — [zhou2023sok]. Modern academic taxonomy; places reentrancy among the canonical smart-contract vulnerability classes and references the DAO lineage.

Discussion

The DAO is unusual among OAK worked examples because its primary historical significance is governance, not extraction mechanics. The reentrancy mechanism itself is, by 2026 standards, a well-understood and routinely-mitigated bug class — Slither's reentrancy-eth detector flags exactly this pattern, OpenZeppelin's ReentrancyGuard blocks it, and the checks-effects-interactions discipline is taught in any reasonable Solidity introduction. What remains historically singular about the case is the Ethereum / Ethereum Classic chain split.

The fork debate crystallised two positions that have recurred in every major smart-contract incident since: (a) "the deployed code defines the legitimate state of the system, regardless of intent" — the position that produced Ethereum Classic — versus (b) "the system has off-chain stakeholders whose interests can override the deployed code in extraordinary cases" — the position that produced the hard fork and the chain that retains the "Ethereum" name. OAK does not adjudicate this question; it is upstream of the framework. But contributors writing examples involving major losses should be aware that the "code is law" framing is itself a 2016-derived position with a specific history, and should not be deployed without acknowledging that history. The Mango Markets 2022 case (/Users/dmytro.chystiakov/Projects/oak/examples/2022-10-mango-markets.md) is the most recent high-profile invocation of "code is law" in a U.S. courtroom; the lineage runs directly back to The DAO.

Industry practice changed permanently after The DAO. The pattern of "deploy substantial value to an unaudited contract on the basis of public enthusiasm" — which produced The DAO crowdsale itself — became indefensible in any serious post-2017 context. Audit firms (Trail of Bits, OpenZeppelin Security, ConsenSys Diligence, later Halborn and the broader audit-firm market) emerged or scaled into the gap. The OWASP Smart Contract Top 10 — and OAK's T9 tactic itself — exist as downstream artefacts of the conditions The DAO exposed. From a defender's perspective, this is the case where the industry learned that smart-contract security is a discipline that needs to exist; everything T9.005 currently prescribes is the answer to a question this incident forced the ecosystem to ask.