The 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. 

Bridging 101

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.

What Went Wrong?

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.

What Was Missed?

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.

1-of-1 DVN as a Red Flag

A single DVN, no matter how reputable, should never sit alone in front of real money. 

Instead:

• Use multi‑DVN, N‑of‑M configurations that require independent systems to agree on state and message validity before assets move.
• Ensure DVNs are operated by distinct entities with separate infrastructure stacks, RPCs, client configurations, and operational practices, not just different labels on the same operator's machines.
• Each of these entities should be completely separate with no common point of failure.

Had rsETH been secured by multiple heterogeneous DVNs, a poisoned DVN (via the compromised RPCs) would have been insufficient to push forged messages through.

Harden the Infra Beneath Verifiers

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?

• Run your own full RPC nodes in hardened environments with strict access control in combination with public RPCs to achieve objective and correct quorum across multiple points of failure.
• Implement binary integrity controls (signed binaries, reproducible builds, measured boot), so that unauthorized client replacement is detectable and blocks RPC participation in the quorum.
• Use diverse clients and providers (different infra vendors, different client implementations, and independent monitoring) to make it costly for an attacker to hijack all your data feeds.
• Always monitor the RPC state - if multiple RPCs are down or under attack, the bridge should immediately take action.

In an Advanced Persistent Threat‑driven world, RPC endpoints are not just plumbing - they’re part of your attack surface.

Make Trust Assumptions Explicit to Integrators

Kelp DAO's rsETH setup shows what happens when an app quietly accepts a single‑operator security stack as "good enough." Bridge frameworks should:

• Enforce the most secure setup and disallow 1-of-1 insecure setups like the one Kelp chose.
• Expose configuration risk levels (i.e., "1-of-1 DVN: high‑risk," "3‑of‑5 heterogeneous DVNs: preferred") so product teams and users can make informed decisions.

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.

Embed Continuous Monitoring and Kill Switches

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:

• Establish automated anomaly detection on bridge flows, looking for abnormal volume, route patterns, or message sequences.
• Pre‑define emergency policies for pausing specific routes, DVNs, or chains when anomalies cross thresholds.
• Regularly simulate incident scenarios (table‑tops and chaos exercises) so teams know how to react when cross‑chain infra is suspected to be compromised.

Fast, coordinated response can cap losses and prevent a localized failure from becoming  a system-wide threat.

Align Audits With the Actual Threat Model

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:

• Include infra‑level red teaming of RPC stacks, DVN environments, and off-chain bridge code that connects everything together.
• Explicitly consider nation‑state attackers if TVL is in the discussion, including long‑term persistence and supply‑chain compromise scenarios.
• Document exactly who/what can cause value movement (validators, guardians, upgrade keys) and what compromises lead to "halt" vs "loss."
• Verify that configuration options exposed to integrators are safe by default or clearly guarded with warnings in place. Expose per‑lane "risk posture" (DVN count, independence, limits) via APIs/UX so integrators and users can see what secures each lane.

Best Practices to Secure Your Bridge

Careful Design, Configuration & Guardrails

We can’t emphasize these measures enough. High-risk configurations have no place beyond testnet.

• No 1-of-1 verifiers or DVNs on any production lane. Enforce multi‑DVN / multi‑validator N‑of‑M quorums in code.
• DVNs/validators must be operated by independent entities with non‑overlapping infra stacks and governance.
• Configure rate limits per lane and asset (throughput and total outstanding) so a single failure cannot drain the bridge.
• Require explicit acknowledgement (or governance approval) for any downgrade in verifier quorum or risk posture on a lane.

Message Verification & Asset Logic

Follow these key practices to strengthen authentication, protect against replays, and avoid unauthorized actions.

• Verify messages with strong authentication: signatures must be over a message hash including chain ID, lane ID, and nonce.
• Implement replay protection: per‑sender nonces, processed‑message tracking, and chain‑bound payloads.
• For lock‑and‑mint designs, enforce supply conservation: total wrapped supply ≤ locked on‑chain collateral at all times.
• Restrict mint/burn/unwrap authority to verified bridge contracts; remove admin mint shortcuts.

Bridge‑Critical Infra & RPC Use

Determined threat actors will dive as deep as they need to. Consider RPCs at risk and plan accordingly.

• Treat RPCs used by verifiers as part of the bridge’s trust base. Do not rely on a single RPC provider or single-node view.
• Use multiple independent RPC providers and/or self‑run nodes. DVNs should require quorum agreement across diverse RPC backends.
• Continuously monitor RPC behavior relevant to bridge security (e.g., unexpected client versions, forks, lag, or data divergence) and tie anomalies to automatic safe‑mode / pause triggers.

Bridge‑Scoped Monitoring, Limits & Kill Switches

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.

Bridge Auditing & Testing

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.

Conclusion

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.