rsETH Bridge Exploit, April 2026

A Liquid Restaking Token left its bridge escrow against a cross-chain message reporting a burn that had never happened. No contract was broken. The verifier that approved the message was reading the blockchain through machines an attacker controlled.

1. What happened

rsETH moves between chains over LayerZero. On that route a message is attested by a Decentralised Verifier Network, and the rsETH route was configured with a single one: the verifier operated by LayerZero Labs. One attestation was therefore enough to authorise a release.

LayerZero's own account, published the day after the event, describes the attacker reaching the list of RPC endpoints that verifier used to read chain state, compromising two of them — which it describes as independent nodes running on separate clusters without direct connection to each other — and swapping out the binaries running those nodes. It states that its least-privilege separation kept the attacker out of the verifier instances themselves, so what followed was an RPC-spoofing attack rather than a compromise of the verifier.

The poisoned nodes answered selectively. LayerZero says the malicious node showed its forged payload only to the verifier while telling the truth to any other address that queried it, which kept the compromise invisible to outside monitoring. To force the verifier onto those nodes, the attacker ran a denial-of-service attack against the endpoints it had not compromised; LayerZero's own timeline places that between 10:20 and 11:40 Pacific, which brackets the 17:35 UTC release.

What the verifier then saw was a burn of rsETH on Unichain that had never occurred. It attested the message, and Kelp's adapter contract on Ethereum released 116,500 rsETH from escrow to the attacker. In LayerZero's words, its verifier instance confirmed transactions that never in fact took place. The malicious node software was built to erase itself afterwards, deleting its binary, logs and configuration once the attack could no longer run.

Roughly three quarters of the proceeds were put straight to work. The risk report filed in Aave's governance forum two days later records 89,567 of the 116,500 rsETH supplied to Aave as collateral across seven addresses, against which 82,650 WETH and 821 wstETH were borrowed, leaving positions sitting at health factors around 1.01 to 1.03. Aave's Guardian froze the rsETH and wrsETH reserves and set their loan-to-value to zero within hours, which stopped new borrowing but left the existing positions in place.

2. What did not fail

This is the part worth dwelling on, because four separate organisations state it independently, including two with an interest in saying otherwise.

• LayerZero says the protocol itself functioned exactly as intended throughout the event and that no vulnerability was identified in it.
• Chainalysis states it was not a smart contract vulnerability — no reentrancy bug, no missing access check, no oracle manipulation — and that the release function behaved exactly as designed.
• OpenZeppelin states that Kelp's contracts were not broken, that no vulnerability was found in the rsETH token logic, and that the contracts performed exactly as written.
• Aave's risk report states that Aave's smart contracts were not compromised at any point during the event, and that its contracts, oracles and liquidation mechanics functioned as designed throughout.

Every piece of code in the path did what it was written to do. The system executed a correct transaction on top of a false picture of reality.

Two things failed instead. The first was a trust setting: one verifier meant one signature, so there was no second opinion to contradict the forged one. The second was the infrastructure underneath that verifier — ordinary server software on ordinary machines, outside every contract and outside every audit.

OpenZeppelin's analysis is explicit about the gap. A contract audit examines deployed contract logic: access control, arithmetic, reentrancy, deviation from spec. It does not typically examine how third-party integrations are configured at deployment, whether infrastructure components introduce a single point of failure, whether the defaults recommended in documentation were followed, or how a system behaves when its off-chain dependencies are compromised. This event sat inside all four of those.

3. Where the sources disagree

Four things are genuinely unsettled, and this page does not settle them.

• Who chose the single-verifier setup. LayerZero states that the configuration contradicted the multi-verifier redundancy model it has consistently recommended to integration partners, and that Kelp chose the one-of-one configuration despite those recommendations. Kelp's public position, as relayed by Chainalysis and by press coverage, is that one-of-one was the default shipped for new deployments at the time and that LayerZero personnel approved it. Litigation followed. Nothing in the published material resolves this, so both accounts are recorded.
• The size of the loss. LayerZero gives approximately $290M; Chainalysis and OpenZeppelin give approximately $292M. The token figure, 116,500 rsETH, is consistent everywhere, which is why it leads the table above.
• The downstream cost. The Aave report models two outcomes — about $124M of bad debt if losses are socialised uniformly, about $230M if they are isolated to the layer-2 deployments — and says in terms that these are hypothetical and that a single definitive outcome cannot yet be established. They are not realised losses and should not be quoted as such.
• Attribution. LayerZero attributes the operation to a state actor, likely the DPRK group known as Lazarus and specifically the subgroup TraderTraitor, and qualifies this as a preliminary indication. Chainalysis relays that attribution rather than reaching its own.

4. What it shows about restaking risk

The restaking map describes four layers: base capital, operator infrastructure, middleware with its slashing registries, and the receipt token wrapped around the result. On this occasion none of those four failed. No validator misbehaved, no penalty was enforced, no middleware rule was breached. The loss entered through the plumbing that lets a receipt token exist on more than one chain at once — a surface the layer model does not contain, because it is not part of restaking at all. It is part of distribution.

Then the receipt did what receipts do. Because rsETH was accepted as collateral in a lending market, tokens that should not have existed were immediately convertible into loans of assets that did. The fourth layer is where this site warns that risk becomes transferable, and this is what that looks like when the thing being transferred is counterfeit.

The practical lesson is narrow and uncomfortable. A depositor doing serious diligence on a liquid restaking position — reading the audits, checking the slashing conditions, counting the contract layers, as our risk questions suggest — would have found nothing wrong here. The questions that mattered were how many independent verifiers stood behind the bridge, and who operated the machines they trusted. Neither appears in an audit report.

Sources

Every figure above comes from one of the following. Dates are publication dates, and these links open in a new tab.

1. KelpDAO Incident Statement — LayerZero, 19 April 2026. The verifier operator's own account; a party to the event.
2. rsETH incident 2026-04-18 — LlamaRisk, in the Aave governance forum, 18 April 2026. Same-day status post on the freezes.
3. rsETH Incident Report — LlamaRisk, in the Aave governance forum, 20 April 2026. Source of the block height, the collateral and borrow figures, and the two bad-debt scenarios. Written by a risk service provider under mandate to Aave.
4. Inside the KelpDAO Bridge Exploit — Chainalysis, 23 April 2026. Independent reconstruction; relays LayerZero's attribution rather than making its own.
5. $292 Million Lost, Zero Bugs Found — Jainil Vora, OpenZeppelin, 23 April 2026. Source of the audit-scope analysis in section 2. A vendor blog: OpenZeppelin sells the security review services it recommends.

No account published by Kelp itself was located while writing this page; its position is therefore reported second-hand, which is a weakness in the record and is marked as such in section 3.

This page is explanatory and not a recommendation. Naming the organisations above records a documented event and reproduces their own published statements; it is not an allegation of wrongdoing and not a safety assessment.