Module 6 · Ethereum & Shared Applications / 6.4
When the program and the promise disagree.
The DAO shows why software rules still lead to human choices.
Imagine a shared fund with a rule: members propose projects, vote, and release money through a program. No single manager is supposed to decide where the funds go.
In 2016, a real Ethereum project called The DAO tried a version of that idea. People contributed ETH for tokens associated with participation in the fund.
The program had a flaw. The crisis that followed was about both code and the meaning of a shared rulebook.
An unfinished withdrawal.
Picture a simplified withdrawal that performs two jobs in the wrong order. First it sends money. Only afterward does it record that the user’s balance has fallen.
The recipient can be another contract. When that contract receives control, it may ask for another withdrawal before the first request finishes. If the recorded balance still looks full, the second request can pass the same check.
Calling back into a contract while an earlier call is unfinished is reentrancy. Not every callback is a bug. The danger is letting the nested call use inconsistent or unprotected state.
The DAO exploit in June 2016 used a more detailed contract path than this picture. The essential lesson is the ordering problem: the program could repeat an action its designers meant to allow only under different conditions.
A deliberately simplified callback model. The real DAO used more complex contract paths.
What the small model leaves out
The affected DAO mechanisms involved splitting into child DAO structures, not an ordinary ATM. A waiting period limited immediate access to the diverted funds and gave the community time to debate responses.
Checks-effects-interactions is one defensive programming pattern. Reentrancy guards and careful cross-function design can also matter. None of these labels is a substitute for examining the actual contract.
Two principles collided.
One position was to preserve the existing execution history without a special recovery intervention. Supporters worried that an exception would make future outcomes depend on political influence.
Another position was to adopt an exceptional state change to recover affected funds. Supporters argued that the exploit was a grave failure of a young system and that a coordinated response was justified.
On July 20, 2016, the forked Ethereum rules moved affected funds to a recovery contract. Participants who continued the non-intervention branch formed the chain known as Ethereum Classic.
Both branches share the history before the split. “Original” does not settle which branch someone should value or use. Nor did one person remotely rewrite every node. Participants and services chose which rules and chain to follow.
Shared past, different adopted rules. Neither branch can force everyone to join it.
Execution is not the whole agreement.
The exploit is commonly called a hack even though it used callable program behavior. A program accepting an action does not make the action lawful, intended, or harmless.
The constitution analogy helps here. Software defines operational rules, while people decide whether to accept changes to those rules. A hard fork can create a disagreement that the old software cannot reconcile automatically.
This history does not prove that every later loss will be rescued. It also does not prove that Bitcoin never changes rules or has never faced a protocol incident. Those are separate historical questions.
For a user, the practical lesson is to distinguish three risks: the network’s rules, a particular application’s code, and the people who can alter or intervene in either. An audit is evidence of review, not a guarantee of recovery.
The idea to keep
Shared execution can enforce a flawed program. When people disagree about the result, the next question is governance: which rules will they choose to keep following?