Case Study 1: The DAO Hack — 3.6 Million ETH, a Hard Fork, and the Birth of Ethereum Classic

Case Study 1: The DAO Hack — 3.6 Million ETH, a Hard Fork, and the Birth of Ethereum Classic

Background

In the spring of 2016, Ethereum was barely a year old. The network had launched on July 30, 2015, and by early 2016, the developer community was exploring what a programmable blockchain could do beyond simple value transfer. The most ambitious experiment was "The DAO" — a Decentralized Autonomous Organization that would function as a venture capital fund governed entirely by smart contract code, with no board of directors, no management team, and no corporate structure.

The concept was radical: investors would send ETH to the DAO contract and receive DAO tokens in proportion to their investment. Token holders could then vote on proposals to fund projects. If a majority approved a proposal, the DAO would automatically transfer funds to the project. If an investor disagreed with the majority, they could "split" from the DAO — withdrawing their proportional share of funds into a personal "child DAO."

The DAO was created by a German company called Slock.it, led by Christoph Jentzsch. It launched its token sale on April 30, 2016, and within 28 days, it had raised 12.7 million ETH from over 11,000 unique addresses. At the time, ETH was trading at approximately $12, making the total raise about $150 million. The DAO held roughly 14% of all ETH in circulation. It was the largest crowdfunding event in history, surpassing every Kickstarter and Indiegogo campaign combined.

The excitement was palpable. The DAO was proof that decentralized governance could work at scale. Ethereum was not just a cryptocurrency — it was the platform for a new form of human organization.

Then the code broke.

The Vulnerability

The DAO's smart contract included a function called splitDAO() that allowed token holders to exit the DAO by withdrawing their proportional share of ETH into a new child DAO. The function was complex — it needed to calculate the user's share, create or reference a child DAO, transfer the funds, and update the user's token balance.

The critical flaw was in the order of operations. The function sent ETH to the user before updating the user's token balance to zero. In pseudocode, the vulnerable logic was:

function splitDAO():
    1. Calculate user's proportional share of ETH
    2. Send ETH to the user's designated recipient address    <-- EXTERNAL CALL
    3. Zero out the user's DAO token balance                   <-- STATE UPDATE

This violated what we now call the checks-effects-interactions pattern. The external call in step 2 could trigger code execution at the recipient address. If the recipient was a malicious contract, that contract could call splitDAO() again before step 3 executed. Since the user's balance had not yet been zeroed, the DAO would calculate the same proportional share again and send another payout. This recursion could continue until the DAO was drained or the gas ran out.

The actual vulnerable code in the DAO contract (simplified from the original Solidity):

function splitDAO(uint _proposalID, address _newCurator) returns (bool _success) {
    // ... proposal validation ...

    uint fundsToBeMoved = (balances[msg.sender] * p.splitData[0].totalSupply) /
                          p.splitData[0].totalSupply;

    // Transfer funds to the new child DAO
    // THIS IS THE VULNERABLE EXTERNAL CALL
    if (!p.splitData[0].newDAO.createTokenProxy.value(fundsToBeMoved)(msg.sender)) {
        throw;
    }

    // Update balance AFTER the external call — TOO LATE
    Transfer(msg.sender, 0, balances[msg.sender]);
    withdrawRewardFor(msg.sender);
    totalSupply -= balances[msg.sender];
    balances[msg.sender] = 0;
    paidOut[msg.sender] = 0;
    return true;
}

The key line is the createTokenProxy.value(fundsToBeMoved) call. This sends ETH to the child DAO contract while the caller's balance is still intact. If the child DAO's creation triggers a callback into splitDAO(), the process repeats.

The Warnings

The vulnerability was not unknown before the attack. On June 9, 2016 — eight days before the exploit — security researcher Peter Vessenes published a blog post titled "More Ethereum Attacks: Race-To-Empty is the Real Deal" that described the exact reentrancy pattern that would be used. On June 12, Ethereum developer Christian Reitwiessner published an analysis of the DAO's code identifying several vulnerabilities, including the reentrancy issue.

The DAO's developers acknowledged these concerns and were working on a fix. But the fix required a proposal to be submitted to the DAO, voted on by token holders, and executed — a process that took weeks. The DAO's own governance mechanism was too slow to patch its own code.

This is the cruel irony of immutable smart contracts: the code cannot be patched, and governance processes designed for considered decision-making are too slow for security response.

The Attack

On June 17, 2016, at approximately 3:34 AM UTC, an attacker began exploiting the reentrancy vulnerability. The attack contract called splitDAO(), and when the DAO sent ETH to the child DAO, the attacker's contract recursively called splitDAO() again. Each recursive call drained an additional share of ETH.

The attacker was methodical. They did not attempt to drain the entire DAO in a single transaction (which would have exceeded the gas limit). Instead, they executed the attack repeatedly across multiple transactions, draining ETH in batches. Over the course of several hours, 3.6 million ETH flowed from the DAO into the attacker's child DAO.

The Ethereum community watched in real time. Block explorers showed the attacker's transactions as they confirmed. Social media erupted. The price of ETH crashed from $20 to $13 within hours as the market processed the implications.

But there was a critical detail that gave the community hope: the DAO's split mechanism included a 28-day waiting period before funds in a child DAO could be further transferred. The attacker had the ETH, but it was locked in the child DAO for four weeks. This created a window for the community to respond.

The Response

The Ethereum community debated three options, and the debate revealed deep philosophical divisions about what a blockchain should be.

Option 1: Do Nothing

The "code is law" purists argued that the smart contract executed exactly as written. The attacker found a way to use the code that the developers did not intend, but the code did what the code does. Reversing the attack would undermine the fundamental promise of blockchain: that transactions are final and immutable. If you can reverse a transaction because enough people disagree with it, you have re-created the traditional financial system with its arbitrary interventions.

Proponents of this view included some of the most principled voices in the cryptocurrency community. They argued that the DAO investors accepted the risk when they invested in experimental smart contract code, and that the community should learn from the failure rather than erase it.

Option 2: Soft Fork

A soft fork was proposed that would blacklist the attacker's address. Miners would refuse to include any transaction that moved funds from the child DAO. This would not reverse the attack but would prevent the attacker from spending the stolen ETH. It was less controversial than a hard fork because it did not actually change transaction history.

However, security researcher Emin Gun Sirer identified a vulnerability in the soft fork proposal: the blacklisting mechanism could be exploited in a denial-of-service attack against miners. If a miner included a transaction that appeared to interact with the blacklisted address, other miners would reject the block, causing the first miner to lose the block reward. An attacker could submit transactions designed to trigger this rejection, effectively punishing miners who enforced the blacklist. The soft fork was abandoned.

Option 3: Hard Fork

The most drastic option: change the Ethereum protocol to move the stolen ETH from the child DAO to a refund contract. DAO token holders would be able to exchange their tokens for a proportional refund of ETH. This would effectively reverse the attack — the attacker would lose the funds, and investors would be made whole.

The cost was enormous in terms of precedent. A hard fork to reverse a specific transaction demonstrated that Ethereum's immutability was conditional — that a social consensus could override the code. Critics called this a "bailout" and argued it set a dangerous precedent. Supporters countered that 14% of all ETH was at stake, the vulnerability was in the DAO's code (not Ethereum's protocol), and failing to act would be catastrophic for the ecosystem.

The Fork

A vote was held. Roughly 85% of ETH holders who voted supported the hard fork. On July 20, 2016, at block 1,920,000, the Ethereum network executed the hard fork. The stolen 3.6 million ETH was moved to a refund contract at address 0xbf4ed7b27f1d666546e30d74d50d173d20bca754. DAO token holders could call this contract to claim their refund.

But the story was not over. A minority of the community refused to adopt the fork. They continued mining and transacting on the original chain — the chain where The DAO hack was never reversed and the attacker kept the funds. This chain was named Ethereum Classic and trades under the ticker ETC. Ethereum Classic still exists and is actively maintained, though its market capitalization and developer community are a fraction of Ethereum's.

The Attacker

The identity of the DAO attacker remained unknown for years. In 2022, journalist Laura Shin published an investigation in her book "The Cryptopians" identifying Toby Hoenisch, an Austrian-born programmer living in Singapore, as the likely attacker based on blockchain forensic analysis. Hoenisch denied the allegation. No criminal charges were ever filed related to the DAO hack specifically — the legal jurisdiction was unclear, the identity was disputed, and the hard fork had returned the funds to investors.

Impact and Legacy

The DAO hack fundamentally shaped the Ethereum ecosystem and the broader blockchain industry:

Smart contract auditing became an industry. Before The DAO, smart contract auditing was informal. After it, specialized security firms (Trail of Bits, OpenZeppelin, Consensys Diligence) emerged to provide professional auditing services. The DAO hack is the single most important origin event for the smart contract security industry.

The checks-effects-interactions pattern became doctrine. Every Solidity tutorial, course, and style guide now teaches CEI as a fundamental pattern. OpenZeppelin's ReentrancyGuard became one of the most used smart contract libraries.

Governance debates crystallized. The hard fork debate established the tension between "code is law" (immutability absolutism) and "the community decides" (social consensus). This tension continues to animate debates about blockchain governance, protocol upgrades, and regulatory intervention.

Ethereum Classic persists as a philosophical statement. Whether or not one agrees with the ETC community's position, its existence is a permanent reminder that the DAO fork was controversial and that reasonable people can disagree about whether immutability should ever be violated.

Regulatory attention increased. The SEC later issued a report (the "DAO Report" of July 2017) concluding that DAO tokens were securities under U.S. law. This report was a watershed moment for cryptocurrency regulation and established that decentralized does not mean unregulated.

Discussion Questions

Was the hard fork the right decision? Consider the perspectives of DAO investors, Ethereum developers, miners, and the broader public. Is there a principled framework for deciding when immutability should be overridden?
If The DAO hack happened today, with Ethereum's current market capitalization ($300+ billion) and institutional investor participation, would the response be different? Could a hard fork even be coordinated given the current scale and diversity of stakeholders?
The DAO's code had been reviewed by multiple developers before the attack, and the reentrancy vulnerability was identified publicly days before the exploit. Why was it not fixed in time? What does this reveal about the governance challenges of immutable smart contracts?
The attacker reportedly defended their actions by arguing that "the code is the contract" and they simply used the code as written. Is there a meaningful distinction between "exploiting a vulnerability" and "using the code as designed"? Should intent matter?
Ethereum Classic's continued existence demonstrates that blockchains are, ultimately, social systems — their legitimacy depends on community consensus rather than just code. What does this mean for the "trustless" narrative of blockchain technology?