Skip to main content

This site is for educational purposes only. Nothing here constitutes financial advice.

Back to all case studies
Smart Contract Exploit
2016-06-17~3.6M ETH (~$60M at the time; over $10B at 2024 prices)

The DAO Hack

June 2016 — reentrancy exploit drains $60M from The DAO and triggers Ethereum's contentious hard fork that created ETH and ETC.

The DAO ('Decentralised Autonomous Organisation') was a venture-capital-fund-like smart contract on Ethereum that raised approximately $150 million in ETH from over 11,000 contributors in mid-2016. It was, at the time, the largest crowdfunding event in history and represented Ethereum's most prominent early application beyond simple token transfers.

On June 17, 2016, an attacker exploited a reentrancy vulnerability in The DAO's withdrawal function to drain approximately 3.6 million ETH (worth around $60 million at the time) into a 'Child DAO' that the attacker controlled. The exploit took advantage of The DAO's 28-day delay before withdrawn ETH could be moved, which gave the Ethereum community a narrow window to respond.

The community's response — a contentious hard fork that effectively reversed the exploit by returning the stolen ETH to a recovery contract — split the Ethereum network into Ethereum (ETH) and Ethereum Classic (ETC). The DAO hack thus indirectly created one of the larger forks in crypto history and established the precedent (or counter-precedent, depending on perspective) for community-driven state rollback after a smart-contract failure.

Timeline

  1. 2016-04-30
    The DAO smart contract deployed on Ethereum; crowdsale begins.
  2. 2016-05-28
    Crowdsale closes after raising 12.7 million ETH (~$150M).
  3. 2016-06-05
    Vulnerability disclosed publicly by researcher Peter Vessenes. Patch in progress.
  4. 2016-06-12
    Stephan Tual (Slock.it CCO) writes that 'no DAO funds at risk.'
  5. 2016-06-17
    Attacker begins exploit. Approximately 3.6M ETH drained into a Child DAO over several hours.
  6. 2016-06-18
    Ethereum Foundation acknowledges the exploit. Vitalik Buterin proposes potential hard fork.
  7. 2016-07-20
    Hard fork executed at block 1,920,000. Stolen ETH returned to a recovery contract; original holders refunded.
  8. 2016-07-25
    Some miners and users refuse to support the fork, creating Ethereum Classic (ETC) on the original chain.
  9. 2016-08
    Both chains stabilise. ETH (forked) becomes dominant; ETC (original) maintains smaller community.
  10. 2022-02
    Brantly Millegan and Laura Shin's Unchained podcast names Toby Hoenisch (a TenX co-founder) as the likely attacker. Hoenisch denies it.

Mechanism

The reentrancy vulnerability. The DAO's `splitDAO` function allowed a token holder to withdraw their share of the DAO's ETH into a Child DAO. The function sent ETH to the holder *before* updating internal state (the holder's DAO token balance). This violated the 'checks-effects-interactions' pattern that has since become standard. The withdrawal function was vulnerable to a recursive call: while the external ETH transfer was executing, the recipient (a contract under the attacker's control) could call splitDAO again, before the first call had decremented its balance.

The exploit pattern. The attacker deployed a contract whose `receive()` function called The DAO's `splitDAO` again before the original call had updated state. The DAO would send another batch of ETH. The recursive call would repeat. The attacker could drain ETH equivalent to many times their actual DAO token balance per single transaction. The first such drain (and several follow-on transactions) extracted approximately 3.6 million ETH from The DAO.

The 28-day delay (which saved Ethereum). The DAO's design included a 28-day delay between requesting a Child DAO split and the withdrawn ETH being movable. This was a security feature for normal use. For the exploit, it meant the stolen ETH was visible but immovable, giving the community a window to react. Without this delay, the ETH would have been cashed out before any response was possible.

The hard fork decision. Faced with a stolen-but-recoverable 14% of all ETH in existence, the Ethereum community debated for roughly a month. Two camps emerged. Pro-fork: the ecosystem was new, The DAO held a substantial fraction of total ETH, and recovering the funds via fork was the pragmatic choice. Anti-fork: smart contracts are 'code is law,' the attacker had exploited a bug but operated within the contract's actual behaviour, and rolling back state set a precedent that undermined Ethereum's value proposition.

The fork execution. At Ethereum block 1,920,000, the hard fork rewrote state to move the stolen ETH (and other DAO holdings) into a 'WithdrawDAO' recovery contract from which original DAO contributors could withdraw their pro-rata share at 1 ETH per 100 DAO tokens. Most miners and users followed the fork; a minority continued running the original chain, which became Ethereum Classic. The two chains have remained separate ever since.

Impact

The DAO hack established several enduring patterns. Technically, it made reentrancy the canonical smart-contract vulnerability and established checks-effects-interactions as a standard defensive pattern. Socially, it established that Ethereum's community would intervene to reverse catastrophic smart-contract failures via hard fork when the stakes were large enough — a precedent that has been used both as a feature (Ethereum is 'governed') and a criticism (Ethereum is 'mutable when convenient'). Legally, it established a 28-day window as the practical minimum for any large smart-contract value transfer where community response is desired. Economically, the creation of ETC from the fork demonstrated that contentious crypto forks could produce persistent dual chains rather than one absorbing the other.

Operational lessons

  1. 1Checks-effects-interactions is not optional. Every smart-contract author since The DAO has been expected to know and follow the pattern: validate inputs, update state, then perform external interactions. The pattern eliminates the class of reentrancy bugs that drained The DAO. It's now in every Solidity audit checklist.
  2. 2Time delays as security feature. The DAO's 28-day delay before withdrawn ETH was movable was the only reason recovery was possible. Modern protocols holding large values commonly include similar delays (admin function timelocks, multisig delays, withdrawal queues) precisely because the delay creates response time for catastrophic failures.
  3. 3'Code is law' has limits at scale. The Ethereum community's decision to fork demonstrated that when the consequences are large enough and the exploit is clear enough, the human governance layer will intervene. Whether this is good or bad is a matter of philosophy; that it occurs is a matter of historical record.
  4. 4Audits are necessary but not sufficient. The DAO had been audited. The vulnerability was disclosed publicly weeks before the exploit, with patches in progress. The exploit succeeded anyway because the patches hadn't been deployed yet. Audit-and-then-deploy timelines matter; protocols holding meaningful value should not be in production with known-vulnerable code awaiting patches.
  5. 5Even successful recoveries create lasting consequences. The hard fork recovered The DAO's ETH but created Ethereum Classic, split the developer community, and established the precedent for governance-driven state reversal. Whether that precedent is net-positive remains debated.

Aftermath

The DAO itself was wound down via the WithdrawDAO contract; contributors withdrew their pro-rata shares of returned ETH. Slock.it (the company that created The DAO) continued operating for several years on other projects but did not produce another large DAO. Ethereum Classic has continued to exist as a smaller-cap chain (ETC market cap remains a small fraction of ETH's) with its own community and roadmap. The reentrancy pattern recurred in subsequent exploits (Cream Finance 2021, multiple others), but always against protocols whose authors had not internalised the post-DAO lessons. The DAO hack remains the standard reference point in every smart-contract security curriculum.

Sources & further reading

We prioritise primary sources. Where a topic moves quickly (regulation, security incidents), we re-check sources on the cadence shown by the page's "Next review" date.

Related on Block Clarity Hub

DeFi Safety L4 — Exploit catalogue (reentrancy)
Glossary — Reentrancy
DeFi Safety Course
Spotted an error? Report it on GitHub — our correction policy