Open the complete story and reading map
A shared program can execute consistently and still produce a result its users reject. That tension is the starting point for understanding The DAO in 2016. Here, The DAO means the particular Ethereum application involved in that event, not every organization now called a DAO.
Two dated records, two different stages
On June 17, 2016, the Ethereum Foundation reported an exploited recursive-calling vulnerability in The DAO. Its update discussed a proposed software response. A proposal made during an incident must not be reported as though it were already the final implemented outcome.
On July 20, 2016, the Foundation reported completion of a hard fork at block 1,920,000, with a specific state change transferring funds from affected contracts to a recovery contract. The announcement also addressed people following the non-fork chain. This is evidence of a contested response involving software adoption, not evidence that every participant agreed.
A simplified example of re-entering before the books are updated
Imagine a fictional withdrawal program that performs two operations in this order: first send the requested funds; then reduce the caller's recorded entitlement. If the receiving code can call back into the withdrawal function before that reduction, another request may see the old entitlement. This sketch illustrates a class of reentrancy problem; it is not a complete reconstruction of The DAO's code.
The general programming lesson is to examine the order of state updates and external calls, and the assumptions made when another contract runs. A familiar interface or a large balance does not establish that all execution paths are safe.
Three layers of governance
| Layer | Example decision | Who must be considered? |
|---|---|---|
| Application rules | Does this withdrawal call pass the deployed checks? | Contract code, callers and any authorized controllers. |
| Application administration | Can a pause or upgrade be invoked? | Key holders or voters with that specific permission. |
| Network rules | Will software accept a special state change? | Client implementers and the participants who choose what software and chain to use. |
Copying an application's source code and deploying a replacement does not automatically move funds out of the old contract. Likewise, a vote inside one application does not automatically command every node to change the blockchain's rules. Confusing these layers makes both decentralization claims and incident reports difficult to evaluate.
Why reasonable people can disagree about a recovery
Consider a hypothetical community choosing among leaving the state untouched, using existing administrative powers or coordinating a network-level change. Leaving the state untouched can preserve a strong expectation about rule continuity while leaving harmed participants without a technical recovery. Intervention can address a particular loss while creating questions about precedent, boundaries and whose losses qualify.
This is an editorial framework for comparing choices, not a claim that all choices were equally feasible in the 2016 incident. The historical documents establish what was reported and implemented; judgments about legitimacy require openly stated values. “Code executed it” and “people should accept it” answer different questions.
A governance worksheet for the next application
- List ordinary powers: who can move funds, change parameters or replace implementation code?
- List emergency powers: is there a pause, veto or delayed upgrade, and who can invoke it?
- Identify the affected group: token holders, users, liquidity providers and node operators may be different people.
- Read the exit conditions: can a user leave before a change takes effect, and does that depend on available liquidity?
- Separate evidence from assurance: a published process is evidence of a stated rule, not proof that every future dispute will be resolved fairly.
For a fictional lending club, “three of five administrators can pause withdrawals” is more informative than “community controlled.” It names the action, threshold and people whose availability matters. The same precision should guide your reading of a DAO proposal.
Check your reasoning: does a successful token-holder vote automatically change Ethereum's consensus rules?
No. A vote can exercise powers the application actually implements. A network-rule change requires a different adoption process. Identify the system in which the vote has authority before describing what it controls.
The next chapter follows tokens: how a common software interface made assets easier to integrate, and why a token balance alone cannot explain the rights or incentives attached to it.