Design for Adversity: Lessons from the rsETH Incident

In the spirit of our earlier post on building systems that assume compromise at every layer, we’re sharing a transparent, engineering-first look at the recent Kelp DAO / LayerZero OFT exploit, our response, and why Ethena assets and infrastructure were not susceptible to the same risks.

The Incident in Brief

On 18 April, 2026, approximately 116,500 rsETH (~$292 million at the time) was drained from Kelp DAO’s Ethereum escrow via its LayerZero OFT bridge. The attack forged a cross-chain message that appeared to originate from Unichain but had no corresponding emission on the source chain.

Preliminary third-party analysis points to two compounding causes: a 1-of-1 DVN configuration (here, LayerZero’s DVN as the sole verifier) and a sophisticated compromise of the RPC infrastructure feeding the DVN. A single compromised verification path was sufficient to authenticate and execute a massive unauthorized release. The fallout included bad debt in lending protocols, paused markets, significant TVL drops across DeFi, and a broad industry response with freezes and a coordinated recovery effort.

This was not a smart contract vulnerability in the core token logic but a configuration and infrastructure failure in the bridging setup. It underscores a core truth in cross-chain design: verification is everything, and single points of failure (or even low-quorum setups) are unacceptable for high-value assets.

Ethena’s Immediate Response

Ethena was among the first major issuers to pause LayerZero OFT bridges as a precautionary measure. Thanks to automated alerting (including Hypernative integration) and tight incident response processes, the bridge was paused within roughly 2 hours of the initial exploit transaction, even with incomplete public information.

• Automated detection: Real-time monitoring of on-chain invariants, packet anomalies, and large transfers.
• Swift action: Paused OFT bridges. Other issuers followed our lead in the hours after.
• No user impact: USDe remained fully backed and operational. Bridging was re-enabled after upgrades (detailed below).

This rapid containment minimized any potential contagion for the Ethena ecosystem.

Core Design Principles: Assume the Attacker Is Already Inside

Our architecture starts from one adversarial assumption: the attacker is already inside. Every layer is built to remain safe even when layers above or below it have been compromised.

Key constraint we design with: No single mistake, compromise, component, or subset of participants below quorum should be enough to push a malicious transaction.

We design against:

• Device compromise
• Channel attacks
• Human vectors
• Vendor risk
• Supply-chain risk
• State-level adversaries

Multiple independent checks and verification at every layer. Automated monitoring, cross-checks intent against invariants in real time in addition to human verification. On-chain final backstops ensure off-chain issues do not become on-chain losses.

Our LayerZero / OFT Setup: Rate Limits + High-Quorum DVNs

Unlike the 1-of-1 configuration exploited in the incident, Ethena has always prioritized defense-in-depth for bridging:

• 4/4 DVN Quorum with Implementation Diversity. Ethena already ran a 2/2 DVN setup from launch and upgraded post-incident to require 4/4 consensus among independent Decentralized Verifier Networks. This means an attacker would need to simultaneously compromise four distinct verification operators with diverse implementations to forge a valid message. Our DVN stack includes multiple implementations, notably the addition of Canary for added diversity. Several DVNs (such as Horizen and Nethermind) use multisignature security models, and we continue evaluating options with cryptographic proof-based verification where supported.While additional DVNs introduce a minor liveness tradeoff (a faulty DVN could delay, but not lose, a transfer), any problematic DVN can be removed quickly. For high-value assets, this security gain far outweighs the operational cost.
• Proactive Rate Limits. Contract-enforced rate limits of $10 million per hour per route. These act as a hard circuit breaker, strictly capping maximum exposure even in the hypothetical case of a full DVN compromise. Most issuers had not enabled equivalent limits prior to the incident.
• Route Minimization & Explicit Whitelisting. Only essential routes are active (primarily Ethereum ↔ supported chains, plus targeted paths). All other pathways are explicitly disabled, eliminating dormant attack surfaces.
• Active Route Culling & Chain Sunsetting. Ethena does not treat bridge routes as permanent infrastructure. Routes are reviewed against actual USDe, sUSDe, and ENA supply, real usage, strategic relevance, and operational security overhead. Chains with negligible supply or limited strategic need can be deprecated and sunsetted, reducing dormant infrastructure and preventing legacy integrations from becoming unnecessary long-tail risk.
• No Third-Party Controlled Configuration. By default, LayerZero applications rely on send and receive libraries that can be updated via the LayerZero Endpoint (under a LayerZero multisig). In our setup, we explicitly pin the send and receive libraries for every pathway and made them immutable against any third-party multisig or external logic. This removes external administrative vectors and further reduces our trust surface.

The result: USDe was structurally protected against this attack vector. Compromising the Ethena asset bridge requires simultaneous breaches of multiple independent operators - not a single endpoint, default path, or admin control. Post-incident upgrades like increasing the required DVNs and expanding coverage of pinned LZ libraries further reduced the trust surface while preserving user experience.

Broader Architecture: Minimal On-Chain Surface + Robust Off-Chain Controls

Our philosophy extends far beyond bridging:

• Small smart contract surface area: Significant capital is managed in non-smart contract MPC custody. Mint/redeem contracts are whitelist-gated, extensively audited (7+ phase process with multiple firms and a $3M+ ongoing bug bounty), and protected by the Ethena Gatekeeper Network.
• Gatekeepers: Geographically and operationally distributed. Any single Gatekeeper can pause mint/redeem within ~1 block (~12 seconds) on adverse pricing or anomalies. They cannot re-enable or take other actions. Does not require Ethena team members to respond with a drawn out manual multisig process.
• Custody: Tri-party Off-Exchange Settlement (OES) with top institutional custodians. Trading venues never hold collateral directly. Monthly attestations + weekly Proof of Reserves by multiple external attesters.
• Off-chain infrastructure: Hardened endpoints, phish-resistant MFA, workload isolation, EDR/MDM, least-privilege access, SIEM, regular audits, and a "pause first, investigate second" incident posture.

This combination - minimal on-chain code touching capital, strong off-chain controls, and on-chain backstops-makes pure on-chain exploits far less impactful than in protocols with larger smart contract footprints.

Guidance for Other Issuers and Protocols

1. Never run 1-of-1 (or low-quorum) DVNs for material value. Move to multi-DVN with diversity immediately.
2. Implement rate limits at the contract level on OFT transfers. $10M/hour (or calibrated to your liquidity/risk) provides a critical circuit breaker.
3. Minimize and explicitly whitelist routes. Disable anything unused.
4. Build automated alerting + pause mechanisms. Human response is too slow against sophisticated actors.
5. Assume compromise: Design so that a single vendor, RPC, or signer failure cannot drain funds.
6. Regular configuration audits: DVN setups, executors, and libraries should be pinned, monitored, and reviewed continuously.

LayerZero provides powerful flexibility. With that comes responsibility for secure configuration.

Looking Forward

We have upgraded to stricter DVN quorums, maintained tight rate limits, and continue exploring cryptographic-proof DVNs and further diversity. Our core product (USDe) remains over-collateralized, transparently attested, and backed by institutional-grade custody.

Security is never "done"- it is an ongoing process of hardening against evolving threats. By sharing these details openly, we aim to raise the bar for the entire ecosystem.

We build for adversity because users deserve systems that survive it.