The DAO Hack (2016) and the Ethereum Fork That Followed
In June 2016 an attacker drained millions of ether from The DAO. Here is what the bug was, why Ethereum hard-forked in July, and why Ethereum Classic exists.
The DAO was meant to be a leaderless investment fund run by code. Instead it became the most debated incident in Ethereum's early history. A flaw in its smart contract allowed an attacker to withdraw millions of ether in June 2016, and the response, a hard fork of the network, split the community and created two separate chains.
What The DAO was
A decentralised autonomous organisation, or DAO, is a set of smart contracts that lets token holders vote on how funds are spent. The project known simply as The DAO was created by the team around Slock.it, a German start-up. Its token sale opened on 30 April 2016 and ran for 28 days. Participants sent ether in exchange for DAO tokens, which granted voting rights over proposals.
The sale raised about 12.7 million ether, which was worth roughly 150 million US dollars at the time. It was among the largest crowdfunding campaigns in history, and a notable share of all ether then in existence was held in the contract.
The vulnerability
Security researchers raised concerns about The DAO's code in the weeks after the sale. On 17 June 2016, an attacker began draining ether through the contract's split function, which let a token holder leave the DAO and withdraw their share of the funds.
The problem is known as a reentrancy bug. The contract sent ether to the requester before updating its internal record of that person's balance. An attacker's contract could receive the ether, then call the withdraw function again before the balance was reduced, repeating the process many times in a single transaction. The code did what it was written to do, but not what its authors intended.
About 3.6 million ether was moved into a so-called child DAO controlled by the attacker. A feature of the design meant the funds could not be moved out of that child DAO for 28 days, which gave the community a window to respond.
The debate
The community faced a hard choice, and the arguments on each side are worth stating fairly:
- Intervene. Supporters argued that the loss threatened the young network and thousands of investors, and that a coordinated fix was justified.
- Do not intervene. Opponents argued that the contract had executed as coded, that "code is law" was a core principle of the platform, and that reversing transactions would set a precedent for future bailouts.
The attacker's defenders pointed to the terms of use, which they argued permitted such behaviour. Most legal commentary at the time treated this as untested. This article does not take a position on those claims.
The fork
A first proposal, a soft fork that would block transactions from the attacker's account, was abandoned after researchers found it could be abused for denial-of-service attacks. The developers then proposed a hard fork, a change to the protocol that makes old software incompatible with the new chain.
At block 1,920,000, on 20 July 2016, the network switched to a version of the chain in which the funds in the child DAO were moved to a recovery contract. DAO token holders could then reclaim their ether at a fixed rate. Most users, exchanges and miners adopted the new chain.
Ethereum Classic
A minority refused to accept the change. They continued to run the original chain, in which the attack stood. This became Ethereum Classic, with the ticker ETC, while the forked chain kept the Ethereum name and the ticker ETH. Both have been running ever since, and they are separate networks with different developers and communities.
| Date | Event |
|---|---|
| 30 Apr 2016 | Token sale opens |
| 28 May 2016 | Sale closes with about 12.7 million ETH raised |
| 17 Jun 2016 | Attack begins; about 3.6 million ETH drained |
| 20 Jul 2016 | Hard fork at block 1,920,000 |
The flaw in code terms
In plain language, the contract behaved like a cashier who hands over money first and writes it in the ledger afterwards. If the person at the counter can ask for the same money again before the entry is made, the cashier pays twice, then three times. The safe order is to record the withdrawal first and send the funds afterwards. Developers also use guard code that blocks a function from being entered again while it is still running. These patterns are now taught in every smart contract course. For web developers, the equivalent habits include validating input and reviewing third-party code, as outlined on our security page.
Consequences
- Smart contract auditing grew. Specialist security firms and formal verification became more common.
- Coding patterns changed. The "checks-effects-interactions" pattern, which updates state before sending funds, became standard advice.
- Regulators noticed. In July 2017 the US Securities and Exchange Commission published a report on The DAO, concluding that its tokens were securities under US law. No enforcement action was taken in that case, but the report shaped later guidance for token sales.
A practical lesson for site owners
The DAO is a lesson about review. A flaw that is obvious in hindsight can survive when many people trust code they have not read. If you rely on plugins, themes or custom scripts, treat them the same way: update regularly, remove what you do not use, and test changes before they go live. The knowledge base is a good place to start.
