The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis

On April 18, 2026, KelpDAO's rsETH cross-chain bridge was exploited for approximately $290 million, making it the largest DeFi security incident of the year. Preliminary attribution points to the Lazarus Group, a state-sponsored threat actor with a well-documented history of targeting crypto infrastructure [1]. The attack did not exploit a smart contract vulnerability. Instead, it poisoned the RPC infrastructure underlying a single Decentralized Verifier Network (DVN) node, forging cross-chain messages that released rsETH tokens with no corresponding source-chain burn.

The exploit itself has been covered in detail by LayerZero [1] and KelpDAO [2]. This article takes a different angle. Rather than replaying the attack, we examine what happened after the exploit: how a single-point infrastructure dependency enabled a cascade that froze billions in liquidity across five chains, and how that cascade forced decentralized governance frameworks to exercise centralized emergency powers in full public view.

The KelpDAO incident traces a causal chain that runs through three layers of the "decentralized" stack: a single-point DVN dependency made the exploit possible; DeFi's composability (also known as "DeFi Lego"), the property that lets protocols plug into each other like building blocks, then turned that bridge exploit into a system-wide liquidity crisis; and the scale of the crisis in turn forced governance frameworks to reveal the centralized emergency powers embedded within them.

Background: The KelpDAO Exploit in Brief

KelpDAO is the issuer of rsETH, a liquid restaking token (LRT) that represents staked ETH positions across multiple operators. To enable cross-chain movement of rsETH, KelpDAO integrated with LayerZero's messaging protocol, which relies on DVNs, independent verifiers that confirm cross-chain messages are legitimate before they are executed on the destination chain.

The critical configuration choice: KelpDAO's rsETH OApp used a 1-of-1 DVN setup, with the LayerZero Labs-operated DVN as the sole verifier. This meant the entire cross-chain security of rsETH depended on a single verification entity. LayerZero's integration documentation explicitly recommends multi-DVN configurations with redundancy, and LayerZero states it communicated this best practice to KelpDAO prior to the incident [1]. KelpDAO, for its part, maintains that the 1/1 setup was "the configuration documented in LayerZero's documentation and shipped as the default for any new OFT deployment," and that "defaults were affirmatively confirmed as appropriate" during their L2 expansion [2].

The attackers compromised two RPC nodes used by the LayerZero Labs DVN, replacing their binaries with malicious versions that returned forged chain state data exclusively to the DVN's IP address while appearing normal to all other observers, including LayerZero's own monitoring infrastructure. A simultaneous DDoS attack against uncompromised RPC nodes forced failover to the poisoned nodes. The result: the DVN confirmed a cross-chain message that never occurred on the source chain, releasing 116,500 rsETH from the Ethereum-side adapter (0x85d4...8ef3) with no corresponding source-side burn [1, 3]. The release transaction is 0x1ae232...db4222. The on-chain evidence is unambiguous: the Ethereum destination endpoint accepted nonce 308, while the Unichain source endpoint still reports a maximum outbound nonce of 307 [10].

KelpDAO detected the anomaly and paused all relevant contracts within 46 minutes. This intervention blocked a subsequent attempt targeting an additional 40,000 rsETH (~$95M) [2]. But by that point, the attacker had already moved to the next stage: converting stolen rsETH into borrowed assets through DeFi lending protocols.

From Forged Tokens to Borrowed Assets

The attacker did not simply sell the stolen rsETH. The 116,500 tokens were dispersed across seven branch wallets and monetized through multiple channels, including direct swaps to ETH via aggregators, Compound V3 supply positions, and re-bridging to Arbitrum [10]. But the most consequential path ran through Aave: the attacker deposited 89,567 rsETH (approximately $221 million) into Aave lending markets across two chains: Ethereum Core and Arbitrum. Using Aave's E-Mode, a capital-efficiency feature that allows higher loan-to-value ratios for correlated assets, the attacker borrowed 82,620 WETH and 821 wstETH against the deposited rsETH [3].

The positions were leveraged to the maximum. Health factors across the attacker's seven addresses ranged from 1.01 to 1.03, barely above the liquidation threshold [3]. This was possible because Aave's E-Mode LTV for rsETH was set at 93%, with a liquidation threshold of 95%, leaving a safety buffer of just 2 percentage points.

The per-address breakdown across both markets:

Source: on-chain data aggregated from Etherscan, Arbiscan, and DeBank as of 2026-04-22 16:51 UTC. USD values reflect token prices at the time of each transaction.

The Cascade: How a Bridge Exploit Froze WETH Across Five Chains

The figure below summarizes the full cascade. Steps 1 and 2 (the bridge exploit and Aave collateral deposit) are covered in the Background section above. The rest of this section examines steps 3 through 5 in detail: why WETH had to be frozen, what parameters shaped the cascade's severity, and what the freeze actually cost.

Why WETH Had to Be Frozen

On April 19, Aave's Protocol Guardian froze all rsETH and wrsETH markets across Aave V3 and V4, preventing new deposits and borrows against rsETH collateral [8]. This was the expected first response.

The unexpected second step came on April 20: Aave froze WETH reserves across Ethereum, Arbitrum, Base, Mantle, and Linea [3, 8].

Why freeze WETH, an asset that was not exploited and has nothing to do with cross-chain bridges? Because the attacker had deposited rsETH that was minted without any corresponding source-chain backing. Aave's oracle continued to price these tokens at full market value, treating them as legitimate collateral indistinguishable from properly bridged rsETH. The attacker exploited this information asymmetry to borrow real WETH against collateral that, at the system level, represented unbacked liabilities. This drained WETH from lending pools, pushing utilization to 100% across affected markets. At full utilization, existing WETH depositors cannot withdraw, and liquidators cannot receive the underlying asset needed to execute liquidations. The liquidation mechanism, the protocol's primary defense against bad debt, was effectively paralyzed [3].

If WETH borrowing remained open, the remaining pool liquidity on other chains could be drained through the same mechanism: deposit rsETH, borrow WETH, walk away. Freezing WETH was not optional. It was the only way to cap the damage.

Three Parameters That Shaped the Cascade

The severity of this cascade was not accidental. Three protocol parameters determined both the direct damage and the scope of the resulting freeze.

1. LTV: How much healthy asset each unit of polluted collateral can extract

Aave's E-Mode LTV for rsETH was 93%, meaning every dollar of polluted rsETH deposited could borrow $0.93 of WETH. For context, Spark Protocol set rsETH LTV at 72% during the same period, and Fluid at approximately 75% [3]. Aave's parameter was the most aggressive in the market.

This was a deliberate design decision, not an oversight. In January 2026, Aave governance raised the E-Mode LTV for rsETH from 92.5% to 93%, further compressing the already thin safety buffer from 2.5% to 2% [3]. The base (non-E-Mode) LTV was intentionally set near zero (0.05%), effectively forcing all meaningful rsETH borrowing through the high-LTV E-Mode path.

2. Pool depth: How vulnerable each market is to liquidity drainage

The same dollar amount of borrowing has vastly different impacts depending on the depth of the target pool.

The attacker deposited rsETH into Aave V3 markets only. Aave V4 (Ethereum only, launched 2026-03-30) was also subject to the precautionary rsETH freeze [8] but is not reflected in this table. WETH reserve data from LlamaRisk [3]; attacker borrowing derived from the per-address breakdown above.

The attacker concentrated borrowing on Ethereum Core and Arbitrum. But the critical observation is what happened to chains the attacker never touched. Because rsETH was accepted as collateral on Mantle, Base, and Linea, any existing user positions backed by rsETH on those chains carried latent bad-debt risk once the underlying bridge backing was compromised. Aave's decision to preventively freeze WETH across all five chains was a rational response: leaving these markets open would have exposed them to the same drain mechanism the attacker had already demonstrated on Ethereum and Arbitrum [3, 8].

3. Cross-chain deployment count: How far the freeze propagates

rsETH was listed as collateral on 11 out of 23 Aave V3 markets, with 7 showing material exposure [3]. The attacker operated on just 2 chains. But the precautionary WETH freeze hit at least 5 chains, including markets where the attacker never deposited a single token. LTV governs how much is extracted per chain; pool depth determines how severely each market is strained. But it is the number of chains where rsETH was accepted as collateral that ultimately decided how far the freeze propagated.

These parameters are not static. Nine days before the exploit, on April 9, Aave's Risk Steward raised rsETH supply caps: Ethereum Core from 480,000 to 530,000, and Mantle from 52,000 to 70,000 [3]. While this does not imply causation (the attacker's preparation timeline likely predates these changes), it underscores how routine parameter adjustments can inadvertently widen the blast radius of a future incident.

The Real Impact of the Freeze

The result: a $290M bridge exploit led to WETH liquidity freezes across five chains, affecting markets with combined reserves exceeding $6.7 billion.

The direct losses were limited to the attacker's borrowing. But in DeFi lending, a freeze is not a minor operational inconvenience. It locks user liquidity, prevents withdrawals, disrupts active positions, and impairs the liquidation mechanisms that protect the protocol from bad debt. The vast majority of users affected had never interacted with rsETH, KelpDAO, or any cross-chain bridge. They were WETH depositors and borrowers on Aave, participants in what they reasonably understood to be a straightforward lending market.

WETH is DeFi's most fundamental liquidity asset. Freezing it is the equivalent of shutting down withdrawals at the largest bank in town because a different financial institution, using a product most depositors have never heard of, was defrauded.

LlamaRisk's incident report [3] modeled two bad-debt scenarios with per-chain shortfall projections, providing the most detailed risk propagation analysis available. But even this analysis focused on potential bad debt, not the broader operational costs of the freeze itself, including locked withdrawals, disrupted positions, and impaired liquidation capacity across all affected markets. A comprehensive quantification of the total cascading impact remains an open problem.

If the attack cascade was complex, the recovery has proven no simpler. Composability constrains repair just as it enables damage. Aave could not simply "unfreeze everything." Each market had to be assessed independently, with different risk profiles depending on local rsETH exposure, WETH utilization levels, and attacker activity. The timeline tells the story:

• April 19: Protocol Guardian froze all rsETH and wrsETH reserves across Aave V3 and V4 [8].
• April 20: WETH frozen across Ethereum, Arbitrum, Base, Mantle, and Linea [3, 8].
• April 21: WETH unfrozen on Ethereum Core V3 only, with LTV remaining at 0 as a precautionary measure. WETH on Ethereum Prime, Arbitrum, Base, Mantle, and Linea remained frozen [8].

Four days after the exploit, five out of six affected markets remain frozen. The recovery path mirrors the attack path in complexity: protocol by protocol, chain by chain, with each step requiring governance coordination and risk assessment.

The Response: How Arbitrum Moved 30,766 ETH Without the Holder's Signature

While Aave was managing the lending cascade, a parallel response was unfolding on Arbitrum. On April 21, the Arbitrum Security Council announced it had taken emergency action to freeze 30,766 ETH held by the exploiter on Arbitrum One [6]. The funds were transferred to an intermediary frozen address (0x...0DA0), accessible only through subsequent Arbitrum governance action [7].

The Governance Action

The Arbitrum Security Council is a formal component of Arbitrum's DAO governance structure, not an external actor or an ad hoc committee. The emergency action was announced publicly through the Arbitrum governance forum [7], executed with input from law enforcement regarding the exploiter's identity [6], and documented with full transaction details. The Security Council acted within its established mandate, weighing "its commitment to the security and integrity of the Arbitrum community without impacting any Arbitrum users or applications" [6].

This was not a back-room decision. It was a governance-sanctioned emergency action, executed transparently, with on-chain evidence for anyone to verify.

The Technical Mechanism

What makes this action remarkable is not the governance decision, but how it was executed on-chain. Based on BlockSec's Phalcon trace analysis [9], the Security Council employed an atomic three-step approach:

1. The Upgrade Executor temporarily upgraded the Ethereum inbox contract (DelayedInbox), adding a new function called sendUnsignedTransactionOverride.

2. This function was used to create a cross-chain message impersonating the exploiter's address. The message was injected via Bridge.enqueueDelayedMessage with kind=3, which maps to L1MessageType_L2Message in Arbitrum's Nitro stack. This message type allows L2MessageKind_UnsignedUserTx execution on L2. Critically, this path does not require a signature check. The sender parameter was shifted from the standard msg.sender path to a caller-controlled input, transformed through L1→L2 address aliasing to carry the exploiter's address context.

3. After the transfer executed on L2, the inbox contract was restored to its original implementation.

The L1 transaction [4] and the resulting L2 transaction [5] are both publicly viewable on Phalcon Explorer. What the L2 transaction shows as "from exploiter to 0x...0DA0" is not a standard user-signed transfer. It is a chain-level forced state transition, a transaction that moved assets without the owner's private key, executed through governance-level infrastructure upgrade powers.

The Dilemma

The mechanism is straightforward in principle: upgradeable contracts grant unlimited capability. If a contract can be upgraded, its behavior can be changed to do anything, including transferring assets without the holder's signature. This capability is inherent to any system built on upgradeable contracts. The 30,766 ETH now sits in a frozen address. Only a subsequent Arbitrum governance vote can determine its disposition. The atomic upgrade-execute-restore pattern left no permanent change to the inbox contract, and no other users or applications were affected [6].

The Arbitrum Security Council's action was, by most reasonable assessments, the right call. The exploiter was identified as a state-sponsored actor. Law enforcement was involved. The governance process was public. And $71 million in stolen assets were recovered, or at least prevented from being laundered further.

But the capability that made this possible extends beyond this specific case. The same upgrade-execute-restore mechanism could, in principle, be used to move any asset held by any address on Arbitrum One. The Security Council's power is not limited to exploiter addresses or stolen funds. It is a general-purpose capability constrained by governance norms, not by code.

This is the dilemma. Users interact with L2s under an implicit mental model: "my assets are controlled by my private key, and no one can move them without my signature." The KelpDAO response demonstrates that this model is incomplete. On Arbitrum, and on any L2 with upgradeable bridge contracts and a Security Council, assets can be moved through governance-level actions that bypass signature checks entirely.

Arbitrum is not unique in this regard. Aave's market freezes are also governance-driven emergency actions. During the KelpDAO incident, multiple protocols exercised centralized emergency powers simultaneously: Aave froze markets across five chains, Arbitrum's Security Council executed a forced transfer, and KelpDAO paused contracts globally. The "decentralized" ecosystem's crisis response was, in practice, a coordinated exercise of centralized authority.

The question is not whether emergency powers should exist. The KelpDAO case makes a compelling argument that they should. The question is whether the boundaries, trigger conditions, and accountability mechanisms for these powers are sufficiently transparent. Users who deposit assets on an L2 should be able to answer a basic question: under what circumstances can the Security Council move my funds, and what recourse do I have?

Current Status of Stolen Funds

Independent on-chain tracing (full visualization on MetaSleuth [11]) shows the attacker fanning the 116,500 rsETH across seven first-hop addresses, supplying most of it as collateral on Aave (Ethereum Core and Arbitrum) to borrow WETH and wstETH, and consolidating the proceeds into a shared address 0x5d39...7ccc on both chains (Ethereum / Arbitrum). As of 2026-04-22 05:42 UTC, the stolen funds sit in four distinct states:

Approximately 31% of the proceeds are frozen or intercepted, 23% remain idle in a single dormant Ethereum address, and 46% have been dispersed, or are currently being dispersed, across 103 first-hop addresses. The rsETH posted as Aave collateral remains deposited, and the borrowed WETH and wstETH have not been repaid — the attacker has abandoned the lending position.

Conclusion

The KelpDAO incident traces a causal chain that runs through three layers of the "decentralized" stack.

It began with a single-point dependency. KelpDAO's 1-of-1 DVN configuration reduced cross-chain verification to a single entity, making the entire bridge exploitable through one compromised infrastructure component. The architecture supported decentralization; the configuration did not.

Composability then turned a bridge exploit into a system-wide liquidity crisis. A single attack froze WETH, DeFi's most fundamental asset, across five chains, affecting billions of dollars in liquidity held by users with no connection to rsETH or KelpDAO. The cascade's reach was shaped by measurable parameters: aggressive LTV settings, shallow liquidity pools, and broad cross-chain collateral deployment.

The scale of the crisis, in turn, forced decentralized governance to exercise centralized emergency powers. Arbitrum's Security Council moved 30,766 ETH without the holder's signature through a governance-sanctioned atomic contract upgrade. Aave froze markets across multiple chains through governance-driven emergency actions. The response was effective, transparent, and arguably necessary. It was also a demonstration that "permissionless" has practical boundaries.

Single-point dependency enabled the exploit; composability amplified the damage; the damage revealed the centralized power that was always there, embedded in upgradeable contracts and governance frameworks. Addressing these linked dynamics requires action from all participants:

For protocols: A protocol's overall security is determined by its weakest link, which in this case was the DVN infrastructure rather than the smart contracts [10]. Effective security requires systematic coverage across multiple dimensions, including code security, infrastructure security, key management, and operational security. Comprehensive assessments and penetration testing should stress-test the full stack, not individual components in isolation. On-chain monitoring enables emergency responses within minutes rather than hours, and rapid cross-chain fund tracing is essential for coordinating asset freezes and maximizing recovery. For lending protocols specifically, collateral from cross-chain synthetic assets should be stress-tested against a "total collateral compromise" scenario across the three parameters discussed above: LTV, pool depth, and cross-chain deployment count.

For L2 governance and DAOs: Emergency powers should be transparent and accountable. Most major L2s already have these capabilities, but they are often buried in technical documentation rather than surfaced in user-facing materials. Governance frameworks should codify trigger conditions, scope limitations, time constraints, and post-action accountability requirements.

For users: Understand the systemic risk inherent in DeFi composability. In this incident, WETH depositors who never touched rsETH had their liquidity frozen across five chains. Individual position risk is only part of the picture; the protocols, pools, collateral types, and chains your assets interact with all form an interconnected risk surface.

References

[1] LayerZero Core, "KelpDAO Incident Statement": https://x.com/LayerZero_Core/status/2046081551574983137

[2] KelpDAO, "April 18 Incident: Additional Context": https://x.com/KelpDAO/status/2046332070277091807

[3] LlamaRisk, "rsETH Incident Report" (April 20, 2026): https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580

[4] BlockSec Phalcon Explorer, L1 Transaction (Arbitrum Security Council action): https://app.blocksec.com/phalcon/explorer/tx/eth/0x079984c56c5670108f5c6f664904178f9b364340351949a42e4637d1f645f770

[5] BlockSec Phalcon Explorer, L2 Transaction (Arbitrum forced transfer): https://app.blocksec.com/phalcon/explorer/tx/arbitrum/0x5618044241dade84af6c41b7d84496dc9823700f98b79751e257608dac570f6b

[6] Arbitrum, "Security Council Emergency Action": https://x.com/arbitrum/status/2046435443680346189

[7] Arbitrum Governance Forum, "Security Council Emergency Action 21/04/2026": https://forum.arbitrum.foundation/t/security-council-emergency-action-21-04-2026/30803

[8] Aave, rsETH incident updates (April 19-21, 2026): https://x.com/aave/status/2045593585966252377

[9] BlockSec Phalcon, "Arbitrum Security Council freeze analysis": https://x.com/Phalcon_xyz/status/2046467830498173088

[10] banteg, "Kelp rsETH Unichain → Ethereum Path Investigation": https://gist.github.com/banteg/705d0284513b74ad20f61d90f5b5de62

[11] MetaSleuth, KelpDAO exploit trace: https://metasleuth.io/result/eth/0x1ae232da212c45f35c1525f851e4c41d529bf18af862d9ce9fd40bf709db4222?source=600c61cd-f0cd-4dff-8687-14e02f6ccd24