Why is The DAO incident treated as the starting point for the entire Smart Contract security industry, rather than just an ordinary hack?
Because it was the first public event that made the entire industry realize how dangerous it is that, once a smart contract is deployed, any error in its code can potentially be unrecoverable — and the scale of the loss and its ripple effects were too large to ignore. It didn't just cause a financial loss; it directly triggered an unprecedented governance crisis and chain split within the Ethereum community. Before this, smart contract security was more of a theoretical discussion; after this incident, code audits, formal verification, and the development of standard security libraries only became something the entire industry treated as a hard requirement worth investing real resources in.
Is the debate between "code is law" and the pro-fork position still meaningful today?
Yes, and the framework of that debate is still being applied to many new controversies — whenever a major hack occurs and a community discusses whether to freeze assets or help recover funds, it's essentially re-confronting the same question: is a blockchain's immutability an absolute principle with no exceptions at all? The DAO incident matters because it was the first time this philosophical question moved from abstract discussion into a real, concrete decision affecting tens of thousands of users — and that decision had no standard answer, only a choice the community made through voting and action. Understanding this history helps readers more clearly see why, in similar incidents since, "should we intervene" remains a contentious question with no simple answer.
If the defenses against reentrancy are already mature and the industry knows about it, why did a case like Solv Protocol still happen in 2026?
This is exactly what makes this case worth discussing — the problem usually isn't "developers don't know about this vulnerability," it's "the protection wasn't fully applied to every corner of the protocol." Most new protocols integrate large amounts of third-party code libraries or inherit existing base contract architecture during development, and whether that external code has correctly implemented reentrancy protection isn't something every team re-checks line by line at the moment of integration. Add in competitive market pressure, where a protocol often needs to launch within a time constraint, and the depth and coverage of an audit can get compressed. This reflects not a technical difficulty problem, but a trade-off in process and resource allocation — knowing how to defend against something and ensuring it's actually properly implemented everywhere are two different things, with a real execution gap between them.
Now understanding the full history of reentrancy attacks, how should an ordinary user concretely adjust how they judge whether a protocol is safe?
The most direct adjustment is not treating "this vulnerability is old, the industry should understand it by now" as a reason to lower your guard — as this article demonstrates, being old doesn't mean it's been eradicated, only that it's no longer the primary source of threat. Concrete things worth checking include: whether the protocol's audit report explicitly mentions testing against reentrancy attacks (you can search for keywords like "reentrancy" or "checks-effects-interactions"), whether the protocol uses an industry-standard protective library rather than implementing its own, and whether the protocol's core contracts were newly developed or inherited a code base from another project (whether that inherited portion was also within this audit's scope is a particularly worthwhile question to ask). The value of understanding this decade of history isn't memorizing the technical details of the attack mechanism — it's building the habit of always asking, for any problem that "should have been solved long ago," whether it was actually solved this time.
If you had to pick one event as the starting point for the entire Smart Contract security industry, most people in the field would pick the 2016 DAO incident. That's not just because of its scale (roughly $60 million worth of Ether stolen at the time), but because it left behind a conclusion that's still being re-verified today: the code logic flaw that caused that accident a decade ago is still costing new protocols real money in 2026. This article traces that full decade-long arc — how the incident itself unfolded, how it reshaped Ethereum, and why the same vulnerability still hasn't been fully eradicated.
The DAO was a decentralized venture fund launched in 2016 that, at the time, set a blockchain crowdfunding record for funds raised. Its withdrawal function had a logic flaw: when the contract transferred Ether to whoever was withdrawing, it simultaneously triggered code execution at the withdrawer's address, but the contract only updated its internal ledger — recording that the funds had been withdrawn — after the transfer completed. That's exactly the timing gap the attacker exploited: using a malicious contract to receive the transfer, and in the instant before the contract had a chance to update its records, immediately calling the same withdrawal function again. Because the ledger at that moment still showed "not yet withdrawn," the funds got sent out again — recursing dozens of times until the fund pool was drained. The entire attack unfolded within a single transaction, taking just a few minutes.
After the incident, the Ethereum community fell into a philosophical dispute still cited to this day: whether to use a hard fork to forcibly "return" the stolen funds to their original holders. Those in favor of forking argued that a blockchain's purpose couldn't be built on the sacrifice of everyone else's interests; those against argued that "code is law" is an inviolable core principle of blockchain — that using collective power to rewrite history simply because you didn't like the outcome effectively negated immutability itself. In the end, the majority of miners and developers chose to execute the hard fork, giving rise to what we call Ethereum (ETH) today; the minority who refused to fork, sticking with the original chain's history, continued on as Ethereum Classic (ETC). This split remains one of the most frequently cited cases in cryptocurrency governance history — it proved that a purely technical vulnerability could ultimately evolve into a philosophical debate over whether immutability has exceptions.
Looking purely at loss share, reentrancy attacks have shown a clear long-term improvement trend. A study by blockchain security firm Immunefi covering six years of DeFi loss data found that ecosystem-level attacks (including Flash Loan price manipulation and reentrancy) fell from nearly 19% of total DeFi losses in 2022 to under 1% in 2025. That decline largely reflects the industry's defensive maturity — the checks-effects-interactions pattern and reentrancy guards are now standard items in mainstream development frameworks and audit checklists, and static analysis tools can relatively easily catch this class of logic flaw.
But a declining share doesn't mean the vulnerability has disappeared. In January 2026, a vault under Bitcoin yield protocol Solv Protocol was still hit by a reentrancy double-mint vulnerability — the attacker repeatedly executed the mint operation 22 times, turning 135 legitimate tokens into roughly 567 million counterfeit tokens conjured from nothing, redeeming them for roughly $2.7 million in assets. Researchers commonly note that the reason this type of incident still happens isn't usually that developers don't know the vulnerability pattern — it's that protocols inherit insufficiently audited base contracts under time pressure, or fail to re-examine whether standard protections were correctly applied when integrating third-party code libraries.
For an ordinary user, the practical takeaway from this decade of reentrancy history isn't "this vulnerability has become rare, so it's safe now" — it's that the declining overall share reflects attackers' attention shifting, not this attack method being retired. In recent years, the largest-scale incidents — involving bridge verification logic or governance permissions, for instance — have indeed surpassed simple reentrancy bugs. But that doesn't mean reentrancy has left the stage entirely; it's more like it moved from "the top battlefield" to a background risk that's "still present, still capable of being triggered, but no longer attackers' first choice." For a newly launched protocol with less thorough auditing, it remains an old-style trap that can go off at any time. When judging whether a protocol is trustworthy, beyond confirming the audit report covers reentrancy testing, it's also worth checking whether the underlying code base that protocol inherited has itself been sufficiently vetted — because the lesson from a decade ago proves the problem often isn't in newly written logic, but hidden in old code everyone assumed was fine and nobody re-checked.