Cowrie Research

kelpdao-rseth-layerzero-1-of-1-dvn-rpc-poisoning-forged-bridge-release-2026-04-18

15 min read

KelpDAO rsETH LayerZero 1-of-1 DVN RPC Poisoning / Forged Bridge Release (2026-04-18)

  • Name: KelpDAO rsETH LayerZero 1-of-1 DVN RPC poisoning / forged bridge release
  • Date: 2026-04-18
  • Protocol: KelpDAO / rsETH / LayerZero OFT Adapter
  • Chain: Ethereum + Unichain + LayerZero-connected L2s
  • Category: bridge verification failure / single-verifier DVN compromise / RPC poisoning / forged message acceptance / unbacked bridge release
  • Loss: about 200M to $236M of WETH and wstETH and left large bad-debt holes on Aave and smaller holes elsewhere
  • Summary: KelpDAO configured the Unichain → Ethereum rsETH bridge path to trust a single LayerZero Labs DVN. Attackers poisoned the source-state view feeding that verifier by compromising internal RPC nodes and knocking clean external nodes offline, then submitted a forged packet claiming a large Unichain-side rsETH burn that never happened. The LayerZero endpoint and KelpDAO’s Ethereum OFT adapter saw a valid attestation from the only required verifier and released 116,500 rsETH from mainnet escrow to the attacker. The attacker then treated the unbacked rsETH as fresh collateral across lending venues, especially Aave, and borrowed real ETH-correlated assets before KelpDAO’s pause landed.
  • Trigger / entry point:
    • The live KelpDAO rsETH bridge route from Unichain to Ethereum relied on LayerZero V2’s OFT adapter pattern and accepted a 1-of-1 DVN configuration.
    • The sole required verifier for that route was LayerZero Labs’ DVN rather than a multi-DVN quorum of independent operators; LayerZero’s later incident statement said that setup directly contradicted its published multi-DVN hardening guidance.
    • The Ethereum-side release path was ordinary LayerZero delivery into EndpointV2 0x1a44076050125825900e736c501f859c50fE728c, which then invoked KelpDAO’s rsETH OFT adapter 0x85d456B2DfF1fd8245387C0BfB64Dfb700e98Ef3.
    • Once the verifier attested that the packet was valid, the adapter’s escrow-release path had no second source-side burn check and no independent verifier to disagree.
  • Root cause:
    • The decisive failure was not a bug in rsETH token logic or LayerZero endpoint bytecode. It was bridge-authenticity collapse at the observation layer.
    • KelpDAO’s route accepted one verifier as sufficient truth, so poisoning that verifier’s source-chain view was enough to mint authenticity for a forged packet.
    • The DVN’s signing quorum was not the same thing as independent verification. LayerZero’s incident statement says the attacker first obtained the DVN’s RPC list, replaced op-geth binaries on two internal nodes, then DDoS’d clean external RPCs so the verifier failed over onto poisoned data.
    • The same statement also says the malicious nodes selectively lied only to DVN-originated requests while continuing to answer truthfully for other IPs, including LayerZero’s scan / observability stack, which explains why ordinary monitoring did not immediately flag the forged Unichain state.
    • No protocol-level invariant re-established that 116,500 rsETH had actually been burned or locked on the source chain before the Ethereum escrow released the same amount.
  • Exploit path:
    1. The attacker targeted the LayerZero Labs verification path used for KelpDAO’s Unichain → Ethereum rsETH route rather than attacking KelpDAO’s restaking contracts directly.
    2. Public postmortems say the attacker obtained the DVN’s RPC inventory, compromised two internal RPC nodes feeding the sole required DVN, and swapped in malicious op-geth binaries.
    3. Those poisoned nodes served fabricated Unichain state only to the DVN path while simultaneously returning truthful state to other requesters, helping the attack evade ordinary scan / observability checks.
    4. The attacker then DDoS’d clean external RPC paths so the verifier failed over onto the poisoned nodes.
    5. Those nodes presented fabricated Unichain state showing a large rsETH burn / outbound packet that did not actually exist.
    6. The sole required DVN accepted that false reality and produced a valid attestation for a forged LayerZero packet.
    7. On Ethereum at about 17:35 UTC, transaction 0x1ae232da212c45f35c1525f851e4c41d529bf18af862d9ce9fd40bf709db4222 delivered the forged packet through EndpointV2 into the KelpDAO OFT adapter.
    8. The adapter released 116,500 rsETH from Ethereum escrow to attacker address 0x8B1b6c9A6DB1304000412dd21Ae6A70a82d60D3b even though no matching Unichain burn had occurred.
    9. The attacker split the freshly released but unbacked rsETH across multiple EOAs, posted a large share into lending venues as collateral, and borrowed out deeper-liquidity ETH assets before markets froze.
    10. Aave later reported that of the 116,500 rsETH received by the attacker, 89,567 rsETH was deposited there, turning the forged bridge release into protocol-scale WETH bad debt rather than a simple DEX dump.
  • What the attacker needed to be true:
    • The bridge route had to trust a single verifier rather than requiring multiple independent DVNs.
    • The sole verifier’s observation layer had to depend on a finite RPC set that could be poisoned or forced into bad failover.
    • Ethereum escrow had to hold enough rsETH to honor the forged packet once the verifier signed it.
    • Downstream lending markets had to accept rsETH as collateral at high enough LTVs that the attacker could quickly convert fake bridge-authenticated rsETH into real WETH and wstETH.
  • Technical anatomy worth remembering:
    • This was a bridge-verification failure even though the attacker did not steal a validator key and did not exploit a smart-contract bug. The forged truth came from a poisoned verifier input path.
    • The cleanest mental model is released on destination chain against a non-existent burn on the source chain. Chainalysis describes the key invariant exactly that way.
    • Public technical analysis highlighted concrete source-side impossibilities: Unichain nonce 308 never existed, no matching PacketSent event was emitted for the claimed outbound packet, and Unichain’s rsETH supply was nowhere near large enough to support a legitimate 116,500 rsETH burn.
    • LayerZero’s own statement makes the monitoring lesson sharper: the malicious nodes allegedly told the truth to other IPs and internal scan infrastructure while showing forged state only to DVN-originated requests. In other words, healthy dashboards did not imply healthy verifier inputs.
    • The incident shows that a nominal verifier quorum can still be a single point of failure when all signers are downstream of the same operator and the same poisoned observation stack.
    • The downstream cashout path mattered as much as the bridge break. Rather than dumping rsETH into shallow spot liquidity, the attacker used DeFi collateral rails to convert fake bridge-authenticated inventory into real borrowed ETH.
  • Representative transactions and contracts:
    • LayerZero EndpointV2: 0x1a44076050125825900e736c501f859c50fE728c
    • KelpDAO rsETH OFT adapter on Ethereum: 0x85d456B2DfF1fd8245387C0BfB64Dfb700e98Ef3
    • Primary forged-release transaction: 0x1ae232da212c45f35c1525f851e4c41d529bf18af862d9ce9fd40bf709db4222
    • Primary recipient / attacker EOA: 0x8B1b6c9A6DB1304000412dd21Ae6A70a82d60D3b
    • Later attacker-controlled consolidation address cited in public writeups: 0x5d3919F12bCc35c26Eee5F8226A9bee90c257Ccc
  • Response / mitigation:
    • KelpDAO paused rsETH contracts across Ethereum and multiple L2 deployments roughly 46 minutes after the initial forged release and blacklisted attacker-linked addresses.
    • Public postmortems say two follow-up forged packets targeting another 40,000 rsETH reverted after the pause.
    • Aave and other venues froze rsETH-related markets; Aave later published incident accounting showing large WETH bad debt depending on how losses were socialized.
    • Arbitrum’s Security Council later used emergency powers to seize or freeze 30,766 ETH of the attacker’s downstream funds on Arbitrum via an intermediary wallet under governance control.
    • LayerZero deprecated the affected RPC nodes, replaced them, and said it would stop signing or attesting messages for applications still running 1-of-1 DVN configurations.
  • Comparable exploit pattern:

Pattern tags

  • bridge-verification-failure
  • verifier-input-independence-failure
  • degraded-mode-authenticity-failure
  • A nominal DVN quorum still collapsed to one bridge-truth lane because the route accepted 1-of-1 verification and the only required verifier inherited the same poisoned RPC / failover cohort
  • External observability and scan tooling stayed truthful while the DVN itself was being shown forged state, so healthy dashboards materially overstated verifier-health reality
  • Destination-side escrow release and downstream borrow-side monetization were almost contiguous, so one forged source-state claim immediately became both bridge loss and lending-system bad debt

Why the exploit worked

  • KelpDAO accepted one DVN as sufficient truth for the Unichain → Ethereum rsETH route, so there was no second independent verifier to disagree once that one lane was poisoned. LayerZero’s own statement says this 1-of-1 setup directly contradicted its published multi-DVN hardening guidance.
  • The real failure domain lived below the signature layer. The attacker did not need DVN key theft or EndpointV2 bytecode bugs; poisoning the RPC nodes and then forcing failover onto them was enough to make the sole verifier attest to a burn that never happened.
  • Monitoring asymmetry helped the route stay live. Public writeups say the malicious nodes told the truth to other requesters and scan infrastructure while selectively lying only to the DVN path, so ordinary external observability did not reconstruct the actual verifier inputs.
  • Ethereum escrow still treated sole required DVN signed this packet as fully sufficient bridge truth. No route-local burn re-check, delayed release boundary, or independent custody sanity check stood between forged attestation and 116,500 rsETH leaving escrow.
  • The forged bridge release stayed maximally monetizable because rsETH still had broad downstream collateral recognition. Instead of dumping counterfeit inventory into shallow spot liquidity, the attacker could post it into money markets and withdraw deeper-liquidity WETH and wstETH before risk controls converged.

Three verifier-authority promotions this incident collapsed

  1. Some verifier-shaped artifact existed
    • A real LayerZero-style attestation arrived for the Unichain → Ethereum rsETH route, and EndpointV2 plus the KelpDAO OFT adapter saw an authenticity-looking object from the only required DVN.
    • That fact alone only proved that one accepted verifier lane had produced a bridge-shaped answer, not that the route had learned a real source-side burn.
  2. That artifact deserved to count as independent bridge truth
    • This was the decisive collapse. KelpDAO treated the sole required DVN attested as if it meant the route has independently learned that Unichain burned 116,500 rsETH, even though the only required verifier still depended on one poisonable observation stack and one failover tree.
    • Once the attacker compromised internal RPC nodes and forced failover away from clean external reads, the route had no second independently grounded witness left to disagree. The bridge confused a verifier answer exists with the route has independent bridge truth.
  3. That accepted truth deserved immediate escrow-release authority
    • Even if the route had some verifier answer good enough to act on at all, Ethereum escrow still treated that answer as sufficient for ordinary full-size release authority.
    • No route-local burn reconciliation, impossible-supply brake, staged withdrawal boundary, or capped degraded-mode lane separated accepted verifier truth exists from release 116,500 rsETH from mainnet escrow now.

The practical review habit is the same one this incident punishes: do not stop at the verifier signed. Ask whether the bridge first confused an attestation artifact arrived with the route has independently grounded bridge truth, then confused even that accepted truth with ordinary escrow-release authority.

Detection and audit pivots

  • Rebuild every multi-step verifier route into its actual independence graph: which DVNs are required, which observation stacks they read from, which failover providers they share, and whether any route still collapses to one operator or one poisoned RPC cohort in practice.
  • Ask the degraded-mode question directly: when clean RPCs fail or are DDoS’d, what exact rule decides whether the bridge halts or continues on narrower evidence? If continued operation can be triggered by forcing failover onto fewer or weaker sources, degraded mode is part of the custody surface.
  • Audit observability independence, not only verifier independence. If the same nodes can lie selectively to the verifier while telling the truth to dashboards, explorers, or alerting systems, then the bridge may be blind exactly when operators think it is healthy.
  • Reconcile source-side impossibility signals against every large bridge release: nonexistent nonces, missing PacketSent events, implausible source-side supply, or burn sizes larger than circulating supply should all page humans and narrow release authority fast.
  • Review the post-authenticity blast radius alongside the verifier path. If one forged release can still become deep-lending bad debt before governance or freezes land, the route needs tighter release caps, destination quarantine, or faster collateral derecognition after bridge anomalies.

Failure-prevention checklist

  • Ban 1-of-1 verifier configurations on custody-bearing routes unless the route is intentionally tiny and explicitly budgeted that way. The minimum trust policy should name independent verifier families, independent observation stacks, and separate admin domains rather than only counting signatures.
  • Treat RPC failover as a custody-policy change, not background reliability plumbing. If a route loses clean observer diversity, converges onto one provider cohort, or enters manual/degraded verification, automatically clamp release authority or halt until the route re-earns full trust; bridge-verifier-independence-inventory-and-degraded-mode-discipline is the positive-design companion.
  • Keep at least one monitoring and reconciliation path outside the live verifier cohort, and probe for selective-lie conditions rather than only total outages. A route is not healthy just because dashboards that query different IP ranges still look green.
  • Add source-side impossibility checks around large releases: nonexistent packet nonces, missing canonical PacketSent events, impossible burn sizes, or supply deltas larger than circulating source inventory should all block or sharply narrow execution.
  • Put route-local loss budgets in the live release path. Per-asset and per-route caps, staged large withdrawals, and emergency brakes should keep one forged packet from immediately accessing the full Ethereum escrow; bridge-bounded-release-design is the adjacent design note.
  • Quarantine fresh bridged inventory downstream when the route is young, operator-dependent, or anomalous. If counterfeit bridge output can instantly become high-LTV collateral, the real blast radius includes money markets, not only the bridge itself.

Audit prompts

  • If one verifier family, one RPC cohort, or one cloud-admin domain disappears right now, how many independent bridge-truth roots actually remain for this route?
  • What exact policy state is the route in when clean RPCs are DDoS’d or fail over — normal mode, degraded mode, or silent single-source operation — and which permissions shrink in each state?
  • Can a malicious node or provider selectively lie only to verifier IPs while explorers, dashboards, and general-purpose health checks keep seeing truthful state?
  • What concrete source-side impossibility checks would have blocked this release: nonexistent nonce, missing PacketSent, impossible source supply, or burn amount larger than live circulation?
  • How much value can one attested packet move before any human intervention, and where is that limit enforced in code rather than in runbooks?
  • Can fresh bridge output on this route immediately become borrow power, LP inventory, or other deep-liquidity exit capacity before the route has survived the observation window the protocol actually trusts?

Lessons that should already be standard

  • 1-of-1 verifier is not merely an operational shortcut. On a custody-bearing bridge route it is direct balance-sheet concentration.
  • Verifier signatures only deserve as much trust as the observation path that produced them. A clean endpoint contract does not save a route whose sole verifier can be shown counterfeit source reality.
  • Monitoring has to disagree with the live verifier on purpose. If dashboards and reconciliations cannot catch verifier-specific lies, everything looked healthy is not meaningful reassurance.
  • Degraded mode should shrink authority before it preserves liveness. A bridge that keeps full-value releases live after observer diversity collapses is choosing throughput over solvency.
  • Bridged assets with immediate downstream collateral value need route-aware quarantine and caps. Otherwise one forged release can become protocol-scale lending bad debt faster than the bridge operator can even finish pausing.

Why this incident matters

  • It is one of the clearest modern examples of a bridge failing at the verifier-input layer rather than at the token contract or the explicit signature-checking code.
  • It shows that one required verifier is not just a governance or ops smell; it is direct custody risk when that verifier’s own observation stack can be poisoned.
  • It also demonstrates how bridge failures now cash out through composability. The forged packet did not need to dump rsETH immediately; DeFi money markets monetized the lie faster and at larger size.
  • It also preserves the separate bounded-release lesson: once one poisoned verifier path released 116,500 rsETH from Ethereum escrow, that counterfeit inventory still had immediate line-of-sight to deep downstream borrow capacity instead of first hitting a tighter route cap, delayed release, destination quarantine, or borrow-side derecognition boundary.

Internal linkages

  • Core recurring pattern: verifier-input-independence-failure.
  • Sharper degraded-mode lens: degraded-mode-authenticity-failure — the attacker forced the route onto poisoned fallback observation before the forged packet was signed.
  • Sharper subfamily: verifier-input-independence-failure — the verifier itself was not enough; the real failure was that the route’s entire authenticity story collapsed onto one poisoned observation stack.
  • Positive-design independence companion: bridge-verifier-independence-inventory-and-degraded-mode-discipline — useful for the sharper design question of which verifier, observer, failover, and outage-mode combinations should ever have been allowed to define rsETH bridge truth.
  • Positive-design blast-radius companion: bridge-bounded-release-design — useful for the separate question of why one forged bridge release was still allowed to convert so quickly into protocol-scale bad debt across lending venues.
  • Related control-surface warning: operator-boundary-opacity — the user-visible trust story said LayerZero DVN, but the effective authenticity boundary also included the concrete RPC and failover stack feeding that verifier.

Control surface

Graph View

Backlinks