The core of this Kelp exploit was that the attacker forged a cross-chain message, causing LayerZero’s OFT bridge to directly mint 116,500 real rsETH on Ethereum mainnet without any corresponding burn on the source chain. The attacker then deposited these “fake” rsETH as collateral into protocols like Aave and borrowed approximately $236 million in real WETH/ETH. The vulnerability did not lie in Aave, but in Kelp DAO’s LayerZero cross-chain bridge configuration. Kelp’s rsETH cross-chain functionality uses LayerZero V2’s OFT (Omnichain Fungible Token) standard: On Ethereum mainnet, the OFTAdapter contract locks rsETH as the ultimate reserve backing wrapped rsETH on multiple L2s (like a bank vault). On L2s, standard OFT contracts follow a 1:1 mechanism during cross-chain transfers: debit (burn/reduce) → message → credit (mint/release). In a normal cross-chain flow, the process would be: L2 user burns rsETH → LayerZero sends message → Mainnet OFTAdapter receives message and releases rsETH. But the attacker did just one thing: They directly called the lzReceive function of LayerZero’s EndpointV2 contract on Ethereum mainnet (transaction hash publicly available: 0x1ae232da…), injecting a forged cross-chain message packet (origin packet) falsely claiming to originate from a legitimate source chain. After EndpointV2 validated the packet, it forwarded the message to Kelp’s rsETH OFTAdapter. The OFTAdapter, upon receipt, immediately released 116,500 rsETH from the mainnet reserve to the attacker’s address—without any corresponding burn or debit record on the source chain. This broke omnichain supply consistency: the mainnet reserve was drained, and all rsETH on L2s simultaneously became worthless. The entire attack was executed in a single transaction. Two subsequent attempts (each for 40,000 rsETH) failed because Kelp urgently paused the bridge. So the question arises: Why did LayerZero’s cross-chain bridge “accept” this fake message? It wasn’t a bug in the LayerZero protocol itself—it was due to Kelp’s extremely weak application-layer (OApp) security configuration. LayerZero V2 allows developers to customize verification strength using a DVN (Distributed Validator Network) to validate messages. Kelp configured only a 1-of-1 DVN (requiring only a single validator’s signature for approval)—the weakest possible security setting. Back in January 2025, Aave’s governance forum warned that Kelp should upgrade its DVN to a multi-signature setup (at least 2-of-2 or higher). Yet 15 months passed without any change; Kelp continued to prioritize speed over security by maintaining the weakest configuration. This single point of failure became the core attack vector: either the single DVN was compromised, its signature forged, or a valid-looking packet was directly constructed to pass validation. Once EndpointV2 received a “validated” message, it immediately invoked the target contract’s lzReceive function. The OFTAdapter fully trusted the packet received from EndpointV2 and performed no additional verification. Had Kelp prioritized balanced security alongside speed, this attack might have been prevented. In essence, Kelp placed complete trust in the legitimacy of cross-chain messages on a single DVN. The reason rsETH could be quickly borrowed as real ETH is because rsETH was whitelisted as collateral in Aave and other DeFi protocols. Within 46 minutes before Kelp paused the bridge, the attacker deposited the forged rsETH and withdrew real WETH. By the time Kelp froze the bridge and tokens, bad debt had already formed in Aave (which subsequently froze the rsETH market and activated its Umbrella security module). In summary, The core of this forgery was “single DVN configuration + direct lzReceive call with forged packet.” A single point of validation, combined with DeFi composability, resulted in this massive-scale exploit. Single-point validation is inherently fragile. Speed matters—but security matters more.