Safeguard
Industry Analysis•

The DAO hack of 2016: what happened and what it taught developers

The 2016 DAO hack explained: a reentrancy bug in splitDAO, about 3.6 million ETH moved, the hard fork that followed, and the lessons for contract developers.

Safeguard Security Team
3 min read

The DAO hack was an attack on 17 June 2016 that exploited a reentrancy bug in a function called splitDAO. The attacker withdrew ether repeatedly before the contract updated its balances. The community responded with a hard fork, and the lessons still shape how smart contracts are written and reviewed.

What happened

The DAO was a crowdfunded investment contract on Ethereum that raised roughly 12 million ETH. On 17 June 2016 an unidentified attacker called splitDAO in a way that let the contract send ether out again and again before it recorded the withdrawal. According to a retrospective in The Block, about 3.6 million ETH, around a third of the fund, ended up in a "child DAO".

That child DAO had a 28 day withdrawal lock. The delay mattered, because it gave the community time to decide what to do.

How the community responded

A group of developers known as the White Hat Group used the same weakness to move the remaining vulnerable funds into contracts they controlled, so the attacker could not drain those too. Then came the harder question: leave the chain alone, or change it.

On 20 July 2016, at block 1,920,000, Ethereum hard forked to restore the affected funds. The Block reports that roughly 85 to 89 percent of voters supported it. Holders who stayed on the forked chain were made whole through a recovery contract. The original chain continued as Ethereum Classic.

The bug in plain words

The contract checked a balance, sent money to the caller, and only then reduced the balance. If the receiver is itself a contract, it can use that moment of control to call back in. The balance still looks untouched, so the check passes again.

The Solidity documentation describes the same pattern: any transfer of ether hands control to the receiving contract, which can call back into the original before the first call finishes.

What it taught developers

  • Update your own state before you call anyone else. This is the checks-effects-interactions order, covered in our guide to reentrancy defenses.
  • Treat every external call as a place where control leaves your code.
  • Code on a public chain is hard to patch and easy to read, so review before deployment matters more than review after.
  • Plan for emergencies. A withdrawal delay or a pause switch buys time that a fully open contract does not.

The Block also notes that the incident is widely credited with starting the smart contract security industry, and that the SEC's 2017 DAO Report concluded the DAO tokens were securities.

Quick check

Was The DAO hack a flaw in Ethereum itself?

No. It was a flaw in one application contract running on Ethereum. The fork was a social decision about how to respond, not a fix to the protocol.

Could the same bug happen today?

Reentrancy is still a known class of bug, and the Solidity documentation and the Ethereum security guide both warn about it. Modern tooling and patterns reduce the risk but do not remove it.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.