What a $290M Bridge Exploit Proves About Single Points of Failure
Author:
Eviatar ButinEditor:
Seth HallemThe Kelp DAO / LayerZero rsETH incident is a reminder that bridge security is about minimizing trust in any operator, stack, or infrastructure layer. Last weekend, the DPRK launched a sophisticated attack that exploited an insecure bridging configuration and performed a cleverly constructed RPC node compromise to steal nearly $300 million. How did things go wrong? Let’s start with some basics.
The basic concept of bridging is simple. To move funds from one chain to another, funds are locked in escrow on Chain 1 and released on Chain 2. To make this operation secure, it’s essential that messages between chains that direct the bridge to lock and release funds are transmitted securely.
To secure this process when a message is emitted from Chain 1 by an oApp (omni-chain app in LayerZero parlance), the message must be confirmed for authenticity by one or more Decentralized Verifier Networks (DVNs). The DVNs are responsible for inspecting the message and determining its authenticity prior to routing the message for execution on Chain 2.
To summarize, if an attacker can cause a fake message on a destination chain (Chain 2), they can direct the oApp to release tokens from escrow when those tokens are still held on chain 1. This scenario should never happen as it allows an attacker to steal tokens that are legitimately in use on another chain.
The best practice for oApp security is to use multiple, fully independent DVNs. That ensures a single point of compromise in the network of DVNs is insufficient to break the bridging system. However, the default configuration for oApps at this time is a 1-of-1 confirmation, meaning a single DVN confirms message authenticity, and presents a single point of failure.
oApp developers can choose how many and which DVNs are used to confirm messages routed through the LayerZero network. Insecure choices by the oApp developer are outside of recommended best practice, but there’s nothing preventing oApp developers from making insecure choices.
On April 18, 2026, at 1:35pm ET, one misconfiguration turned a restaking product into a $290 million target for a nation-state attacker. An attack, now linked to North Korea's Lazarus Group, skipped smart‑contract logic and on-chain security and went straight for the infrastructure.
The weak link was the decision to rely on a single DVN (a 1-of-1 validation setup) for the Kelp DAO rsETH oApp, meaning one DVN was the only security gatekeeper for hundreds of millions in value locked in the rsETH token. According to LayerZero's public statement, the attacker compromised multiple RPC nodes used by the LayerZero Labs-operated DVN.
The RPCs were run by independent operators (not LayerZero Labs). The attack started by replacing op‑geth binaries on two independent RPC nodes such that these two nodes deliberately reported false transaction information to the LayerZero Labs DVN. This compromise allowed the attacker to report fake transactions to the DVN. But the RPC compromise was not enough.
First the attacker carefully ensured that the compromised RPC nodes only reported false information to the LayerZero Labs DVN, avoiding detection by existing monitoring systems for RPC integrity.
Second, because the LayerZero Labs DVN relied on a distributed network of RPCs (far more than 2), the attacker needed to force the DVN to listen to the compromised RPCs. A separate DDOS attack was launched against all the other RPC nodes used by the DVN, thereby coercing the DVN to rely solely on the two compromised nodes.
There was no protocol-level bug, no broken key management. Just infrastructure access and a bridge that trusted only one party.
Since the DVN configuration was 1-of-1 in this case, the single, configured DVN was listening to poisoned RPC nodes. There were no additional independent verifiers to reject forged messages. The attacker then got to work forging a message to steal tokens.
The rest is a chain of disasters: the poisoned RPCs allowed fraudulently fabricated messages to be "verified," enabling the release of roughly 116,500 rsETH, about $290 million at the time, from Kelp's bridge.
Other LayerZero-connected apps scrambled to contain risk, with projects like Curve halting LayerZero infrastructure while investigations were under way, even as LayerZero insisted there was "zero contagion" beyond Kelp's rsETH configuration.
LayerZero's public statement emphasizes that the incident was isolated to Kelp DAO's rsETH configuration and that the use of a single DVN (1-of-1) contradicts their recommended multi-DVN setup. At the same time, the attack path went through infrastructure used by the Labs-operated DVN, underscoring how centralized verification and infrastructure in a single operator can create systemic risk even when each party follows its own operational protocols correctly.
The lesson for the rest of the ecosystem is stark: if your decentralized bridge security ultimately bottlenecks through a single operator's infrastructure, it is only as secure as that operator's worst-hardened node.
Let’s discuss the issues in LayerZero and Kelp’s security models in more detail and the best practices in designing and building a bridge.
A single DVN, no matter how reputable, should never sit alone in front of real money.
Instead:
Had rsETH been secured by multiple heterogeneous DVNs, a poisoned DVN (via the compromised RPCs) would have been insufficient to push forged messages through.
The rsETH exploit did not require breaking the LayerZero protocol or DVN signing keys. It depended on breaking the RPC nodes that the LayerZero DVN uses to see activity on the blockchain.
What does practical prevention look like?
In an Advanced Persistent Threat‑driven world, RPC endpoints are not just plumbing - they’re part of your attack surface.
Kelp DAO's rsETH setup shows what happens when an app quietly accepts a single‑operator security stack as "good enough." Bridge frameworks should:
If an app chooses a 1-of-1 configuration despite warnings, that choice should be denied or at least publicly obvious and priced into the asset.
Curve's immediate pause of LayerZero infrastructure during the rsETH investigation was a textbook example of defensive posture in an interconnected ecosystem. To generalize, cross-chain protocols should:
Fast, coordinated response can cap losses and prevent a localized failure from becoming a system-wide threat.
Many bridge audits still focus almost exclusively on contract logic and message‑passing correctness, underestimating the off-chain Web2 layer where this attack actually landed. A modern bridge security program should:
We can’t emphasize these measures enough. High-risk configurations have no place beyond testnet.
Follow these key practices to strengthen authentication, protect against replays, and avoid unauthorized actions.
Determined threat actors will dive as deep as they need to. Consider RPCs at risk and plan accordingly.
Continuously monitor bridge flows (by lane, asset, chain pair) for anomalies: sudden size jumps, unusual routes, repeated failures.
Add automatic slow‑downs and hard caps when volumes or patterns deviate from historical norms on any lane. Implement bridge‑level circuit breakers to pause globally, per-chain, and per-lane.
Get a bridge‑focused audit that covers trust model, message verification, rate limits, and emergency mechanisms, not just ERC‑20 logic.
Perform cross‑chain test scenarios like full round‑trip transfers, failed message handling, chain reorgs, lane pauses, and upgrade procedures.
Repeat targeted reviews when changing verifier sets, DVN implementations, or RPC architectures that the bridge depends on.
None of these principles are novel. They’re the same safety-engineering instincts that apply to any high-stakes distributed system. What is striking is how rarely they are applied properly to cross-chain token designs and how expensive that gap has become.
At Certora, we approach cross-chain security as a design discipline. Formal verification of on-chain invariants, combined with rigorous review of verifier topology, rate controls, and failure modes, is how this class of incident gets caught early.
Contact us to discuss your cross-chain and infrastructure security and avoid the next $200 million post-mortem.