DeFi has reached its most dangerous moment: the real vulnerabilities are not in the code

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 minted $292 million in unsupported tokens on its own, triggering an outflow of approximately $8.5 billion from Aave within 48 hours, while other DeFi protocols experienced an outflow of about $4.5 billion. Twelve days later, an attacker holding the private key of a stolen deployer drained $4.5 million from the Wasabi Protocol across four chains.

None of these events were due to exploiting smart contract vulnerabilities.

For more than half a decade, DeFi has believed that security is a code problem. Audits, formal verification, bug bounties—the entire industry has organized itself around one premise: as long as the logic of the smart contract is sound, the protocol is secure. Mathematics is law. April 2026 was the month this premise collapsed in the public eye. In that month alone, over 30 incidents collectively resulted in more than $625 million stolen—according to DefiLlama data, this was the worst month for hacks in crypto history by number of incidents—and each significant loss traced back to administrator private keys, cross-chain bridge validators, oracle blind spots, or social engineering attacks, all of which audits were never designed to cover.

This article will discuss this migration. We will break down three severe hacking incidents in April into three faces of the same underlying failure, reviewing how a protocol's misconfigured cross-chain bridge triggered an outflow of $13.2 billion from a protocol 25 times its size, and frankly examine the current reality of DeFi—it is, in fact, an open infrastructure with trusted operational leverage, even if the marketing rhetoric does not say so. The problem does not lie in mathematics. The problem lies in the "mental models" surrounding mathematics.

Mathematics is not broken. What is broken is the mental model built on top of mathematics, and the cost of this misalignment is forcing the industry to re-examine what "decentralization" really means.

I. Mental Model Gap

For most of DeFi's history, the mainstream security culture has been based on Solidity. Audits review contract logic. Bug bounties pay for reentrancy, integer overflow, and access modifier errors. Formal verification proves invariants for on-chain code. The implicit assumption is that everything outside the contract—multisigs, 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 when attackers exploit Solidity vulnerabilities.

The hacking incidents in April 2026 share a structural characteristic that an audit report cannot describe: the smart contracts themselves had no vulnerabilities. According to independent on-chain researchers, Drift's code was audited once by Trail of Bits in 2022 and again by ClawSecure in February 2026, both passing. Neither audit covered Drift's multisig configuration, durable nonce handling logic, nor the social engineering attack surface surrounding its Security Council. KelpDAO's LayerZero adapter is standard OFT template code, and the contract itself has no issues. The error lies in the deployment configuration, which typically falls outside the regular scope of Solidity audits. Wasabi's Vault contract is designed to be upgradable; the design itself is a vulnerability.

What collapsed in April was not mathematics, but the operational foundation on which mathematics relies.

II. Dissection of Three Cases: Three Faces of the Same Failure

The three severe hacking incidents in April 2026—Drift, KelpDAO, Wasabi—represent three distinctly different "non-code failures." Together, they cover most new attack surfaces and share the same structural characteristic: in each incident, one or two compromised entities or infrastructures triggered a domino effect across the entire protocol. Drift: Human-Operated Multisig ($285 million) The Drift hack was an intelligence operation, not a vulnerability exploit. Analysts from TRM Labs, Elliptic, and Drift itself, with assistance from SEAL 911, attributed it to North Korea's Lazarus Group, specifically the UNC4736 sub-group, which Mandiant had previously linked to the Radiant Capital attack in October 2024. The attackers spent about six months planning this operation. Social engineering began at industry conferences in the fall of 2025, while on-chain preparations only started three weeks before the incident.

On March 11, 2026, the operation was initiated with a transaction of 10 ETH proposed by Tornado Cash. The next day, around 9:00 AM Pyongyang time, these funds were used to deploy the CarbonVote Token (CVT) on Solana. The attackers created a small liquidity pool on Raydium, conducting wash trades to anchor the market price around $1, and then set up a price oracle they controlled to feed this artificial price to Drift. The existence of wash trades was to make the oracle's output "look legitimate"—anyone checking would find that the market price matched the oracle's quote.

Meanwhile, the attackers disguised themselves as a quantitative trading firm, spending weeks building relationships with Drift contributors. The goal was not to extract information but to accumulate trust for a specific moment.

That moment relied on a feature of Solana 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 members of Drift's five-person Security Council. From the signers' perspective, they were approving routine transactions. From the network's perspective, these signatures were valid authorization credentials, dormant but effective.

On March 26, Drift made a disastrous decision in hindsight: migrating to a brand new 2-of-5 Security Council multisig with a zero timelock. This migration eliminated the delay window that could have detected or intervened in the attack.

On April 1 at 16:05:18 UTC, the attacker submitted the first pre-signed durable nonce transaction—a proposal to transfer administrative control to the address H7PiGqqUaanBovwKgEtreJbKmQe6dbq6VTrw6guy7ZgL. One second later, at 16:05:19 UTC, the second pre-signed transaction approved and executed it. The attacker took control of Drift.

What followed took only twelve minutes. The attacker listed the worthless CVT as collateral, with nearly unlimited borrowing capacity, deposited 500 million CVT at the manipulated oracle price, and then withdrew $285 million in real assets from three core Vaults—JLP, USDC, SOL, cbBTC, wBTC, ETH. Drift's TVL collapsed from $550 million to about $250 million. Two signers, one protocol, and the smart contract worked entirely as designed. The vulnerability lay with "people."

One aspect of Drift's post-incident response is worth noting, as it relates to the standards future victim protocols should aim for: Drift's own post-incident disclosure was unusually candid.

Within five days of the vulnerability's exposure, the team released a detailed review of the social engineering attack—including the following facts: contributors were contacted multiple times over six months; two of the contributors may have been compromised through a cloned code repository and a TestFlight wallet beta; chats with the attackers on Telegram were deleted before and after the attack; the decision to migrate to a zero timelock multisig six days before the incident eliminated the last detection window. The team also publicly shared the attribution of the attack (UNC4736 / Citrine Sleet) with moderate confidence, coordinated with SEAL 911, and shared operational details that could help other protocols identify the same tactics. Victim protocols often retreat into legal caution and vague wording; Drift chose to publish a narrative that could turn a single incident into industry-wide threat intelligence, with a forensic quality. 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 what distinguishes protocols that contribute to collective learning in the industry from those that silently absorb losses. KelpDAO: Single Validator ($292 million) Seventeen days later, on April 18, a similar threat actor profile produced a structurally completely different attack. KelpDAO is a liquidity re-staking protocol that issues rsETH—tokens representing user deposits routed through EigenLayer for additional yield. By April 2026, rsETH's TVL had exceeded $1 billion and was deployed across more than 20 chains using LayerZero's OFT (Omnichain Fungible Token) standard.

The contract had no issues. The configuration had problems.

KelpDAO's cross-chain bridge operated on a 1-of-1 DVN (Decentralized Verifier Network)—meaning there was only one validator. A single node was sufficient to approve a cross-chain message. "Decentralization" is a term, not an architecture.

The attack was conducted in phases. The attacker first compromised the internal RPC node that the validator relied on to read the source chain state, then launched a coordinated DDoS attack on external nodes, forcing the system to revert to compromised infrastructure. After gaining control of the data source, they forged a cross-chain message instructing KelpDAO's Ethereum mainnet contract to mint rsETH based on a "destruction that never occurred on any source chain."

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

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

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

What followed was a public dispute: where does the responsibility lie? LayerZero's initial post-incident report placed the blame squarely on Kelp, arguing that Kelp violated guidelines by choosing a 1-of-1 DVN. Kelp's rebuttal memo on May 5 painted a different picture: at the time, 47% of active LayerZero OApp contracts—about 1,250 applications with a total 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 shipped with LayerZero Labs' DVN as the required validator, and there was no second one; they also presented Telegram screenshots from LayerZero staff, who told the Kelp team "using default values is fine" during eight integration discussions over two and a half years. Security researcher Sujith Somraaj (a former LayerZero auditor) had previously submitted a bug bounty report to Immunefi that precisely described this attack pattern, which LayerZero rejected on the grounds that "validator network selection is an application layer configuration."

LayerZero's response to Kelp's memo was that this statement was misleading. The bug bounty excluded "application layer configuration" as a standard "platform/application" boundary (a LayerZero spokesperson pointed out that otherwise "any application could set itself as the only DVN and maliciously collect rewards"); the protocol's default value was actually multi-DVN in almost all paths; as for those templates that resulted in 1-of-1, the unique DVN pointed to a placeholder contract called "DeadDVN," which would reject all messages, forcing developers to configure their security stack before going live. Regarding Kelp, LayerZero stated that Kelp initially deployed a multi-DVN and later manually downgraded to 1-of-1—not "using default values." The boundary between platform and application is indeed a real point of contention, and rational engineers may disagree on the question of whether a platform that can be configured into a dangerous state should be held accountable for the configurations actually deployed by users.

What is less contentious is the second part of LayerZero's final response. On May 8, three weeks after the first 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 did not constrain our DVN in terms of what it was providing protection for." The protocol stopped supporting 1-of-1 in the DVN system, migrated the default value to 5-of-5, raised its multisig 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 joint failure between a platform that could be configured into a dangerous state from the outset and an integrator that actively downgraded, both parties ultimately converged on the same answer: 1-of-1 validation is not safe at scale, and the industry should not have learned this lesson at the cost of $292 million. Wasabi: Administrator Private Key ($4.5 million) The Wasabi incident on April 30 was an order of magnitude smaller than the other two, making it all the more embarrassing. It was a "boring hack."

A deployer EOA—address 0x5c629f8c0b5368f523c85bfe79d2a8efb64fb0c8—held ADMIN_ROLE in Wasabi's perpetual contract managers deployed on Ethereum, Base, Blast, and Bera chains. There was no multisig. The contract framework originally supported timelock, but the configuration value was zero.

The attacker obtained that private key—phishing, device intrusion, supply chain attacks are all possibilities, but Wasabi did not provide a final conclusion. With ADMIN_ROLE, they granted the same role to a malicious auxiliary contract, performed a UUPS proxy upgrade on the Vault contract, and swept away collateral and pool balances. The total cross-chain loss was $4.5 to $5.5 million.

Wasabi did not employ any new technology. This type of vulnerability has been warned against as a DeFi anti-pattern for many years: excessive concentration of management authority, lack of power separation, and no delay window. This is the same vulnerability that DeFi has been facing and writing post-incident reports about since 2020, yet has never corrected in practice.

Connecting the three incidents: ultimately, they are the same type of hack. Whether privileged access was obtained through manipulating signers, compromising validation nodes, or stealing deployer private keys, the attack surface is the same—concentration of power outside the smart contract layer, with insufficient protection. This pattern also serves as a warning: in each incident, one or two compromised entities triggered a domino chain that Solidity hardening could not prevent.

III. Asymmetric Dominoes

The significance of the KelpDAO incident extends beyond its dollar amount because of what happened afterward—this was the first true stress test of DeFi composability under operational failure—while also being the most illustrative case of "how absurdly asymmetric contagion mathematics can be."

To clarify the scale: at the time of the incident, KelpDAO's rsETH TVL was about $1 billion; Aave's AUM across all chains exceeded $25 billion. A protocol roughly only 4% the size of Aave, through a single incident, withdrew $8.45 billion from Aave within 48 hours—this figure 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. Asymmetry is the real story. A small protocol with a misconfigured cross-chain bridge triggered a bank run on a much larger protocol that was "operating as intended" by all its own contract metrics.

When the attacker minted unsupported rsETH and deposited it into Aave, Aave's contracts were executing according to specifications. Its oracle still read rsETH as close to 1:1 during the brief window when the attacker borrowed. The lending pool released real WETH, targeting collateral that appeared "valid" to all on-chain systems.

The market reaction was immediate. rsETH traded at a deep discount on DEXs within hours, reflecting a real uncertainty—whether the remaining 82% of the supply was still fully backed. 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). Holders of rsETH on Arbitrum, Base, Mantle, Linea, Blast, and Scroll could no longer be sure that their tokens could be redeemed 1:1 for Ethereum mainnet custody.

The subsequent outflow was not because Aave was hacked, but because depositors could not ascertain whether the collateral backing their loans still had repayment capability. In the weeks leading up to the incident, Aave had accumulated a significant position in rsETH, as users leveraged for re-staking trades; the protocol earned fees from this exposure without placing a cap on it. Thus, this contagion was not purely a "bystander logic"—Aave itself chose to bear counterparty risk—but the triggering event lay outside its own contracts and beyond its governance's discernible scope.

Aave's response to this incident is worth noting separately, as it set a standard that could be measured against other large lending protocols. Within hours of the incident's exposure, the protocol's emergency administrator froze the rsETH market across all affected chains on V3 and V4, setting LTV to zero, thereby sealing off further losses. Within 48 hours, Aave's service provider published a detailed incident report in the governance forum, openly modeling two different bad debt scenarios—if Kelp socialized the losses among all rsETH holders, the bad debt would be $123.7 million; if the losses were isolated to the L2 deployment, it would be $230.1 million—along with a breakdown by chain, indicating which markets would bear which gaps.

Aave founder Stani Kulechov personally committed 5,000 ETH for recovery; a DeFi United coalition led by Aave's service provider—bringing in Lido, EtherFi, LayerZero, Mantle, and others—raised over $300 million in commitments to fill the rsETH gap. This was the largest cross-protocol rescue in the industry to date.

The critical part is narrower and should be viewed separately from the response: Aave's stance drifted as the bad debt range became clearer. Initially promising that its Umbrella reserves would cover the gap, it was softened within days to "exploring paths to fill the gap." The narrative shift is subtle but noteworthy—what sounds definitive in abstract contexts as protocol-level insurance becomes negotiable once the numbers are specific. Aave handled the operational aspects well, but this does not change the structural fact: depositors putting USDC into the protocol bore counterparty risk for a token they might not even know existed, and the protocol's insurance mechanism ultimately had far weaker binding power than implied in the documentation.

This is the deeper structural issue. The single-pool design that gives Aave deep liquidity and a streamlined experience also means that a poorly listed collateral can create an explosive radius at the entire protocol level. Even if Aave's governance is diligent and its contracts robust, the protocol remains downstream of a much smaller counterparty's security failure—one that is sufficient to pressure nine-digit depositor funds and trigger market freezes across nine protocols.

The composability that supports DeFi growth is also its contagion transmission channel; April 2026 was the first time this bill was settled on a large scale. The legal amendments are not obvious. What once drove DeFi growth through composability has now become a conduit for "how the operational failure of one protocol can turn into a bank run on another."

IV. The Truth of OpenFi

We have arrived at a conversation the industry has long avoided.

Let’s call it OpenFi: permissionless access, on-chain auditable, but at the critical juncture of "the original decentralization argument should remove intermediaries," it still relies on trusted third-party financial infrastructure for operations. By this definition, most things marketed today under the name DeFi are OpenFi. A Security Council with the power to transfer administrative control. A cross-chain bridge with only a 1-of-1 validator. A deployer EOA with cross-chain ADMIN_ROLE. A governance token concentrated enough for a patient minority to capture the treasury, like Nouns. Each is a "privileged seam" patched into a supposedly seamless system.

It is worth recalling what the original arguments actually said. Szabo's "trust-minimized" calculus, Buterin's "trustworthy neutrality" infrastructure, the Cypherpunk insistence that "privacy and freedom require the removal of rather than the auditing of intermediaries"—none of these are about "transparency." Transparency is necessary and easy. The truly difficult claim—the one that can bear all the friction of "running a global state machine on tens of thousands of redundant nodes"—is "no party in the system can be coerced, captured, bribed, or hacked to change the rules." An open ledger you can examine but cannot influence is a different thing from an open ledger with an administrator's private key lying in someone's safe hardware wallet. OpenFi has preserved the first half of this transaction while quietly discarding the second half.

Different protocols rely on different types of trust, and their failure modes vary. Naming them one by one is useful: custodial trust (someone holds real assets for you, and you trade on the right to claim them—cross-chain bridges, wrapped tokens); upgrade trust (someone can change contract behavior after you deposit—proxy administrators, Security Council); oracle trust (someone provides data that the contract itself cannot generate—price feeds); active trust (the system's normal operation relies on someone continuously operating—sorters, relayers, keepers); governance trust (token holders, or that small portion who can muster a quorum in contentious votes). Most protocols rely on three to four of these simultaneously. Most marketing copy collapses all of them into the term "decentralization," leaving readers to guess the rest.

The larger issue is that some of these assumptions are completely hidden. LayerZero admitted in its May apology that three and a half years ago, one of its multisig signers had made a personal transaction using a production hardware wallet. This mistake was internally fixed but never disclosed to users, surfacing later as part of a fortification announcement, packaged as a routine adjustment rather than a confession. Users of the trust system had no way of knowing this, nor any way to price the risk of "it really happened."

The industry has a euphemistic term for this gap: "training wheels." The selling point is that the administrator private key and Security Council are transitional—existing today, to be removed once the protocol matures enough to walk independently. In practice, training wheels are almost never taken off. They are renamed, repackaged, renewed, or quietly transferred to a foundation. The L2Beat Stage 0 / Stage 1 / Stage 2 framework is the cleanest exception, serving as proof of existence that "this industry can candidly describe its actual trust assumptions if it wants to." Almost no protocol adopts L2Beat-style expressions in its marketing, which itself is evidence that "dishonesty is structural, not incidental."

This is the engineering reality, shaped by the incentives builders actually face at every layer. If you want to quickly launch complex products, respond to vulnerabilities without forking the protocol, support new collateral types, and integrate with other parts of the ecosystem, you need operational leverage. Completely immutable contracts with no privileged access are indeed robust, but also brittle—any change requires a full migration, any vulnerability becomes permanent, and any new feature requires users to re-choose to join a new deployment. Beyond technical factors, there is a layer of reality: VC timelines do not allow for three years of formal verification cycles; protocols that launch first get liquidity.

Composability amplifies the problem: an immutable protocol cannot access new oracles, cannot support new chains, cannot patch known vulnerabilities unless it forces all users and integrators to migrate. The result is that for any single team, the rational choice is to "launch with an administrator private key, promising to remove it in the future"; for any single user, the rational choice is to accept this trade-off because alternative protocols either do not exist or lack liquidity. OpenFi is not a moral failure of individual builders. It is the Nash equilibrium of the field.

An honest statement is: DeFi has almost universally chosen to exchange a portion of decentralization for operational feasibility. This choice is defensible. The dishonesty lies in not naming the trade-offs and continuing to market protocols as "decentralized," while their actual security models rely on a few signers, a single validator, or a multisig that can be compromised by social engineering.

The way forward is closer to "disclosure" than "revolution": mandating trust assumption labeling according to the L2Beat model; allowing sufficient time delays for users to exit before privileged operations are completed; pricing "operational risk" rather than fictitious "pure code risk" in insurance markets; and making a clear distinction between "which parts of the system truly need upgrade paths" and "which parts are merely set to be variable due to architectural habits." April 2026 did not prove OpenFi unfeasible. It proved that marketing an OpenFi system as DeFi leaves its users unprepared for its actual failure modes. To make such systems secure, the first step is to honestly acknowledge that this is what we are building.

V. The Duality of Centralization

The core trade-off of OpenFi became visibly apparent in the Arbitrum freeze incident. Three days after the KelpDAO vulnerability was exploited, Arbitrum's Security Council voted to freeze 30,766 ETH that the attacker had transferred to Arbitrum One—about $71 million. The freeze was coordinated with law enforcement and is seen as a good outcome by most standards: stolen funds were prevented from being laundered, the attacker's downstream channels were closed, and some user losses might even be recoverable.

But note what made this freeze possible: Arbitrum has a Security Council with the authority to "reach into the chain to transfer funds." This is not a characteristic of decentralized infrastructure. It is a centralized kill switch that exists by design—defensible under the rationale of "emergency response," used in the way critics have long feared—not necessarily bad, but certainly consequential.

The same type of mechanism that allowed Arbitrum to play the "good guy" after the Kelp incident is also the same form of mechanism that led to Drift being compromised—a small number of trusted signers wielding the power to execute protocol-level operations, differing only in "how strongly this power is constrained." Once, this power was legitimately used to freeze stolen funds; another time, it was hijacked through social engineering to drain user deposits. Leverage can cut both ways.

The "kill switch" has failed through at least five different channels—social engineering (Ronin, Drift), insider breaches (Multichain), sovereign coercion, legal enforcement (Tornado Cash, USDC), and governance hijacking (Beanstalk, Mango Markets). Each is a different attack with different defenses; saying "the Council failed" obscures everything. Pointing out specific failure channels is the first step toward defending against them.

This is the "dual nature of centralization" in DeFi, and it is the most important thing about the current state of the industry: every operational leverage that can bring about a "good outcome" in emergencies is also an attack surface—it can lead to bad outcomes in another incident.

The deeper question is: in the case of Arbitrum, the term "good outcome" carries too much weight. Legitimacy is socially constructed, and the same form of leverage has been pulled under consensus that is far from clean. The 2016 DAO fork on Ethereum remains a classic case: half the community insisted that reversing that $60 million vulnerability was the most obvious and legitimate use of social consensus; the other half insisted it was a fatal betrayal of "code is law," forking off to let the original chain continue as Ethereum Classic.

Circle and Tether frequently freeze USDC and USDT addresses, sometimes in response to OFAC sanctions, sometimes acting solely on suspicion, with affected users having no recourse—freezing is packaged as compliance but is essentially discretionary. Arbitrum's freeze worked. The DAO fork, in a sense, also worked. USDC freezing is effective on a daily basis. The honest question is not "can the kill switch produce good outcomes," but "who decides what constitutes a good outcome"—and what the protocol's users have been informed about this decision-making process.

No version of the trade-off can "take one without the other." You either have a kill switch, in which case you have something that can be captured, manipulated, or social engineered; or you do not, in which case you must accept that some incidents will be permanent and irreversible.

These levers are also not interchangeable. Arbitrum's Security Council can rapidly transfer funds through emergency processes at a low threshold—combining "speed + scope" makes freezing possible, but the same combination also makes the failure mode catastrophic when the Council itself is compromised.

THORChain's leverage is narrower: it can pause and recapitalize through RUNE issuance but has no authority to seize or redirect user assets. Aave's emergency administrator can freeze markets 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 referred to as "kill switches." A protocol that is willing to honestly address its own trust model owes its users not a category but a specific form.

The industry also tends to avoid another distinction: the difference between "leverage used only in extreme circumstances" and "leverage that operates in regular rhythms."

Both Bitcoin and Ethereum fundamentally have kill switches—nodes, miners, validators, and exchanges can coordinate to fork any chain at a sufficient level. These two chains are still viewed as trust-minimized because this lever has almost never been pulled; the cost of pulling it is a permanent community split. The DAO fork has been a contentious event in Ethereum's history for the past decade. Bitcoin has never experienced a similar fork. The existence of leverage, but its credible commitment to "stay put" in regular affairs, is precisely this long history of restraint that gives the underlying system a reliability that no single design feature can confer.

In contrast, Arbitrum's Security Council operates in regular rhythms. It votes regularly on upgrades. It had executed emergency actions before the Kelp freeze and will execute more afterward. It is not a dormant reserve capability but an active governance body. OpenFi criticism applies much more forcefully to "active leverage" than to "dormant leverage," because the restraint of dormant leverage itself is a signal—trust earned by operators with extremely high usage thresholds is something that leverage itself cannot grant. Active leverage lacks this signal. They can only assess based on their own controls, which have been repeatedly proven insufficient.

THORChain faced criticism for taking a "no leverage" route after experiencing a vulnerability in 2021. Arbitrum took the "kill switch" route and received praise. Both choices are defensible. Neither is free. The industry must stop pretending that both can be had—and must honestly inform users of what each specific protocol has actually traded off.

The final twist: this trade-off will only worsen over time. Once a protocol can freeze, regulators and courts become increasingly inclined to rule that it "must" freeze. The freezing capability of USDC began as an emergency compliance tool but has now become a de facto response to OFAC notifications and an ever-expanding list of state-level enforcement actions. The decision to "launch with a kill 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 may not align with the direction supported by the protocol's own community. THORChain's "no leverage" stance is therefore not only an engineering choice but also a regulatory posture—it preemptively excludes "the possibility of compliance," thus preemptively excluding "the