← Back to course
Supplementary Lecture · Blockchain History

L13: The DAO Fork

The $60 Million Bug That Split a Blockchain
In 2016, a single smart contract vulnerability triggered the most consequential governance crisis in blockchain history. This lecture traces the full story: from a radical experiment in decentralised venture capital, through a catastrophic hack, to the community vote that split Ethereum into two competing chains — and the lessons that still shape blockchain security and governance today.
Slides: 12 Charts: 4 Type: Supplementary Prerequisites: L05 Ethereum, L11 DAOs

The DAO hack of June 2016 is the most studied crisis in blockchain history. It was the moment the Ethereum community was forced to answer a question nobody had prepared for: when a smart contract executes exactly as written but produces a catastrophic outcome, who has the authority to reverse it?

This lecture follows the story across four acts. Act 1: The Dream — an ambitious experiment in decentralised governance that attracted $150 million in weeks. Act 2: The Crisis — a reentrancy attack that drained 3.6 million ETH in hours. Act 3: The Dilemma — a community torn between two irreconcilable philosophies. Act 4: The Legacy — a chain split that produced two living blockchains and transformed smart contract security forever.

Why this matters: Every concept covered in this course — hashing, consensus, smart contracts, governance, immutability — intersected in the DAO crisis. Understanding it is the capstone of the technical curriculum.

Ethereum is 10 months old. A team from Slock.it, led by Christoph Jentzsch, launches “The DAO” — a smart contract acting as a decentralised autonomous organisation modelled as a venture capital fund with no CEO, no board, and no headquarters. Just code and token holders voting on how to deploy funds.

The Analogy: Imagine Kickstarter, but the backers control the money — forever. No refunds, no management team, no override button. The smart contract is the CEO.

Three properties made The DAO unprecedented:

Decentralised governance: Any holder of DAO tokens could propose and vote on how funds were deployed. No proxy representation, no board veto — pure token-weighted democracy.
Smart contract treasury: Funds were held in an Ethereum smart contract. No bank, no escrow agent, no trustee. The code held the money and executed disbursements automatically on a passed vote.
Immutability: Once deployed, the code could not be modified. This was presented as a feature — no single party could alter the rules. It would become the fatal constraint.
No audit completed: The contract was deployed before a full independent security audit was finished. Speed of deployment was prioritised over security verification.

The underlying thesis: replace institutional trust (lawyers, boards, regulators) with mathematical trust (cryptography, consensus, immutable code). It was the boldest test of the Ethereum vision to date.

The largest crowdfund in history (at that time). In 28 days, The DAO raised the equivalent of $150 million in ETH from approximately 11,000 individual investors worldwide — no intermediary, no underwriter, no minimum investment threshold.

MetricValue
Duration28 days
Total raised~$150 million
ETH locked3.6M ETH (14% of all ETH)
Investors~11,000
Token rate1 ETH = 100 DAO tokens
Legal entityNone
Terms of serviceNone
The risk nobody emphasised: With no legal entity and no insurance, investors had no recourse if something went wrong. The smart contract was the only protection.
DAO Fundraising Timeline
Fig 13.1 — The DAO crowdsale: cumulative USD raised over 28 days, reaching $150 million

The DAO’s governance model had four stages: Propose → Debate → Vote → Execute. Any token holder could propose allocating funds to a project. The community debated it. Token holders voted (weighted by holdings). If the proposal passed, the smart contract disbursed the ETH automatically — no human intermediary required.

But there was a fifth function that would prove critical: splitDAO() — the exit door. If a token holder disagreed with the majority, they could call this function to leave The DAO and take their proportional share of ETH into a new “child DAO”.

The design intent: The split function was a minority investor protection mechanism. If your proposal lost the vote and you disagreed with the direction, you could exit with your ETH rather than being locked into investments you opposed. It was meant to be a safety valve. It became the attack vector.

The child DAO mechanism had one critical property: once you initiated a split and created a child DAO, there was a 28-day waiting period before the ETH could be withdrawn. This was a theft-prevention delay. It was also the feature that gave the community time to respond to the attack.

Governance FunctionRoleRisk
propose()Submit a funding requestLow
vote()Cast weighted vote on a proposalLow (voter apathy)
executeProposal()Disburse ETH to approved projectMedium (requires correct logic)
splitDAO()Exit and create child DAOCRITICAL — reentrancy vulnerability

Security researcher Peter Vessenes publicly disclosed a reentrancy vulnerability in the splitDAO() function on June 9, 2016. The community read the report. The core developers acknowledged the concern. But the contract was already deployed on Ethereum.

The immutability trap: Smart contracts are immutable once deployed. Unlike a web application where you push a patch, there is no mechanism to update live Ethereum code. $150 million sat in a contract with a known flaw, and nobody had the keys to fix it.

Proposals were floated: could the community coordinate a “white hat” drain of the contract funds to a safe address before an attacker could exploit the bug? Could a soft fork freeze the vulnerable functions? Each plan required broad community coordination that could not be achieved in time.

What was known (June 9): The reentrancy bug existed in splitDAO(). An attacker calling the function in a loop could drain ETH before the balance updated. The exploit path was publicly described.
What couldn’t be done: The contract could not be patched. A hard fork to disable the vulnerable function would require months of social consensus. A soft fork might work but had not been designed or tested.

Eight days passed. The warning was acknowledged. Nothing was fixed. On June 17, the attacker acted.

The reentrancy attack exploited a race condition between the ETH transfer and the balance update in splitDAO(). The mechanism is often explained as the ATM analogy:

The ATM analogy: Imagine pressing “withdraw $100” at an ATM, but before your balance updates, you press it again — and again, and again. Each press succeeds because the balance hasn’t been decremented yet. The attacker called splitDAO() in a loop, draining ETH each iteration.

The technical root cause: the contract sent ETH before updating the sender’s internal balance record. The attacker’s malicious contract intercepted the ETH transfer via a fallback function, immediately re-called splitDAO(), and repeated the cycle dozens of times.

The 28-day lifeline: The child DAO that received the stolen ETH was subject to the same 28-day waiting period as any split. The attacker held 3.6 million ETH but could not move it for 28 days. The community had a window to respond.
Reentrancy Attack Flow
Fig 13.2 — The reentrancy attack: how splitDAO() was exploited to drain 3.6 million ETH
Attack DetailValue
DateJune 17, 2016
ETH drained3.6 million ETH (~$60 million at the time)
Percentage of DAO funds~30% of total holdings
Lock period remaining28 days
FixChecks-Effects-Interactions pattern (always update state before sending)

The community response compressed weeks of deliberation into days. ETH price dropped 33% within hours of the attack being discovered. Exchanges halted DAO token trading.

  • June 17Attack discovered. Ethereum community enters crisis mode. ETH drops from ~$20 to ~$13.
  • June 18Vitalik Buterin proposes a soft fork: modify the Ethereum protocol to freeze any transactions moving the stolen ETH. Miners would implement by updating software.
  • June 21The attacker publishes an open letter arguing the funds were legally obtained under the DAO’s own rules: “I followed the code’s rules. This is not theft.”
  • June 24Security researchers discover the soft fork proposal itself has a Denial-of-Service vulnerability — it could be used to spam the network with free transactions. The soft fork is abandoned.
  • June 28The only remaining option: a hard fork that manually moves the stolen ETH to a refund contract, reversing the attack at the protocol level.
  • July 15Community vote closes. Hard fork proceeds to implementation.
  • July 20Hard fork executes at block 1,920,000. Ethereum splits.
The pressure: If no action was taken before the 28-day child DAO lock expired, the attacker’s funds would become permanently theirs. The clock was not abstract — it had a precise expiry block.

The hard fork debate exposed a philosophical fault line that had always existed in blockchain culture but had never been tested at scale. The question was not technical. It was political: who has ultimate authority over a blockchain?

Against the Fork: “Code Is Law”

The contract executed exactly as written. No rule was broken — only a design flaw exploited within the defined rules. Reversing the transaction destroys Ethereum’s core guarantee: immutability. If developers can undo transactions once, they can undo them again whenever powerful people lose money. The fork sets a precedent that Ethereum’s ledger is not censorship-resistant — it is subject to developer veto. Ethereum Classic maintains that this principle, once broken, cannot be restored.

For the Fork: “Intent Matters”

The attacker exploited a bug, not a feature. The difference between intent and outcome matters morally, even if the code made no such distinction. A nascent ecosystem cannot survive a $60M theft in its first year — it would destroy the credibility of Ethereum as a platform for serious applications. Ethereum is a social contract, not just software. Communities have always exercised governance over shared infrastructure. The code’s immutability is a technical property, not a moral command.

Neither side was wrong. Both were asking legitimately different questions. The “code is law” camp prioritised systemic trust over individual outcomes. The “intent matters” camp prioritised ecosystem viability over philosophical purity. The debate reflects the deeper tension between algorithmic governance and human governance that every blockchain community eventually confronts.

The Ethereum Foundation organised the Carbon Vote, an on-chain governance experiment where ETH holders could signal their preference by sending a transaction. The results were decisive — but raised immediate questions about legitimacy.

Vote OutcomeResult
For the hard fork87% of voting ETH
Against the fork13% of voting ETH
Voter turnout~5.5% of all ETH
Large holder biasYes — whale-weighted
The governance problem: Democracy requires participation. The vote was technically valid — 87% of voting ETH chose the fork. But only 5.5% of ETH holders voted. Does a 5% turnout on-chain vote constitute a legitimate mandate for the most consequential decision in Ethereum’s history?

The Carbon Vote is often cited as evidence both for and against on-chain governance. It showed that coordination was possible at speed. It also showed that plutocratic weighting and low participation are structural risks in token-weighted voting.

Community Vote Results
Fig 13.3 — Carbon Vote results: 87% support for the hard fork, but only 5.5% turnout

On July 20, 2016, at block 1,920,000, the Ethereum Foundation deployed an irregular state transition — a one-time, manually authored change to the blockchain state outside of the normal transaction rules. The stolen ETH was moved to a refund contract. Investors could retrieve their ETH.

But not all miners ran the new software. A minority of miners continued to build on the original, unforked chain — the one where the attacker’s funds remained intact. The two chains shared identical history up to block 1,919,999. From block 1,920,000 onwards, they diverged permanently.

The market spontaneously assigned names and ticker symbols. The forked chain — with the refund — became Ethereum (ETH). The original chain — where the attacker’s funds remained — became Ethereum Classic (ETC).

Technical note: An irregular state transition is distinct from a normal fork. It is not a rule change (like a gas limit adjustment) but a direct manual edit to the state database. It has happened exactly once in Ethereum’s history — and the Ethereum community has committed it will never happen again.
PropertyEthereum (ETH)Ethereum Classic (ETC)
Fork appliedYes — funds refundedNo — original state
PhilosophyIntent matters; community governsCode is law; immutability absolute
Development teamEthereum FoundationSeparate community
Market outcomeDominant; grew to #2 by capSurvived; 51%-attacked in 2020

The market rendered its verdict with price. ETH recovered, grew, and became the foundation of DeFi, NFTs, and the smart contract economy. ETC survived but never achieved comparable adoption, and its smaller hashrate left it vulnerable to 51% attacks.

The constructive legacy: The DAO hack created the modern smart contract security industry. It produced the Checks-Effects-Interactions pattern, formal verification tooling, the OpenZeppelin secure contract library, and a professional audit ecosystem that now charges $200K–$1M per engagement. Every Solidity developer learns reentrancy defence as day-one curriculum.
ETC’s security lesson: Ethereum Classic suffered three 51% attacks in 2020, with attackers reorganising hundreds of blocks and double-spending millions of dollars. Smaller PoW chains inherit the security assumptions of PoW (hash rate = security) without the hash rate. The fork that preserved immutability ultimately demonstrated that minority PoW chains face an existential security problem.
ETH vs ETC Price Divergence
Fig 13.4 — ETH vs ETC price divergence post-fork: markets voted decisively for the forked chain

The DAO crisis produced five lessons that have shaped blockchain development and governance ever since. Each directly contradicted assumptions that the 2016 community held.

  • Smart contracts are immutable — test before you deploy. There is no patch, no hotfix, no support ticket once code is live on a public blockchain. The cost of a bug in production is borne entirely by users. Comprehensive testing, fuzzing, and formal verification are not optional extras — they are the minimum viable security posture for any contract holding significant value.
  • “Code is law” has limits. Communities will intervene when the stakes are high enough. The DAO fork proved that no amount of philosophical commitment to immutability will survive a $60 million crisis with a 28-day window. Every blockchain is ultimately a social consensus machine. The code is the mechanism; the community is the authority.
  • Governance is the hardest problem. Technical consensus (miners, nodes running the same software) is achievable by protocol design. Social consensus (developers, users, investors, exchanges, regulators) is not. The DAO fork required both simultaneously — and nearly failed at the social layer despite broad technical agreement.
  • Security audits are not a checkbox. The DAO was audited. But the audit was incomplete and rushed. A thorough security audit is a process, not a timestamp. It requires time, adversarial thinking, and the willingness to delay deployment when findings are unresolved.
  • Forks are the ultimate governance mechanism. When a community cannot reach consensus, it splits. Both outcomes can coexist. Markets and developers determine which vision survives. This is not a bug in decentralised systems — it is a feature. Dissenting minorities can exit with their assets rather than being permanently outvoted.
The synthesis: The DAO fork proved that blockchains are not just technology — they are social systems that happen to run on code. The technical guarantees (immutability, censorship-resistance) are constrained by the social processes (governance, coordination, consensus) that surround them.
DAODecentralised Autonomous Organisation: an entity governed by smart contract rules rather than traditional management
Smart contractSelf-executing code deployed on a blockchain; immutable after deployment
Token holderEntity holding DAO tokens, entitling them to vote on proposals proportional to their holdings
Decentralised governanceDecision-making distributed across token holders rather than centralised authority
ImmutabilityProperty of deployed smart contracts: code cannot be modified after deployment
ProposalA request submitted to the DAO for funding consideration by token holders
VotingToken-weighted mechanism for approving or rejecting proposals
Child DAOA new DAO contract created when a token holder calls splitDAO() to exit with their proportional share
Split functionsplitDAO(): the exit mechanism that allowed investors to leave with their ETH; the attack vector
Reentrancy attackExploit where a malicious contract re-enters the calling function before state is updated, draining funds
Fallback functionDefault Solidity function called when ETH is received; used by attacker to re-enter splitDAO()
Checks-Effects-InteractionsSecurity pattern: validate inputs, update state, then interact with external contracts — in that order
Security auditFormal review of smart contract code by independent security researchers to identify vulnerabilities
Soft forkA backwards-compatible protocol upgrade; only nodes running new software enforce new rules
Hard forkA non-backwards-compatible protocol upgrade; creates a permanent chain split if not universally adopted
Code is lawPhilosophy: smart contract code defines the rules; all outcomes, even unintended ones, must be respected
Censorship resistanceProperty of blockchains: transactions cannot be blocked or reversed by any central authority
Carbon VoteOn-chain governance mechanism used to gauge community preference on the DAO fork decision
Voter apathyLow participation in governance votes; Carbon Vote had ~5.5% ETH holder participation
On-chain votingGovernance votes executed directly on the blockchain, typically weighted by token holdings
Irregular state transitionA one-time manual edit to blockchain state; used in the DAO fork to redirect stolen ETH
Chain splitPermanent divergence of a blockchain into two distinct chains with different transaction histories
Hard forkProtocol change requiring all nodes to upgrade; creates two chains if adoption is not universal
Ethereum (ETH)The forked chain that applied the DAO fix; became the dominant Ethereum network
Ethereum Classic (ETC)The original, unforked chain; preserves the pre-fork history including the attacker’s funds
51% attackAn attacker controlling >50% of a PoW network’s hash rate can reorganise blocks and double-spend
Formal verificationMathematical proof that smart contract code satisfies a specification; used to prevent reentrancy and other bugs
OpenZeppelinOpen-source library of secure, audited smart contract components; emerged after the DAO hack
CrowdfundRaising capital from a large number of small contributors; The DAO raised $150M this way
Token economicsDesign of incentive structures around token creation, distribution, and use
Decentralised venture capitalThe DAO’s stated model: community-governed investment decisions replacing traditional VC structures
Social consensusAgreement among humans (developers, users, miners, exchanges) about protocol direction; distinct from technical consensus
DoS vulnerabilityDenial-of-Service flaw; found in the proposed soft fork that would have allowed free spam transactions
PlutocracyGovernance weighted by wealth; token-weighted voting amplifies the influence of large holders
© Joerg Osterrieder 2025 · BSc Blockchain Course · Supplementary Lecture