If Aave's code had no issues at all, why does this incident still fall on Aave rather than being entirely Kelp's fault for its bridge design?
The answer to this question is exactly what makes this incident worth remembering: accountability isn't the same thing as "whose code got exploited." Aave chose to activate e-mode for rsETH and set the LTV at 93% — that was a decision Aave's own governance made, and the review process behind that decision never covered the fact that Kelp's bridge relied on a single verifier. In other words, when Aave's governance approved this collateral's eligibility, it never actually understood what it was approving.
Pinning all the blame on Kelp assumes a lending protocol only needs to answer for its own code, not for which collateral assets it chooses to accept. But a lending protocol's core business is precisely "assessing risk and deciding what to take on" — if that assessment itself is missing, no matter how clean the code is, it can't prevent this category of loss. That's also why separating Kelp's bridge vulnerability from Aave's governance oversight is what lets you actually see the full picture: this is two independent failures stacking on top of each other, not something one party's mistake alone can explain.
Is there a direct causal link between specialized risk providers like Chaos Labs departing and this incident?
Publicly available information shows no direct causal link between Chaos Labs' departure and this incident — there's no evidence that, had they still been in place, they would have necessarily caught Kelp's single-verifier bridge issue in time and blocked the e-mode proposal from passing. After all, the governance proposal activating rsETH e-mode passed in January, and Chaos Labs didn't leave until April 6 — they had over two months in between to intervene and didn't, which suggests that even with the risk provider actively in place, this particular Bridge Risk wasn't necessarily going to be caught.
But what's worth remembering about this incident isn't a simplified causal claim like "the risk provider's departure caused the attack" — it's a more notable timing coincidence: an accountability system originally designed to safeguard risk on users' behalf happened to develop a structural gap at exactly the moment it was needed most. Three independent oversight roles emptying out simultaneously doesn't mean the next attack was guaranteed to happen, but it does mean a layer of protection that should have existed wasn't intact at a critical moment — that state of "a gap existing in the safety net" is itself a risk worth documenting and taking seriously, without needing to prove causation, and is on its own a meaningful signal for assessing a protocol's current governance health.
Morpho and Aave faced the same attack, but their exposure differed by nearly 200x — was that gap entirely down to architecture?
Largely, yes. Aave uses a shared pool architecture — all depositors' funds are pooled together into one large pool, and once any protocol-accepted collateral asset runs into trouble, the Bad Debt is absorbed proportionally across the entire pool. The upside of this design is high capital efficiency and deep market liquidity, but the cost is that risk becomes contagious within the protocol: an asset that has nothing to do with you can still get your funds locked and your borrowing rate spiked.
Morpho uses an isolated vault architecture, where each vault is a separate, siloed market. If a collateral asset accepted in one vault runs into trouble, the loss stays confined to that specific vault and doesn't spread to other, unrelated vaults. In this incident, Morpho happened to have one vault that also accepted the same problematic asset, so it did carry roughly $1 million in exposure — but because of architectural isolation, that loss never touched depositors in any of Morpho's other vaults. This contrast clearly demonstrates that the same collateral risk event can produce actual damage that differs by orders of magnitude depending on the protocol's architecture — architecture itself is a risk-management tool.
I've never touched some problematic asset, but I could still get hurt by other users' losses on the same protocol — how should I assess this risk in advance?
The first step is figuring out whether the lending protocol you use runs a shared pool architecture or an isolated vault architecture. If it's a shared pool, your risk exposure isn't limited to the assets you personally chose — it includes every other piece of collateral that pool accepts. You're effectively co-signing every asset decision the protocol's governance has ever approved, even ones you never actively chose to take on.
The second step is watching for structural changes like key roles departing en masse from a protocol's governance — you don't need to prove this directly causes the next attack, but a system that was designed to rely on multiple independent layers of oversight, if those overseers keep stepping away one after another, means the actual rigor of that system may have drifted from the version you originally based your assessment on. The third step, if you find you already hold a position in a shared-pool-architecture protocol, is to periodically check the protocol's governance forum for newly proposed higher-risk collateral assets — not because you have the power to veto those proposals, but because knowing in advance what's being added to the pool lets you decide for yourself whether to exit before a risk actually materializes.
On April 18, 2026, North Korea's Lazarus Group drained roughly $292 million in tokens from the Cross-Chain Bridge of Kelp DAO, a liquid Restaking protocol, deposited those tokens as collateral on Aave, DeFi's largest lending platform, and borrowed approximately $190 million in WETH against them. The technical root cause wasn't a flaw in Aave's code, a problem in LayerZero's core protocol, or even a breach of Kelp's smart contracts — the attacker exploited a single configuration decision at Kelp's cross-chain bridge that Aave's risk framework had never assessed: Kelp used only a single verifier to confirm cross-chain transfers. What's genuinely worth remembering here isn't the attack method itself, but a deeper fact it exposed — Aave has one of the most thorough audit histories in the industry, and it still got hit by this, because an audit verifies a protocol's own code, not the risks hidden inside the infrastructure behind an asset the protocol chose to trust as collateral.
In January 2026, an Aave governance proposal activated e-mode for rsETH, letting users borrow WETH against rsETH collateral at a loan-to-value cap of 93%. The motivation was straightforward: similar liquid restaking tokens on other protocols already had comparable parameters, and this proposal explicitly targeted attracting $1 billion in new rsETH inflows. No Bridge Risk assessment was conducted as part of the proposal process. When the attackers showed up with $292 million in stolen tokens, that 93% LTV let them borrow $93 in WETH for every $100 of stolen collateral — by comparison, other lending protocols like SparkLend and Fluid had set rsETH's LTV at 72% and 75% respectively over the same period, noticeably more conservative. The governance vote that opened the industry's highest LTV for this asset passed a full three months before the exploit occurred.
Even more worth noting is what happened to the governance ecosystem itself. BGD Labs, which built and maintained Aave's core technical infrastructure, departed on April 1, citing disagreement with the team over the timeline for a major architectural upgrade. The Aave Chan Initiative, which coordinated governance and had grown Aave's own Stablecoin supply from $35 million to $527 million, left over concerns about Aave Labs' control over Governance Token distribution. And Chaos Labs, the specialized risk provider that had kept every Aave market free of material Bad Debt since November 2022, departed on April 6 — just 12 days before the exploit — citing inadequate budget and misalignment over risk management priorities. Three organizations that together formed Aave's accountability layer, each independent of the others, all left within weeks of each other right before the attack.
The most counterintuitive part of this incident is how far the damage spread beyond users directly exposed to rsETH. Within 48 hours of the exploit, borrowing rates for USDC and USDT on Aave spiked from roughly 3.5% to 14% and stayed there — not a decision made in any meeting, but the automatic output of Aave's rate algorithm reacting once pool utilization was pushed toward 100%. An institution that had never touched rsETH, simply borrowing stablecoins against bitcoin or Ethereum, watched its borrowing cost quadruple with zero warning and zero recourse. That's because Aave runs on a shared pool architecture: if any accepted collateral fails, the bad debt is absorbed proportionally by the entire pool, regardless of whether you had any exposure to the asset that failed. By contrast, Morpho, which uses an isolated vault architecture, faced the same attack on the same problematic asset and had only about $1 million in exposure — dramatically lower than Aave's roughly $196 million. That gap isn't a difference in who managed risk better — it's a difference in architecture itself.
Aave has one of the most thorough audit histories among DeFi lending protocols, and this incident didn't involve exploiting a single line of vulnerable code. That's precisely the lesson worth remembering: an audit verifies whether a piece of code behaves as designed, but it can't verify whether a parameter set through a governance vote is actually reasonable, whether the infrastructure behind an accepted collateral asset is genuinely secure, or whether the team responsible for overseeing risk might happen to collectively walk away at exactly the wrong moment. None of these fall under the scope of a code audit — yet all of them are capable of producing the exact same kind of catastrophic loss a code audit was supposed to prevent.