Author｜ Darko @ IOSG

On April 1, 2026, at 16:05:18 UTC, an attacker submitted a transaction to the Drift Protocol. One second later, another transaction approved it. Twelve minutes later, $285 million vanished. Seventeen days later, a compromised validator on the KelpDAO cross-chain bridge single-handedly minted $292 million worth of unbacked tokens, triggering an outflow of approximately $8.5 billion from Aave within 48 hours, and approximately $4.5 billion from other DeFi protocols. Twelve days later, an attacker possessing the stolen deployer's private key withdrew $4.5 million from the Wasabi Protocol across four chains.

None of these incidents were caused by exploiting smart contract vulnerabilities.

For most of its decade, DeFi firmly believed that security was a code problem. Auditing, formal verification, bug bounties—the entire industry was self-organized around the premise that as long as smart contract logic was sound, the protocol was secure. Mathematics was law. April 2026 was the month this premise collapsed in the public eye. Over $625 million was stolen in approximately 30 incidents in a single month—according to DefiLlama, this was the worst month in crypto history in terms of the number of incidents—and every major loss traced back to administrator private keys, cross-chain bridge validators, oracle blind spots, or social engineering attacks—all operational foundations that auditing was never designed to cover.

This article will discuss this migration. We will dissect the three major hacking incidents in April into three faces of the same underlying failure, review how a protocol's faulty cross-chain bridge configuration led to a $13.2 billion outflow from a protocol 25 times larger, and frankly examine the true face of DeFi now—it is, in fact, an open infrastructure with trusted operational leverage, even if that's not the marketing rhetoric. The problem isn't in the math. The problem lies in the "mental model" surrounding the math.

Mathematics itself isn't bad. What's bad is the mental models built upon it, and the cost of this misalignment is forcing the industry to re-examine what "decentralization" truly means.

Mental model gap

For much of DeFi's history, the mainstream security culture has been based on Solidity. Audits scrutinize contract logic. Bug bounties pay for reentrancy, integer overflows, and access modifier errors. Formal verification proves invariants in on-chain code. The implicit assumption is that everything outside the contract—multisignature, deployer private keys, cross-chain bridge validators, Relayer infrastructure, team communication channels—is either out of scope or someone else's problem.

This assumption only holds true when attackers are exploiting Solidity vulnerabilities.

Several hacking incidents in April 2026 shared a structural characteristic that audit reports failed to describe: the smart contracts themselves were not vulnerable. According to independent on-chain researchers, Drift's code was audited twice, once by Trail of Bits in 2022 and again by ClawSecure in February 2026, both of which passed. Neither audit covered Drift's multi-signature configuration, durable nonce handling logic, or the social engineering attack surface surrounding its Security Council. KelpDAO's LayerZero adapter is standard OFT template code; the contract itself has no issues. The problem lies in the deployment configuration, which is typically outside the scope of Solidity audits. Wasabi's Vault contract is designed to be upgradeable; the design itself is flawed.

What collapsed in April was not mathematics itself, but the operational foundation upon which mathematics depends.

Three Dissections: Three Faces of the Same Failure

The three major hacking incidents in April 2026—Drift, KelpDAO, and Wasabi—represent three distinct types of "non-code failures." Together, they cover most of the new attack surface and share the same structural characteristic: in each incident, the breach of one or two individuals or infrastructures created a domino effect on the entire protocol.

Drift: Human-assisted multi-signature program ($285 million)

The Drift hack was an intelligence operation, not a vulnerability exploit. Analysis by TRM Labs, Elliptic, and Drift itself, with assistance from SEAL 911, attributed the attack to the North Korean Lazarus Group, specifically the UNC4736 sub-group, which Mandiant had previously linked to the Radiant Capital attack in October 2024. The attackers spent approximately six months planning the operation. Social engineering began at an industry conference in the fall of 2025, while on-chain preparations only started three weeks before the incident.

On March 11, 2026, the operation began with a donation of 10 ETH from Tornado Cash. The following day, around 9:00 AM Pyongyang time, these funds were deployed as CarbonVote Tokens (CVT) on Solana. The attackers created a small liquidity pool on Raydium, using wash trades of CVT to anchor the market price around $1, and then set up a price oracle they controlled, feeding this artificial price to Drift. The wash trades were there to make the oracle's output "appear legitimate"—any random check would find that the market price matched the oracle's quote.

Meanwhile, the attackers posed as a quantitative trading firm, spending weeks building relationships with Drift contributors. Their aim wasn't to extract information, but rather to cultivate trust in advance for a specific moment.

That moment relied on a Solana feature called durable nonces: a legitimate mechanism that allows "sign today, execute later." Between March 23 and March 30, the attackers obtained durable nonce signatures from at least two of the five members of the Drift Security Council. From the signers' perspective, they were approving routine transactions. From the network's perspective, these signatures were valid authorization credentials, in a dormant but effective state.

On March 26, Drift made a decision that, in hindsight, was disastrous: to migrate to a completely new 2-of-5 Security Council multisignature with zero timelocks. This migration eliminated the potential window of delay that could have been used to detect or intervene in attacks.

At 16:05:18 UTC on April 1st, the attacker submitted the first pre-signed durable nonce transaction—a proposal to transfer administrator control to address H7PiGqqUaanBovwKgEtreJbKmQe6dbq6VTrw6guy7ZgL. One second later, at 16:05:19 UTC, the second pre-signed transaction was approved and executed. The attacker gained control of Drift.

What happened next took only twelve minutes. The attackers used worthless CVT as collateral, with virtually unlimited lending, depositing 500 million CVT at manipulated oracle prices, and then withdrew $285 million in real assets—JLP, USDC, SOL, cbBTC, wBTC, and ETH—from three core Vaults. Drift's TVL collapsed from $550 million to approximately $250 million. Two signers, one protocol, and the smart contract worked exactly as designed. The vulnerability lay with the "human."

One point regarding Drift's post-incident response deserves special mention because it relates to the standard that the next wave of victimized protocols should meet: Drift's own post-incident disclosure was exceptionally frank. Within five days of the vulnerability being exposed, the team released a detailed social engineering attack recap—including the following facts: contributors were contacted multiple times over a six-month period; two contributors may have been compromised through code repository cloning and a TestFlight wallet beta version; Telegram chats with the attackers were deleted before and after the attack; and the decision to migrate to zero-timelock multisignature six days prior to the incident eliminated the final detection window. The team also released the attack attribution (UNC4736 / Citrine Sleet) with moderate credibility, coordinated with SEAL 911, and shared operational details that could help other protocols identify the same tactics. Victimized protocols often retreat into legal caution and vague wording; Drift chose to release a narrative with forensic quality that could transform a single incident into industry-wide threat intelligence. The incident itself remains a hacking incident, and the underlying governance vulnerability remains a vulnerability. But the willingness to disclose "how social engineering works" is key to distinguishing agreements that contribute to collective learning within the industry from those that silently swallow losses.

KelpDAO: Single Validator ($292 million)

Seventeen days later, on April 18th, the same type of threat actor profile produced a structurally completely different attack. KelpDAO, a liquidity restaking protocol, issued rsETH—a token representing user deposits that earned additional rewards through EigenLayer routing. By April 2026, rsETH's TVL had exceeded $1 billion and was deployed on over 20 chains via LayerZero's OFT (Omnichain Fungible Token) standard.

The contract is fine. The configuration is the problem.

KelpDAO's cross-chain bridges run on a 1-of-1 DVN (Decentralized Verifier Network)—meaning there is only one validator. One node is sufficient to approve a cross-chain message. "Decentralized" is a term, not an architecture.

The attack was carried out in stages. The attackers first compromised the internal RPC nodes that validators relied on to read the source chain state, and then launched a coordinated DDoS attack on external nodes, forcing the system to revert to the compromised infrastructure. After gaining control of the data source, they forged a cross-chain message instructing the KelpDAO Ethereum mainnet contract to mint rsETH with a destruction that "never happened on any source chain".

At 17:35 UTC, the contract released 116,500 rsETH—worth approximately $292 million, roughly 18% of the token's circulating supply—to an address controlled by the attacker. Within minutes, these rsETH were deposited into Aave as collateral, each valued at approximately $2,500. The attacker borrowed real WETH, USDC, and wBTC using this unbacked collateral, ultimately withdrawing over 82,600 ETH (approximately $191 million) before KelpDAO suspended the contract at 18:21 UTC.

Two subsequent attempts at 18:26 and 18:28 UTC, each trying to withdraw another 40,000 rsETH, were both rolled back. The pause prevented further losses, but not the initial one.

There were no reentrancy vulnerabilities, no missing access checks, and no oracle tricks within Kelp's own logic. The accounting invariant defining cross-chain bridges—that assets released on the destination chain must equal assets destroyed on the source chain—was violated at the system level, not the transaction level. One node, hundreds of millions of dollars in losses.

What followed was a public controversy: who should bear the responsibility? LayerZero's initial post-incident report directly blamed Kelp, arguing that Kelp had violated guidelines by choosing a 1-of-1 DVN. Kelp's rebuttal memo on May 5th presented a different picture: at the time, 47% of active LayerZero OApp contracts—approximately 1,250 applications with a combined market value exceeding $4.5 billion—were running on the same single validator configuration. Kelp argued that LayerZero's own OFT Quickstart, GitHub examples, and developer templates all came with LayerZero Labs' own DVN as a mandatory validator from the outset, with no second one; and presented Telegram screenshots from LayerZero staff who told the Kelp team in eight integration discussions over two and a half years that "using the default value is fine." Security researcher Sujith Somraaj (former LayerZero auditor) had submitted a bug bounty report to Immunefi that precisely described this attack pattern, but it was rejected by LayerZero on the grounds that "validator network selection is an application-layer configuration".

LayerZero responded to the Kelp memo by stating that the statement was misleading. The exclusion of "application-layer configuration" from bug bounties is a standard "platform/application" boundary (a LayerZero spokesperson pointed out that otherwise "any application could set itself as the sole DVN and maliciously collect rewards"); the default value of the protocol in almost all paths is actually multiple DVNs; as for those 1-of-1 templates, the sole DVN points to a placeholder contract called "DeadDVN," which rejects all messages, forcing developers to configure the security stack themselves before deployment. Regarding Kelp, LayerZero stated that Kelp initially deployed multiple DVNs and later manually downgraded to 1-of-1—not "using the default value." The platform vs. application boundary is indeed a real point of contention; rational engineers will disagree on whether they should be responsible for the actual configuration deployed by users when templates can be configured to be in a dangerous state.

Even less controversial was the second part of LayerZero's final response. On May 8th, three weeks after the initial post-incident report, LayerZero reversed course and apologized: "We made a mistake by allowing our DVN to operate as a 1-of-1 DVN in high-value transactions. We failed to constrain our DVN regarding what protections it provides." The protocol stopped supporting 1-of-1 within the DVN ecosystem, moved the default to 5-of-5, raised its multisignature threshold from 3-of-5 to 7-of-10, and announced a new issuer monitoring platform (Console). Whether the underlying configuration was Kelp's fault, LayerZero's fault, or—most likely—a shared failure between a platform that could be configured to a dangerous state out of the box and an integrator that proactively downgraded, both parties' final responses converged on the same answer: 1-of-1 verification is insecure at scale, and the industry shouldn't have spent $292 million to learn this.

Wasabi: Administrator Private Key ($4.5 million)

The Wasabi attack on April 30th was an order of magnitude smaller than the other two, which is why it was the most embarrassing. It was a "boring hack."

A deployer EOA—address 0x5c629f8c0b5368f523c85bfe79d2a8efb64fb0c8—holds ADMIN_ROLE in the Wasabi perpetual contract manager deployed on the Ethereum, Base, Blast, and Bera chains. No multisignature is used. The contract framework originally supported timelocks, but the configured value is zero.

The attackers obtained the private key—phishing, device intrusion, and supply chain attacks are all possibilities, Wasabi did not provide a final conclusion. With ADMIN_ROLE, they assigned the same role to a malicious auxiliary contract, performing a UUPS proxy upgrade on the Vault contract, and sweeping away collateral and pool balances. Total cross-chain losses amounted to $4.5 million–$5.5 million.

Wasabi didn't use any new technologies. This kind of vulnerability, as an anti-pattern in DeFi, has been warned about for years: excessive centralization of governance, lack of separation of powers, and no window of opportunity for delay. This is the same vulnerability that DeFi has been plagued by since 2020, with constant post-mortem reports but never actually addressed in practice.

Connecting the three incidents: Ultimately, they all involve the same type of hacking. Whether privileged access was gained by manipulating signers, hacking validators, or stealing deployers' private keys, the attack surface is the same—a concentration of power outside the smart contract layer, with inadequate protection. This pattern also serves as a warning: in each incident, one or two compromised entities trigger a domino effect that no amount of Solidity hardening can stop.

Asymmetric dominoes

The significance of the KelpDAO incident extends beyond its dollar amount itself because of what happened afterward—this was the first real stress test of DeFi composability under operational failure—and it is by far the most telling case of how absurdly asymmetrical the mathematics of sprawl can be.

Let's put the scales together: At the time of the incident, KelpDAO's rsETH TVL was approximately $1 billion; Aave's AUM across all chains exceeded $25 billion. A protocol with a size of only about 4% of Aave's could, in a single event, drain $8.45 billion from Aave within 48 hours—a figure that grew to $15.1 billion within three and a half days—while the entire DeFi TVL decreased by $13.21 billion during that 48-hour window. The asymmetry is the real story. A small protocol with a misconfigured cross-chain bridge triggered a bank run on a much larger protocol that, by all its own contract metrics, was "operating according to regulations."

When the attacker minted unbacked rsETH and deposited it into Aave, Aave's contract executed exactly as specified. Its oracle, during the brief window of the attacker's lending, still read rsETH as nearly 1:1. The lending pool released real WETH against collateral that appeared "valid" to all on-chain systems.

The market reaction was immediate. Within hours, rsETH was trading at a deep discount on DEXs, reflecting a real uncertainty—whether the remaining 82% supply was still fully supported. Aave V3 and V4 froze the rsETH market; Fluid, Compound, Euler, and Morpho followed suit within hours (SparkLend had already delisted rsETH back in January). rsETH holders on Arbitrum, Base, Mantle, Linea, Blast, and Scroll were no longer certain that their tokens could be redeemed 1:1 for Ethereum mainnet custody.

The subsequent outflow of funds was not due to Aave being hacked, but rather because depositors were uncertain whether the collateral used to secure their loans was still capable of repayment. In the weeks leading up to the incident, Aave had accumulated a substantial rsETH position as users leveraged restaking transactions; the protocol earned fees from these transactions without setting a cap on this exposure. Therefore, this contagion wasn't purely a case of "innocent bystander" behavior—Aave itself chose to bear the risk of the counterparties—but the triggering event occurred outside its own contracts and beyond the scope of its governance.

Aave's response to this incident deserves special mention, as it sets a benchmark for other large lending protocols. Within hours of the incident being exposed, the protocol's emergency administrators froze the rsETH market on all affected chains' V3 and V4, setting the LTV to zero and preventing further losses. Within 48 hours, Aave's service providers published a detailed incident report on the governance forum, publicly modeling two different bad debt scenarios—$123.7 million if Kelp socialized the losses among all rsETH holders; and $230.1 million if the losses were isolated to L2 deployments—along with a chain-by-chain breakdown showing which markets would bear which gaps.

Aave founder Stani Kulechov personally pledged 5,000 ETH for the recovery; the DeFi United consortium, led by Aave service providers and including Lido, EtherFi, LayerZero, Mantle, and others, raised over $300 million in pledges to fill the rsETH shortfall. This is the largest cross-protocol rescue in the industry to date.

The criticism is narrower and should be considered separately from the response: Aave's stance shifted as the bad debt range became clearer. The initial promise that its Umbrella reserves would cover the gap was softened within days to "exploring paths to fill the gap." This narrative shift, though minor, is noteworthy—protocol-level insurance, which sounds convincing in an abstract context, becomes negotiable once the numbers are concrete. Aave's operational handling doesn't change the structural fact: depositors who put USDC into the protocol bear counterparty risk for a token they may not even know exists, and the protocol's insurance mechanism is ultimately much weaker than implied in the documentation.

This is the deeper structural problem. Aave's single-pool design, which gives it deep liquidity and a streamlined experience, also means that a poor collateral listing can have an explosive radius across the entire protocol. Even with Aave's diligent governance and robust contracts, the protocol is still downstream of a much smaller counterparty's safe failure—an exposure that could put nine-figure depositor funds under pressure and trigger a market freeze on nine protocols.

The composability that underpinned DeFi's growth, and also its contagion channel, will be settled on a large scale for the first time in April 2026. The legislative changes are not significant. The composability that once drove DeFi's growth has now become a contagion channel for how the operational failure of one protocol can lead to a bank run on another protocol.

The Truth About OpenFi

We've veered into a conversation that the industry has been avoiding.

Let's call it OpenFi: permissionless access and on-chain auditability, but at the crucial juncture where "the original decentralized argument should remove intermediaries," its operation still relies on trusted third-party financial infrastructure. By this definition, most things marketed today under the name of DeFi are OpenFi. A Security Council with the power to transfer administrator control. A cross-chain bridge with only 1-of-1 validators. A deployer EOA with a cross-chain ADMIN_ROLE. A governance token centralized enough to allow a patient minority to capture the treasury, like Nouns. Each one is a "privileged seam" patched up in a supposedly seamless system.

It's worth revisiting the original arguments. Szabo's "trust-minimized" computation, Buterin's "trust-neutral" infrastructure, and Cypherpunk's insistence on removing, rather than auditing, intermediaries for privacy and freedom—none of these are about "transparency." Transparency is necessary and easy. The truly difficult claim—the one that justifies all the friction of "running a global state machine on tens of thousands of redundant nodes"—is that "no party in the system can be coerced, captured, bribed, or hacked to change the rules." A public ledger that you can examine but cannot influence is different from a public ledger where the administrator's private key lies in someone's safe or hardware wallet. OpenFi preserved the first half of the deal, quietly discarding the second.

Different protocols rely on different types of trust, and their failure modes vary. It's helpful to name them: Custodial Trust (someone holds your real assets; you're trading a claim on them—cross-chain bridges, token wrappers); Upgrade Trust (someone can change contract behavior after you deposit—proxy administrators, Security Councils); Oracle Trust (someone provides data that the contract itself cannot generate—price feeds); Liveness Trust (the system's proper functioning depends on someone continuously operating it—sorters, Relayers, Keepers); Governance Trust (token holders, or the small group that can gather a quorum in a disputed vote). Most protocols rely on three or four of these simultaneously. Most marketing copy collapses them all into the single word "decentralized," leaving the reader to guess the rest.

The bigger problem is that some of these assumptions were completely hidden. In its May apology, LayerZero admitted that three and a half years ago, one of its multisignature signers had used a production hardware wallet to conduct a personal transaction. This oversight was never disclosed to users after being internally fixed, and finally surfaced as part of a hardening announcement, packaged as a routine overhaul rather than a confession. Users who trusted the system had no way of knowing about this, nor any way of pricing in the risk that "it really happened."

There's a euphemism in the industry for this gap: the "training wheel." The selling point is that the administrator's private key and the Security Council are transitional—they exist today, to be removed once the protocol matures to operate independently. In practice, training wheels are almost never removed. They are renamed, repackaged, renewed, or quietly transferred to a foundation. L2Beat's Stage 0/Stage 1/Stage 2 framework is the cleanest exception, proof of the existence that "the industry can frankly describe its actual trust assumptions if it wants to." The fact that almost no protocol uses L2Beat-style expressions in its marketing is itself evidence that "dishonesty is structural, not accidental."

This is the reality of engineering, shaped at every layer by the incentives faced by builders. If you want to quickly launch complex products, respond to vulnerabilities without forking protocols, support new collateral types, and integrate with other parts of the ecosystem, you need operational leverage. Completely immutable contracts without privileged access are indeed robust, but also fragile—any change requires a full migration, any vulnerability becomes permanent, and any new feature requires users to opt-in to join a new deployment. Beyond technical factors, there's another reality: VC timelines don't allow for a three-year formal validation period; protocols that launch first secure liquidity first.

Composability exacerbates the problem: an immutable protocol cannot integrate with new oracles, support new chains, or patch discovered vulnerabilities unless all users and integrators are forced to migrate. The result is that for any single team, the rational choice is to "publish with the administrator's private key, promising future removal"; for any single user, the rational choice is to accept this trade-off, because alternative protocols either don't exist or lack liquidity. OpenFi is not a moral failure of individual builders. It is the Nash equilibrium of this field.

The honest statement is: DeFi has almost universally opted to trade off some decentralization for operational viability. This choice is justifiable. The dishonesty lies in not naming the trade-offs and continuing to market protocols as "decentralized" when their actual security models rely on a few signers, a validator, or a multi-signature mechanism that can be compromised by social engineering.

The road ahead is closer to "disclosure" than "revolution": labeling trust assumptions according to the L2Beat model; sufficiently long time delays to allow users to exit before privileged operations are completed; an insurance market that prices "operational risks" rather than fictitious "pure code risks"; and a clear distinction between "which parts of the system actually need upgrade paths" and "which parts are simply made variable due to architectural habits." April 2026 did not prove OpenFi unworkable. What it proved was that marketing an OpenFi system as DeFi leaves its users completely unprepared for its actual failure modes. To make such a system secure, the first step is to honestly acknowledge that this is what we are building.

Centralized Two-Sided Coin

The core trade-offs of OpenFi became starkly apparent in the Arbitrum freeze. Three days after the KelpDAO vulnerability was exploited, Arbitrum's Security Council voted to freeze 30,766 ETH—approximately $71 million—that the attackers had transferred to Arbitrum One. The freeze, coordinated with law enforcement, is by most standards a good outcome: stolen funds were prevented from being laundered, the attackers' downstream channels were shut down, and some users' losses may still be recoverable.

But note what made this freeze possible: Arbitrum has a Security Council with the authority to "reach into the blockchain to transfer funds." This is not a characteristic of decentralized infrastructure. It's a centralized shut-off switch that exists by design—defendable under the guise of an "emergency response," and used in the way critics have always feared—not necessarily bad, but certainly with significant consequences.

The same mechanism that allowed Arbitrum to play the "good guy" after the Kelp incident is also the same mechanism that led to Drift's downfall—a small group of trusted signers wield the power to execute protocol-level operations, differing only in the extent to which this power is constrained. Once, this power was legitimately used to freeze stolen funds; another time, it was hijacked by social engineering to drain user deposits. Leverage—it can harm people on both sides.

The "shutdown switch" fails through at least five different channels—social engineering (Ronin, Drift), insider intrusion (Multichain), sovereignty coercion, legal enforcement (Tornado Cash, USDC), and governance hijacking (Beanstalk, Mango Markets). Each is a different attack with different defenses; the phrase "Council failed" obscures the whole picture. Identifying the specific channels of failure is the first step in beginning to defend against it.

This is the "centralized two-sided coin" in DeFi, and it's also the most important thing about the current state of the industry: every operational leverage that can bring "good results" in an emergency is also an attack surface—it can bring bad results in another event.

A deeper issue is that in the Arbitrum case, the term "good outcome" carries too much weight. Legitimacy is socially constructed, and the same kind of leverage has been used when consensus is far from clean. The Ethereum DAO fork in 2016 remains a classic example: half the community insisted that reversing the $60 million vulnerability was the most obvious and legitimate use of social consensus; the other half insisted that it was a fatal betrayal of "code is law" and forked away, allowing the original chain to continue as Ethereum Classic.

Circle and Tether frequently freeze USDC and USDT addresses, sometimes in response to OFAC sanctions, sometimes on mere suspicion, leaving affected users with no recourse—the freezes are presented as compliant, but are essentially discretionary. The Arbitrum freeze worked. The DAO fork, in a sense, also worked. USDC freezes are routinely effective. The honest question isn't "whether turning off the switch produces good results," but rather "who decides what constitutes a good result"—and what the protocol's users are actually informed about this decision-making process.

No trade-off can be "either/or". You either have an off switch, in which case you have something that can be captured, manipulated, or socially engineered; or you don't, in which case you must accept that some events will be permanent and irreversible.

These levers are not interchangeable. Arbitrum's Security Council can quickly transfer funds with low barriers through emergency procedures—the combination of "speed + scope" makes freezing possible, but the same combination also makes the Council's own failure mode catastrophic when it is hacked.

THORChain has a narrower leverage: it can suspend operations and recapitulate through RUNE issuance, but it has no right to seize or redirect user assets. Aave's emergency administrator can freeze the market and adjust risk parameters, but cannot transfer user balances. MakerDAO's emergency shutdown is a one-way exit, not a confiscation tool. Different forms, different trade-offs, yet all are abbreviated as "shutdown switch." A protocol willing to honestly address its own trust model owes users not a scope, but a specific form.

The industry also tends to avoid another distinction: the difference between "leverage used only in extreme situations" and "leverage used in normal operations".

Both Bitcoin and Ethereum, in principle, have a shut-off switch—a sufficient degree of coordination among nodes, miners, validators, and exchanges could allow either chain to fork tomorrow. These two chains are still considered to have credibly minimized trust because this lever has almost never been pulled; each time it was pulled, the cost was a permanent community split. The DAO fork, ten years ago, remains one of the most controversial events in Ethereum's history. Bitcoin has never experienced a similar fork. The leverage exists, but it is credibly committed to "holding back" in routine transactions. It is this long history of restraint that gives the underlying system a level of trust that no single design feature can provide.

In contrast, Arbitrum's Security Council operates at a regular pace. It votes on upgrades periodically. It took emergency action before the Kelp freeze and will take more afterward. It's not a dormant reserve capability, but an active governance body. OpenFi criticism applies far more strongly to "active leverage" than to "dormant leverage," because the restraint of dormant leverage itself sends a signal—the trust earned by operators with extremely high barriers to entry is something leverage itself cannot grant. Active leverage doesn't send this signal. They can only be evaluated through their own controls, which have repeatedly proven insufficient.

THORChain took a "no-leverage" approach after a vulnerability in 2021, drawing criticism for its lack of intervention. Arbitrum went for a "shutdown switch" approach and received praise. Both options are justifiable. Neither is free. The industry must stop pretending it's possible to have both—and must honestly tell users which trade-off each specific protocol actually makes.

The final twist: this trade-off will only worsen over time. Once a protocol can be frozen, regulators and courts are increasingly inclined to rule that it "must" be frozen. USDC's freezing capability, initially an emergency compliance tool, has now become a de facto mandatory response to OFAC notices and an ever-expanding list of state enforcement actions. The decision to "go live with a shutdown switch" is also a decision to "inherit a list of mandatory uses that will continue to grow throughout the protocol's lifecycle," many of which are inconsistent with the direction the protocol's community would support. THORChain's "no leverage" stance is therefore not only an engineering choice but also a regulatory posture—it preemptively excludes the "obligation to comply" by preemptively excluding the "possibility of compliance." Whether this posture can survive under continued enforcement pressure is an open question, but the asymmetry is real: leveraged protocols can be forced to use it; those without cannot.

For institutions observing from the sidelines, this honesty is far more important than marketing. An operational shut-off switch with clear disclosure, coupled with documented governance, key management, and incident response—that's something a treasury team or insurance company can underwrite. A protocol that claims to have minimal trust but runs on top of a zero-timelock 2-of-5 multisignature is not. The former is a legitimate engineering choice. The latter is a risk that no one can price.

What will happen next?

The industry cycle habit is forgetting. Every four-year cycle reinvents the very institutions that DeFi was supposed to replace, gets beaten up as a result, briefly remembers why the principles exist, and then forgets them again. What happened in April was not unprecedented. It was an industry that traded convenience for principles, without naming names, and its eventual state was predictable.

Three decisions are now facing the industry, and none of them can be postponed any longer.

Centralization. Every protocol must publicly choose which operational leverage it holds and explain this choice to users. An honest version of DeFi isn't the kind that markets itself as "decentralized" while running on a zero-timelock 2-of-5 multisig; rather, it's DeFi that publicly discloses the multisig composition, thresholds, timelock, and conditions for using each type of leverage. Clearly defining the trade-offs is the only way for trade-offs to survive.

Security. Auditing is not the boundary. Protocols that survive the next cycle will treat operational security—keys, signers, cross-chain bridges, configuration, incident response—as a first-class discipline, on par with Solidity audits. Most teams still treat it as logistical. This attitude has been unacceptable since the treasury allocators started asking the questions they would ask today.

Fund allocation. The funds that will determine the next cycle are sitting on the balance sheets of pension funds, sovereign wealth funders, corporate treasuries, and insurance companies—they're on the sidelines. They don't need pure trust minimization. They need operational risk that can be insured. Protocols that look more like critical infrastructure than experimentation will absorb this flow of funds. Other protocols will continue to hold onto the retail funds they've always had, watching the institutional wave bypass them.

April 2026 is not a security crisis. It is the moment when the industry's mental model completely shatters, and when the surviving protocols begin to be distinguished from the ones that will not.