Executive summary
On 18 April 2026, an attacker delivered a forged inbound LayerZero packet from Unichain to Ethereum and withdrew 116,500 rsETH from KelpDAO's Ethereum-side bridge adapter, without any corresponding burn on the source chain. At roughly $292 million at the time, this became one of the largest DeFi incidents of 2026.
The root cause, confirmed in the official incident report co-authored by Aave service providers, was that the Unichain → Ethereum rsETH route was configured as a 1-of-1 DVN, a single Decentralized Verifier Network. One attestation was enough to release the funds. There were no compensating monitoring controls in place to detect the bridge invariant being broken before the assets left.
What happened
LayerZero's cross-chain messaging system relies on DVNs to verify that a message on the source chain is legitimate before the destination chain acts on it. KelpDAO had configured this path with a single required DVN, meaning one attestation was sufficient for the destination contract to release funds.
The attacker submitted a forged inbound packet claiming that rsETH had been locked on Unichain and was owed on Ethereum. The single DVN attested to it. The bridge contract accepted it. And 116,500 rsETH was released, with no corresponding burn anywhere on the source side. The bridge invariant, that locked Ethereum assets must always equal or exceed IOUs issued on remote chains, was broken in a single transaction.
The attacker then distributed the stolen assets across seven branch wallets. Some of the rsETH was used as collateral on Aave V3, with additional positions bridged to Arbitrum, extending exposure across the broader DeFi ecosystem.
The configuration that made it possible
This was not a bug in the conventional sense. The contract executed exactly as configured. The failure was a trust architecture decision that quietly collapsed a distributed verification system into a single point of failure.
A 1-of-1 DVN configuration is, in practice, identical to trusting a single privileged key with production funds. In traditional security terms, it is break-glass access, the kind of control that demands short-lived authorisation, continuous monitoring, and explicit change approval. None of those compensating controls existed. There was also no real-time reconciliation to catch the moment assets were released without a corresponding source-chain burn. That invariant violation was detectable; it just wasn't being watched for.
What defenders can learn
Verifier configuration is a security control, not a protocol detail. A 1-of-1 DVN is a decision to place production funds behind a single attestation. It should be gated by the same change control as privileged credentials: documented, time-bounded, and approved before deployment.
Bridge invariant monitoring is a first-class detection requirement. Any time a bridge adapter releases assets without a paired source-chain burn or nonce advance, an alert should fire. Reconciling message claims against source-chain state in near real time is both achievable and essential for high-value routes.
Incident command needs to be pre-planned for bridge failures. When the root cause is a configuration decision, the postmortem must answer: who authorised the path, what approvals were required, what monitoring should have detected the invariant break, and which specific guardrails prevent it being reintroduced. Those answers should exist before an incident, not be assembled after one.
Further reading
- Official incident report, Aave governance
- Hypernative technical analysis
- Chainalysis fund flow analysis
- Galaxy market impact research
If your protocol relies on cross-chain messaging or verification networks, Security4Web3 can help you assess your verifier configuration, design invariant monitoring, and build incident readiness, before the next exploit.