weETH Bridge Security Hardening

On April 18th, a forged cross-chain message released ~$292M in unbacked rsETH from Kelp DAO. No EtherFi systems were directly compromised, nor did EtherFi Liquid vaults have direct exposure to rsETH. Here's how.

ether.fi executed three protocol-wide hardening changes across all 20 weETH chains:

1. Pinned the LayerZero message libraries on every pathway, so LayerZero can no longer swap in a different send or receive library for weETH.
2. Pinned the DVN configuration and raised the DVN threshold to 4-of-4, so every inbound message must be independently verified by all four DVNs before it is accepted, and LayerZero can no longer alter the DVN set.
3. Tightened pair-wise rate limits on the ether.fi-owned bridge contracts themselves, bounding per-route throughput with a defense-in-depth cap that is fully under ether.fi control and independent of any bridge provider.

After these changes, every weETH bridge parameter that can authorize a mint or release of weETH is controlled exclusively by ether.fi multisigs. The per-chain addresses and the way to verify each one are in the appendix.

Background

LayerZero's EndpointV2 resolves each OApp's configuration in two layers: an OApp-specific slot, writable only by ether.fi, and a protocol-wide default, writable by LayerZero's 3/5 multisig. If the OApp slot is empty, resolution falls back to the default.

For weETH, both the message library, the contract that enforces DVN checks, and the DVN configuration, the set of required DVNs and their threshold, were resolving to LayerZero defaults. In principle, LayerZero's 3/5 multisig could have modified either. It could have swapped in a malicious library that ignored DVN verification, or altered the default DVN set directly, and weETH would have picked up the change on the next message.

No exploit occurred, and LayerZero's multisig has never moved against any integrator. ether.fi treated this as a latent risk worth closing proactively.

What Changed

1. Message library pinning

ether.fi executed `setSendLibrary` and `setReceiveLibrary` on every pathway across all 20 weETH chains, pinning the current `SendUln302` and `ReceiveUln302` addresses into the OApp-specific slots. The libraries are byte-identical to what was already in use via the defaults, so bridging behavior is unchanged. What changed is that the fallback path to LayerZero's default library is now closed. LayerZero's multisig can no longer swap in a different library that would ignore DVN verification.

2. DVN configuration pinning and 4-of-4 threshold

ether.fi executed `setConfig` on every pathway to pin the four-DVN set into the OApp-specific slot and raise the verification threshold to 4-of-4. All four DVNs are now `requiredDVNs` with no optional slots, so every inbound message must be attested by every DVN before the receive library accepts it. A single unavailable or malicious DVN now halts the message rather than being tolerated.

LayerZero's team independently reviewed and confirmed the configuration is correct and complete. The DVN set itself is byte-identical to what was already in effect via the defaults. The behavioral change is that (a) LayerZero can no longer alter the set, and (b) DVN verification is now strictly unanimous.

3. Pair-wise rate-limit hardening

In parallel, ether.fi tightened pair-wise rate limits on the ether.fi-owned bridge contracts so that every (source chain, destination chain) route enforces a conservative per-window cap on inbound and outbound weETH. These limits are set and enforced on contracts ether.fi fully controls, so they hold regardless of how any upstream messaging provider behaves.

The rate limits cap how much weETH can move on any single route within a time window. They are one layer of a defense-in-depth design, not the only one: ether.fi runs continuous onchain monitoring (Hypernative) that detects an anomalous mint or transfer in real time, and the affected route can be paused before a single-window event can repeat across successive windows. The rate limit bounds the size of any single-window failure; monitoring and pause keep it from compounding.

Post-Execution State

• Send library — controlled by ether.fi Safes. Pinned.
• Receive library — controlled by ether.fi Safes. Pinned.
• DVN config — controlled by ether.fi Safes. Pinned, with the verification threshold raised to 4-of-4 (Canary, Horizen, Nethermind, LayerZero Labs).
• Pair-wise rate limits — controlled by ether.fi Safes. Hardened, enforced on ether.fi-owned contracts, independent of any bridge provider.

Bottom Line

The LayerZero multisig no longer has any onchain path to change how weETH messages are verified or authorized. The message libraries, the DVN set and 4-of-4 threshold, and the pair-wise rate limits are all controlled by ether.fi multisigs. If any upstream stack ever failed, pair-wise rate limits cap per-window throughput and continuous monitoring pauses the affected route before a single-window failure can compound.

Next Steps

The changes above close the LayerZero-specific fallback risk and bound blast radius. Two structural exposures remain, and ether.fi is actively working on both.

1. Multi-provider quorum. weETH bridging still depends on a single messaging stack. To remove that single point of failure, ether.fi is evaluating a second independent bridge provider, such as Chainlink CCIP or Wormhole, alongside LayerZero. Crosschain messages would then require attestation from a quorum of independent providers before being accepted, so no single bridge stack, LayerZero included, can unilaterally authorize a mint or release of weETH. This moves weETH to a no-single-provider trust assumption.
2. L2 chain risk assessment and deprecation. A bridged asset is only as safe as the chains it lives on. A compromised L2 sequencer, upgrade key, or settlement assumption on any connected chain is a risk surface for weETH holders across the entire mesh. ether.fi is assessing every chain weETH is deployed on and will begin deprecating the ones whose trust assumptions it is no longer comfortable underwriting, in coordination with the L2 teams and the broader security community.