Block 1,920,000: The DAO Rescue and the Chain That Became Ethereum Classic

1. A fund governed by code still had people at its gates

Between April 30 and May 28, 2016, The DAO sold tokens for roughly 12 million ETH, worth about $150 million when the offering closed. Slock.it and its co-founders helped build and promote the project. Investors were buying participation in a venture-funding experiment whose proposals and payments would be handled through smart contracts.^[1]

That promise did not remove human authority. Token holders voted, but curators decided which proposals could enter the whitelist and reach a vote. The SEC’s later investigation documented their discretion over the order and timing of proposals. The distinction matters: a fund can execute through code while people still decide what the code is permitted to fund.^[1]

Warnings also preceded the theft. The SEC report records a May security proposal and a June 3 proposal to halt new funding decisions while vulnerabilities were addressed. The attack did not arrive in a world where nobody had raised questions; it arrived before those concerns had been resolved.^[1]

2. One application’s split function became the point of failure

On June 17, an attacker diverted approximately 3.6 million ETH into an address under its control. The SEC described that amount as roughly one third of the ETH raised by The DAO.^[1]

Vitalik Buterin’s alert that day identified recursive calls to the split function: another split was invoked during the execution of the first, collecting ether repeatedly in one transaction. The failure was in The DAO’s application logic. It did not require breaking Ethereum’s cryptography or replacing its consensus rules.^[2]

The money had moved, but immediate external withdrawal was restricted by the child DAO’s creation window. The June 17 alert estimated at least another 27 days. That constraint gave responders time to act; it was not an exact four-week countdown ending with the eventual fork.^[1][2]

3. Freezing withdrawals introduced another security problem

The first response described in the June 17 alert was a proposed soft fork. It would reject transactions that reduced the balances of specified DAO contracts. The announcement expressly distinguished this prospective restriction from reversing earlier transactions or blocks.^[2]

On June 28, developer Felix Lange reported a denial-of-service vulnerability in the released soft-fork implementation. An attacker could make clients execute code without paying the expected gas cost, slowing mining and obstructing legitimate transactions. The alert advised avoiding activation while alternatives were considered.^[3]

The remedy therefore needed scrutiny of its own. Blocking the attacker’s exit and preserving normal network operation were separate requirements, and a mechanism aimed at satisfying the first could endanger the second. The proposed response moved from restricting withdrawals toward explicitly reallocating the affected balances.^[2][3][4]

4. A specific state change required participants to choose software

Jeffrey Wilcke’s July 15 announcement set out the hard-fork specification. At block 1,920,000, balances in an enumerated set of DAO and child-DAO accounts would move to WithdrawDAO. Holders could exchange 100 DAO tokens for 1 ETH through the recovery contract, with extra-balance cases handled separately.^[4]

The Foundation did not describe this as a decision it could make alone. Wilcke explained that community preferences would inform the default fork option in Geth; users still had to adopt compatible software and choose which state to follow. The disagreement concerned whether an exceptional rescue justified changing balances that the previous rules had produced.^[4]

On July 20, the Foundation reported that the state change had moved about 12 million ETH from Dark DAO and Whitehat DAO contracts into the recovery contract. It estimated that roughly 85% of miners were following the fork. The transferred amount included more than the attacker’s 3.6 million ETH: it concerned the listed DAO accounts, not only stolen funds.^[5]

EIP-779 later documented this event. Created in November 2017, it describes an irregular state change rather than a new transaction format or set of EVM instructions.^[7]

5. The fork succeeded without making the other chain disappear

Some participants continued without the rescue state change. By July 26, the Foundation explicitly described ETH as the fork chain and ETC as the community effort to continue the no-fork chain. Ethereum Classic’s origin lies in that continuation: the two networks shared their earlier blocks and then accepted different states.^[6]

This was also a wallet problem. People who held ether before the split had assets on both branches, and a signed transaction could be replayed across them. The Foundation recommended separating ETC into a new account and managing the assets in separate wallets. A disagreement about immutability had become a practical question of which network a signature would affect.^[6]

The episode connects application security to the limits of collective rescue. Ethereum participants could coordinate a recovery, but they could not make that choice unanimous. ETC preserved the alternative state, turning a rejected intervention into the origin of a separate network rather than erasing the shared history.^[5][6]