As much as it pains me, but for the things I have influence over, I will switch to the default: SECURITY > NEUTRALITY A “pause everything” function? A daily limit? An extra safety-net layer that every transaction has to pass through before being processed? Yes!

On April 6, I ran an AI-assisted security scan on Kelp DAO and flagged their LayerZero DVN bridge config as an unresolved risk. 12 days later, that exact attack surface was exploited for $292M. The tool didn't find a code bug. It found something code audits can't catch: a 1-of-1 bridge validator config that Kelp never disclosed publicly. One node compromised = $292M drained. Kelp had 5+ code audits from top firms. None caught it — because it's not a code problem. The tool is open-source. Anyone can run it on any DeFi protocol before depositing. What it checks that code scanners don't: → Bridge validator thresholds → Governance gaps between core contracts and operational configs → Historical attack pattern matching (Ronin, Harmony, Drift) What protocols are you exposed to that haven't disclosed their DVN config?

we're now seeing some negative secondary effects of illiquidity in Aave stablecoin markets (in this example, Aave Core USDT on Ethereum) because users cant withdraw due to 100% utilization, there has been a ~$300 million increase in borrowing with USDT collateral in just the past day since the rsETH exploit with a 75% max LTV, users with stuck USDT deposits can take out up to 3/4 of the value of their aave position. but this ends up reducing liquidity in other markets, with USDC and USDe markets now at 100% utilization as well i think aave should consider immediately prevent new borrowing with illiquid collateral assets (eg setting LTV=0 for USDT, USDC, USDe on Aave Core, and relevant assets on other markets/chains, or alternatively disabling borrows across the board on all assets)

because the final allocation of losses between rsETH on Ethereum (which is technically "fully backed") and external chains is still tbd, i can only read this as a statement of Aave Labs' preference - they would rather rsETH on mainnet to have zero haircut, and for rsETH on L2s/external chains to bear the full loss (essentially zeroed out) ultimately, the allocation of losses will be mostly decided by Kelpdao team (and lawyers) but we can consider why this outcome would be aave labs' preference, and what would be the impact on users if this is how it ends up working out # aave labs preference aave core market on ethereum is covered by umbrella insurance module, and is also explicitly covered by aave dao backstop (eg dao committed to using treasury to backstop against bad debt). so if rsETH on ethereum ends up with no haircut, then not only are umbrella users completely unaffected (other than potentially GHO stakers to cover unbacked GHO on external chains), but the aave treasury remains intact aave core is also the primary money-maker for the aave protocol, and preserving this is probably top priority for labs team # user impacts if rsETH on Ethereum has no socialized losses/haircut, users on Aave core would end up being mostly unimpacted however, certain L2 networks would face an extremely heavy burden, with WETH suppliers taking a direct hit from unbacked rsETH current rsETH collateral across external chains includes: - Base: $71 million - Arbitrum: $152 million - Mantle: $116 million - Ink: $21 million - Linea: $1.4 million in some cases, rsETH backed loop positions may comprise a large share of the backing of aWETH, meaning that any assets borrowed against ETH may also be at risk of a haircut (USDC and USDT0 markets) mantle, arbitrum, and base seem to have the highest risk here, with mantle in particular having the majority of aWETH backed by potentially zero value rsETH. it is possible that Aave could successfully maneuver these chains into bailing out their markets (this may be part of the reason why Aave Labs prefers no loss socialization on Ethereum, to force the issue with relatively better capitalized chain ecosystems) we also note that ethena has a material deposit amount in the mantle USDT pool (https://debank.com/profile/0xB8734a14fBD… which may face a haircut, potentially exceeding their excess capital buffer. if this is the case, then this would become another vector of contagion risk into Aave markets including Core and Plasma (which has been relatively less affected as it had no rsETH exposure at the time of the hack) # comparison with full socialization personally, i think that concentrating losses on external chains is actually a worse outcome for Aave in the case where losses are spread evenly including Ethereum users, this would engage Umbrella ETH depositors (roughly $50 million) and also enable using rsETH collateral on Aave Core to repay part of the debt, likely reducing the uncovered loss on Ethereum mainnet to an amount lower than Aave's current treasury reserves the loss levels on external chains would then be at much more manageable levels, with less risk of cascading spillover into large haircuts on stablecoin markets or impairment to other key aave collateral assets like USDe awaiting further updates from the Kelpdao team to see how this will play out in practice

OK — Kelpdao hacker, how much you want? Let’s just talk. With KelpDAO’s help, of course. It’s simply not worth it to sacrifice both Aave and KelpDAO and let them go down over this hack. You can’t spend $300 million anyway.

Aave Sees $5.4B ETH Outflows as rsETH Exploit Raises Concerns According to Lookonchain, the Kelp DAO exploit has left Aave saddled with bad debt after the attacker deposited rsETH to drain ETH. This has sparked a massive whale exodus, with over $5.4 billion fleeing the protocol in a panic. Justin Sun alone yanked 65,584 ETH (~$154M) from the platform. Driven by this mass flight, Aave's ETH utilization rate has now maxed out at 100%.

🚨 SECURITY ALERT 🚨 We are aware of a potential domain hijack affecting the @eth_limo DNS. Please DO NOT use the following domains until further notice. ❌ staking.safenet-beta.eth dot limo ❌ explorer.safenet-beta.eth dot limo You can safely access these services via IPFS directly: 🔹 Staking: https://ipfs.io/ipfs/bafybeiemy5vn7xwsfr… 🔹 Explorer: https://ipfs.io/ipfs/bafybeigq44oghn3enl… This is NOT a Safe specific issue and any other dot limo domains should also be avoided till the @eth_limo team resolves the issue. Stay vigilant.

KelpDAO's rsETH bridge seems to have been exploited for ~$292M. Hacker borrows WETH against stolen rsETH on Aave. Here's what we know.

I'm dropping a thread of all the protocols that had to freeze their interop because of LayerZero being compromised. Let's go:

The KelpDAO exploit (~$290M, is NOT a LayerZero protocol bug. It's a configuration issue and a case study every project with a cross-chain token needs to look at today. KelpDAO shipped their rsETH OFT with a 1/1 DVN security stack. One required verifier. Zero optional. Threshold 0. Straight from LayerZero Scan's ReceiverOAppConfig on the rsETH bridge pathway: • requiredDVNCount: 1 • requiredDVNNames: [LayerZero Labs] • optionalDVNCount: 0 • optionalDVNThreshold: 0 Source and Destination OApp both labeled "Kelp DAO." Destination is the rsETH OFT Adapter on Ethereum: 0x85d456B2DfF1fd8245387C0BfB64Dfb700e98Ef3. How the attack worked: the forged message's source packet was never actually emitted on the source chain (Unichain). The single required DVN signed an attestation for something that didn't exist and because it was the ONLY required DVN, there was no independent verifier to contradict it. Everything downstream then executed exactly as designed: commitVerification → lzReceive → peer check → OFT decode → rsETH mint. The contracts weren't broken. The verification layer was. One signature and 116,500 rsETH materialized out of thin air on Ethereum. To be clear: LayerZero V2 is modular by design. Apps pick their own security stack X-of-Y-of-N, multiple independent DVNs, thresholds, block confirmations. No one is forced into any configuration. The protocol gave projects the full toolkit. KelpDAO chose 1/1. Even reputable DVNs can have a bad day key compromise, infra failure, bad actor, whatever. That's exactly why you want multiple independent verifiers. Redundancy is the whole point. A 1/1 DVN is the cross-chain equivalent of a 1-of-1 multisig on a treasury. Baseline for any OFT/OApp with serious TVL: • Multiple required DVNs (3–4+) • Independent providers (don't stack correlated risk) use canary DVN as it’s also its own independent client. • Optional DVNs + threshold on top • Sane block confirmations If you're a founder or dev with an OFT live in production, pull your Send/Receive ULN config today. Call getConfig() on the endpoint. If requiredDVNCount is 1 and optionalDVNCount is 0, reconfigure before the market does it for you. Anyone can verify any OApp's config on http://layerzeroscan.com right now. Security is the application's responsibility. LayerZero hands every project a powerful, modular security stack it's on the project to actually use it. Kelp's full RCA is still coming, but the root enabler is already onchain and visible to anyone who looks. Check your configs. Stay safe out there.

Update on rsETH incident: According to our analysis, rsETH on Ethereum mainnet is fully backed. Out of an abundance of caution, rsETH remains frozen across Aave V3 and V4 and exposure to the incident is capped. WETH reserves also remain frozen across affected markets including Ethereum, Arbitrum, Base, Mantle, and Linea. Aave is actively validating information and assessing potential resolutions.

Due to rsETH LayerZero infrastructure being hacked, we decided to pause Curve LayerZero infrastructure before more understanding about the root causes is obtained, out of precaution. This affects: * CRV bridging from chains: bnb, sonic, avalanche, fantom, etherlink, kava. Other chains use native bridging; * crvUSD fast bridge (slow bridging for L2s still works).

We’ve identified a security incident that involved unauthorized access to certain internal Vercel systems, impacting a limited subset of customers. Please see our security bulletin: https://vercel.com/kb/bulletin/vercel-ap…

The rsETH markets on Aave V3 and Aave V4 have been frozen. Aave's contracts have not been exploited and this is an exploit related to rsETH. The freeze follows an exploit of the Kelp DAO rsETH bridge. Freezing the rsETH markets prevents new deposits and borrowing against rsETH collateral while the situation is assessed. We are reviewing information about rsETH borrows on Aave that occurred after the exploit and will share more details as soon as possible. If the protocol accumulates bad debt from this incident, we'll explore paths to offset the deficit.

AAVE MULTISIG GUARDIAN FREEZES WETH ON LENDING MARKETS: ONCHAIN

@dcfgod is right! rsETH exploit forensics. Live on-chain. 1/ Attacker wallet: 0x1F4C1c2e610f089D6914c4448E6F21Cb0db3adeF @aave V3 supply ladder, one wallet: 1 → 400 → 5,000 → 20,000 → 27,999 rsETH. Textbook test-then-scale. Probe with 1 token, ramp each time the prior clears. 53,400 rsETH from this wallet. ~$134M. Cluster total: ~116,500 rsETH. ~$290M. 2/ Aave V3 ETH reserve, live: Supplied: 2.71M WETH ($6.37B) Borrowed: 2.71M WETH ($6.37B) Utilization: 100% Supply APY: 7.36% Borrow APY: 8.71% That is the bank run. WETH suppliers are locked. Withdrawals blocked, as first flagged by @Marczeller. 3/ The mechanic. Attacker drained rsETH (OFT bridge vector, per initial reports). Supplied it as collateral on Aave V3 mainnet. Borrowed max WETH up to liquidation threshold. Walked. Kelp paused redemptions. Secondary rsETH liquidity cracked. Aave oracle still marks near peg. Liquidators cannot close the position at mark. The gap becomes bad debt on the WETH reserve. 4/ Loss waterfall. a. Umbrella. First live stress test of the Q4 2025 replacement for Safety Module. Will it fully slash aWETH stakers to cover the deficit? b. Residual haircut flows pro-rata to remaining WETH suppliers. c. Kelp mainnet rsETH holders are intact. Native ETH backing untouched, circulating supply unchanged. This is not a Kelp mint exploit. It is a bridge theft that became an Aave bad debt via instant cash-out. 5/ The primitive lesson. Listing an LRT, or any bridged derivative, as collateral means underwriting the entire upstream dependency stack: - Bridge config and security (@LayerZero_Core OFT here) - Mint and burn permissions - Oracle feeds and redemption mechanics - Fee contracts and wrapper logic Any single point of failure upstream becomes WETH bad debt downstream. @StaniKulechov, this is a listing-authority problem more than a token problem. If the stack cannot be fully priced and simulated, do not list it.

Checked the chain No new rseth was minted recently - the circ supply has been pretty steady They still have 670k eth and there’s 629k rseth circulating Question is - is any rseth considered unbacked? Does it work like frax where they can protocol mint some that would never be redeemed? Or is all rseth always backed? in which case, there would be no aave bad debt as they can just redeem it But then whose rseth was this? Some whale?

our domaim appears to have been compromised and the http://eth.limo domain has been hijacked. We're actively working with all parties involved to assess the situation and remediate the problem.