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.
Key concepts: This analysis covers trust assumption, verification failure, smart contract audit, DeFi protocol and related blockchain security topics.
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.
Bridge Security: What Protocol Teams Must Verify Before Going Live
The KelpDAO rsETH exploit did not happen because of a sophisticated zero-day attack. It happened because a trust architecture decision — a 1-of-1 DVN configuration — was treated as a protocol detail rather than a security control. That distinction is the entire lesson.
When a cross-chain bridge goes live with a single verifier on a high-value route, the team has made an implicit decision to trust one system with production funds, with no compensating controls, no monitoring, and no procedural gate requiring that decision to be reviewed. In any other industry where this kind of single point of failure governed access to hundreds of millions of dollars of assets, it would not survive a basic security review. In DeFi, it shipped to mainnet.
The Verification Trust Architecture Problem
Cross-chain bridges are fundamentally in the business of making trust decisions. The destination chain must decide whether to believe a claim that something happened on the source side. The quality of that decision depends entirely on the verification architecture. A 1-of-1 DVN is not a distributed verification system — it is a single privileged oracle with production access. The distributed label is misleading if only one participant is required to attest.
The minimum viable verification posture for a high-value bridge route is a threshold of independent, non-colluding verifiers, paired with monitoring that detects when a destination-side release occurs without a corresponding source-side event. Neither of these is exotic — they are the baseline requirements that the KelpDAO incident makes explicit.
A Pre-Launch Bridge Security Checklist
- Verifier configuration review: What is the DVN or validator threshold on every active route? Any 1-of-1 or effectively single-path configuration must be treated as a critical finding.
- Bridge invariant monitoring: Is there real-time alerting that fires when destination-side releases exceed source-side deposits or burns? This is a non-negotiable detection control for any live bridge.
- Change control for trust configuration: Are verifier settings, trusted remote configurations, and signing thresholds gated by a documented change approval process? Configuration changes to production bridge parameters should require the same scrutiny as smart contract upgrades.
- Incident response pre-planning: Does the team have a documented runbook for pausing bridge operations, communicating to users, and triaging a suspected invariant breach? The KelpDAO response was slow in part because these decisions were being made under pressure for the first time.
- Formal verification of message validation logic: The correctness of the verification path — the logic that decides whether to accept or reject an inbound message — is the most critical property of any bridge contract. It should be formally verified, not just audited.
Our DeFi protocol bridge audit covers the full verification trust stack: DVN configuration, invariant monitoring design, message validation logic, and operational governance. For teams who want mathematical assurance that their core validation path is correct, our formal verification service provides the strongest available guarantee — and for bridge contracts specifically, it is the appropriate bar.