LayerZero Releases rsETH Incident Report: Rebuilding Affected Infrastructure and Raising the Baseline for Cross-Chain Security
LayerZero Releases rsETH Incident Report: Rebuilding Affected Infrastructure and Raising the Baseline for Cross-Chain Security
Cross-chain interoperability has become a core primitive for DeFi in 2025–2026: liquid restaking tokens, multi-chain lending markets, and omnichain issuance standards all assume assets can move safely between networks. But the rsETH incident is a reminder that bridge security is not only about smart contracts—it’s equally about offchain verification, infrastructure integrity, and configuration choices.
In the wake of the KelpDAO rsETH exploit (April 18, 2026), LayerZero published a detailed incident statement and follow-up update explaining how a forged cross-chain message was ultimately accepted under a single-verifier setup, and what operational and policy changes it is making going forward. You can read the original write-ups here: KelpDAO Incident Statement and LayerZero Update.
What happened (and what didn’t)
The impact: rsETH bridge drained via forged message
On April 18, 2026, an attacker caused KelpDAO’s LayerZero-based rsETH bridge route to release approximately 116,500 rsETH (roughly $292M at the time), by getting a forged cross-chain message verified and executed on Ethereum. LayerZero emphasized that this was isolated to KelpDAO’s rsETH configuration and that the LayerZero protocol itself was not exploited. See LayerZero’s summary in the incident statement.
Attribution: DPRK-linked “TraderTraitor”
LayerZero stated it has preliminary confidence the attacker was a highly sophisticated state actor, attributing the incident to DPRK’s Lazarus Group, specifically the TraderTraitor cluster referenced by US authorities. For background on the “TraderTraitor” tradecraft (social engineering, malware delivery, and targeting crypto orgs), refer to the US joint advisory: CISA’s TraderTraitor advisory (AA22-108A).
What was not compromised (per LayerZero)
LayerZero’s incident statement explicitly notes the attack was not the result of a LayerZero protocol bug, and states DVN signing keys were not directly stolen. Instead, the attacker targeted the DVN’s data dependencies (RPC) and the surrounding availability assumptions. Details are in the incident statement.
The core failure mode: “single verifier” meets RPC poisoning + forced failover
LayerZero’s explanation centers on a growing class of attacks: RPC poisoning (feeding a verifier manipulated chain state) combined with DoS / DDoS (forcing the system to rely on the poisoned sources).
1) Downstream RPC nodes were compromised and selectively lied
According to LayerZero, the attacker gained access to the list of RPC nodes used by the LayerZero Labs DVN, compromised a subset, and modified node behavior so the DVN would receive falsified chain state—while many monitoring systems continued to see “normal” responses. LayerZero describes this selective deception in its incident statement.
If you want a practical primer on why RPC endpoints are a high-leverage attack surface for crypto systems, Chainstack’s overview is a helpful reference: RPC poisoning attacks in crypto. For a general definition of RPC in distributed systems, see IBM’s overview: Remote Procedure Call (RPC).
2) External RPC availability was attacked to trigger reliance on compromised nodes
LayerZero reports that DDoS activity against healthy external RPC endpoints pushed the DVN’s fallback behavior toward the poisoned endpoints, enabling verification of a message tied to transactions that never occurred as claimed. This “availability pressure” is a crucial lesson for anyone building offchain verification systems: redundancy is not just about having more endpoints; it’s about surviving targeted outages without trusting the wrong ones.
3) KelpDAO’s 1-of-1 DVN configuration turned compromise into loss
The most important configuration detail: KelpDAO’s rsETH route used a 1-of-1 DVN setup, with LayerZero Labs acting as the sole verifier. LayerZero argues this created a single point of failure—no independent verifier existed to reject the forged message. This is discussed directly in the incident statement.
A third-party deep dive that captures the “why this mattered for DeFi risk” angle is Galaxy’s research note: KelpDAO / LayerZero exploit analysis.
Why this incident matters beyond one bridge
The 2025–2026 reality: “infrastructure exploits” are scaling faster than contract exploits
DeFi security conversations still over-index on audits and onchain bugs. Yet many of the largest incidents now resemble enterprise intrusions: endpoint compromise, supply-chain tampering, session hijacking, and availability attacks—followed by onchain extraction.
In the rsETH case, the onchain contracts behaved as designed; the inputs to the verification process were poisoned.
DeFi composability turned a bridge drain into a liquidity shock
A major downstream concern was how unbacked or compromised collateral propagates into lending markets. Post-incident analysis highlighted how rapidly confidence shocks can drain liquidity even when the lending protocol’s core code works as intended. Glassnode’s write-up offers a market-structure perspective: Anatomy of a Liquidity Freeze.
LayerZero’s response: policy shifts, configuration hardening, and DVN changes
LayerZero’s publications describe three practical directions:
1) “No more 1-of-1” for the LayerZero Labs DVN
LayerZero states it will not sign/attest messages for applications using a 1-of-1 DVN configuration, and that it is reaching out to projects still operating with single-verifier setups. This is spelled out in the incident statement and reinforced in the LayerZero Update.
2) Raise the default baseline, but push teams to pin configs
In its May 8 update, LayerZero recommends builders:
- Pin configurations (don’t rely on mutable defaults)
- Use higher block confirmations appropriate for the chain
- Adopt multi-DVN redundancy (at least 2, ideally 3–5)
These recommendations are listed in the LayerZero Update. For implementers, LayerZero also references an integration checklist in its docs: LayerZero integrations checklist.
3) Rebuild and replace affected RPC components
LayerZero states the affected RPC nodes were deprecated and replaced, and DVN operations resumed with changes to RPC quorum and redundancy assumptions (details across the incident statement and update).
While every team’s internal security architecture differs, the direction aligns with broader “zero trust”-style thinking: minimize standing privileges, segment production systems, and treat internal networks as hostile by default—especially when your system acts as a verifier for external value.
Practical takeaways for builders: a 2026 checklist for cross-chain bridge security
If you ship or integrate an omnichain asset (OFT-like wrappers, canonical bridges, restaking derivatives), the rsETH incident suggests a clear priority order:
-
Eliminate unilateral verification
- Require N-of-M independent verifiers (not “two brands on the same stack”).
- Independence must include: operator org, hosting, RPC sources, monitoring, and incident response.
-
Harden RPC trust and failover logic
- Treat RPC endpoints as untrusted inputs.
- Ensure failover does not silently reduce security (e.g., “if endpoints fail, trust fewer endpoints” is dangerous).
- Build “degraded mode” behavior: halt verification rather than accept weaker proofs under pressure.
-
Design for adversarial availability
- Assume targeted DDoS is part of the kill chain.
- Model what happens when only the attacker-controlled subset remains reachable.
-
Make security posture observable
- Publish your verification assumptions in a dashboard or docs:
- DVN set, thresholds, confirmations, pause keys, emergency procedures
- Users and risk teams need to see configuration risk before an incident.
- Publish your verification assumptions in a dashboard or docs:
Practical takeaways for users: how to reduce cross-chain risk exposure
Even if you never write a line of code, you can materially reduce risk:
- Treat bridged assets as a separate risk class from “native” assets.
- When yield looks similar across chains, prefer venues where collateral depends on fewer offchain assumptions.
- Keep only operational balances on L2 / bridged representations; store long-term holdings in cold storage.
Self-custody matters: why a hardware wallet is still a core control
Incidents like rsETH are about verification and infrastructure, but many large losses still begin with compromised devices, credential theft, and social engineering. A hardware wallet reduces the blast radius by keeping private keys isolated from everyday browsing and workstation malware.
If you’re serious about long-term self-custody, using a hardware wallet like OneKey helps ensure transaction signing stays off your internet-connected environment—an important layer when the broader ecosystem is dealing with increasingly professional, state-linked threat models.
Closing thought: “configurations are security”
The rsETH exploit will likely be remembered less as “a bridge hack” and more as a systemic lesson: protocol security is modular now, and the weakest module (often configuration + infrastructure) defines the real risk.
As cross-chain messaging becomes the default plumbing for DeFi and tokenized assets, the industry’s baseline must move from “audited code” to audited assumptions—including DVN diversity, RPC integrity, and failover safety.
