The DAO fork was a governance decision in code

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.

The decision was concrete

After The DAO crisis, Ethereum participants considered changing the chain's state to make affected ether withdrawable under a specified arrangement. The Ethereum Foundation's 15 July 2016 proposal set out the intended transfer and a choice about the default fork setting in a client. Its own language presented the decision as contested and time sensitive. The 20 July announcement records completion, rather than a hypothetical future intervention.

What the fork did

EIP-779, written later as a meta record, describes an irregular state change at mainnet block 1,920,000. Specified DAO-related balances were moved to a withdrawal contract. The document says the fork did not rewrite the normal transaction format or the EVM instruction set. That is a sharper description than 'Ethereum reversed transactions': the intervention changed a particular set of balances under new consensus rules adopted by those running the fork.

The chronology matters. The EIP is a retrospective specification created in 2017 for a 2016 event. Its creation date is not the date of the fork. A reader who sees a later document should ask whether it describes a proposed change, an implemented change, or a later interpretation. Here the 2016 posts and the later EIP answer different parts of that question.

What governance meant in practice

Code was necessary but insufficient. Client maintainers supplied implementation choices; operators and users had to choose what software and chain to follow. The existence of a proposed default did not turn a community decision into a mechanical vote binding every participant. It is more accurate to say that the intervention made a contested policy choice executable and that adoption determined which history each participant treated as canonical.

There was a real tradeoff. Leaving the original state untouched protected a strong expectation about application outcomes; intervening prioritized a remedy for a specific failure. Neither position disappears because one chain gained more support. The episode remains relevant whenever a system promises both rapid emergency repair and absolute resistance to human intervention. Those promises can conflict under pressure.

Questions the episode leaves

• Who can propose an exceptional state change, and who can refuse it?
• Is a rescue rule general, or written for named accounts after a loss?
• How will users know which version of history their service recognizes?

The DAO fork does not establish that every Ethereum application can be rescued. It demonstrates a particular capacity for coordinated change under exceptional circumstances, with governance and legitimacy questions attached.