The DAO exploit sent ether before updating a balance

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

A recursive call before the balance updated

On 17 June 2016, an attacker began draining ether from The DAO, a token-funded venture pool built on Ethereum. The Securities and Exchange Commission's later report of investigation records that the attack moved approximately 3.6 million ETH, about a third of the roughly 12 million ETH the offering had raised, into an address the attacker controlled. The Ethereum Foundation's same-day critical update describes the mechanism directly: 'An attacker called the split function, and then calls the split function recursively inside of the split, thereby collecting ether many times over in a single transaction.'

Why the order of operations mattered

The vulnerability is a textbook case of what Solidity's own security documentation calls a reentrancy flaw, described there, as retrieved on 16 September 2026, as arising whenever a contract hands control to another contract mid-function, before finishing its own state changes. The DAO's split function sent ether out before it had fully recorded that the corresponding balance was spent, so a receiving contract could call split again, and again, within the same transaction, each time before the first call's bookkeeping caught up. The documented fix is the checks-effects-interactions pattern: validate conditions, update the contract's own state, and only then make an external call or transfer. The DAO's code performed the interaction before the effect, the exact inversion that pattern exists to prevent.

A contained loss and a contested response

The stolen ether was not immediately spendable. The Foundation's update noted that the attacker was prevented by The DAO's code from moving the ETH for a further 27 days, the child DAO's creation window, and it explicitly ruled out a rollback while proposing a soft fork instead. The eventual response, a hard fork restoring the funds, split the network: a minority continued on the original chain, later known as Ethereum Classic, because reversing the outcome ran counter to their view of what a blockchain is for, as the fork-mechanics post and the community vote it describes make clear. Whether the fork was the right governance choice is a separate judgment; the reentrancy bug itself is not in dispute.

• Does a contract send funds before or after it updates the balance that authorised the send?
• If a contract holds a large pooled balance, what independent review has checked its ordering of state changes against external calls?
• When a network's response to theft is a fork, who decided, and who is bound by a chain they did not choose to run?

The DAO's exploit did not require breaking cryptography or forging a signature. It required only that a withdrawal function trust its own future execution before confirming its past one. That failure mode still applies to any contract written today, on any chain, wherever an external call happens before the ledger entry it depends on.