Design for Adversity

TL;DR

On 22^nd March 2026, Resolv Labs’ USR stablecoin suffered a significant exploit. An attacker compromised Resolv’s offchain infrastructure, gaining control of a SERVICE_ROLE key and minting 80 million unbacked USR tokens against only 200K USDC, extracting roughly $23–25 million before USR depegged sharply to as low as ~$0.05 on certain venues. The protocol was paused several hours later once multisig signing was coordinated.

This incident highlights a critical principle for DeFi: even well-audited smart contracts can produce severe outcomes when offchain trust assumptions fail. In the spirit of shared learning, we outline key design principles that can help mitigate such risks - including onchain bounds, atomic collateral tying, and fast automated containment. These are the approaches Ethena has adopted since day one to ensure our system remains economically sound even under adverse conditions. We share this transparently to help the community raise security standards for DeFi builders generally.

The Incident: What Happened?

On 22^nd March 2026 (all verifiable onchain):

• The attacker deposited ~$200K USDC and called requestSwap on TheCounter contract.
• Using the compromised SERVICE_ROLE EOA (unchanged since December 2024 and stored on offchain infrastructure), they called completeSwap twice.
• The contract accepted massively inflated _targetAmount parameters with no hard onchain upper bound or collateral-ratio check, minting ~50M USR in one transaction at 02:21:35 UTC and ~30M in the next at 03:41:47 UTC.
• The minted USR was wrapped to wstUSR, sold across DEXes, and converted to ETH.
• USR depegged within minutes (to ~$0.05 on some pools).
• Resolv’s admin multisig paused the protocol after several hours of coordinating signers.
• Later, via a wstUSR contract upgrade, an additional ~36M wstUSR held in four exploiter-associated wallets were blacklisted.
• A final burn of the remaining unbacked USR was executed.
• In total, these containment actions removed roughly $45M (nominal value at peg) of unbacked USR supply from circulation.

The contracts executed valid, signed instructions perfectly. It appears the key vulnerability lay in treating inputs from offchain infrastructure as authoritative without independent onchain safeguards. This allowed unbacked supply to be created at scale before any meaningful response was possible.

When Onchain Execution Meets Offchain Input

The exploit was not a cryptographic failure or hidden bug. It exposed a fundamental question: where does the system place trust, and what happens when that boundary is crossed?

In Resolv’s two-step minting flow (requestSwap → offchain SERVICE_ROLE signature → completeSwap), the contract enforced the externally supplied _targetAmount without additional constraints. Once the key was compromised, the attacker could bypass economic checks entirely. With only a small collateral deposit, they stepped into the role of the system itself and minted tens of millions in new tokens before the protocol (or its stewards) could respond.

Modern DeFi systems increasingly rely on offchain inputs - price feeds, execution services, and coordination layers. These are often necessary abstractions, yet they raise a question that is easy to overlook: What happens if the offchain inputs are compromised?

In Resolv’s design, it appears an offchain service effectively determined how much supply should be minted, and the onchain system enforced that decision without applying independent constraints. This created a structural dependency in which the integrity of the protocol execution was tied directly to the integrity of a single external actor. Under normal conditions this works seamlessly; under adversarial conditions it becomes a single point of failure. Once that boundary is crossed, the system has no built-in mechanism to reclaim control.

Designing for Adversarial Conditions

Rather than asking whether offchain systems can be trusted, teams should design assuming they can fail - via compromise, bug, or error - and ensure the protocol remains economically sound regardless.

This principle guides Ethena’s issuance mechanics. Minting is strictly constrained by verified collateral, enforced entirely onchain. Importantly, only known KYC approved entities are whitelisted to interact with the mint and redeem smart contract. No external input (signed message, service response, or price signal) can override that atomic relationship: value created must be matched by value provided.

To make the system more resilient and robust, protocols can strengthen resilience through choices such as:

• Enforcing mint/redeem logic fully onchain with strict bounded parameters (e.g., hard upper limits and collateral-ratio checks on price).
• Tying issuance directly to verifiable, deposited collateral and onchain accounting - rather than externally supplied targets.
• Avoiding single points of failure in offchain infrastructure that can unilaterally determine final output.

The below table illustrates these design principles in practice:

We further layer rapid containment:

• Rate limiting on new supply to cap damage from any single failure, turning potential instant collapse into a detectable event with reaction time.
• Independent monitoring systems that automatically intervene when invariants are threatened. Internal operators and our distributed GATEKEEPER_ROLE track health in real time and can halt mint/redeem activity within one Ethereum block (~12 seconds) - orders of magnitude faster than multisig coordination.

This model reduces sensitivity to any single data source or transient issue through stricter onchain pricing constraints and conservative caps.

A robust model should treat external inputs as suggestions, not authority, and enforce core economic properties where they cannot be bypassed: onchain.

Building a Secure DeFi Community

As DeFi grows more complex, offchain dependencies will increase. The key question is not whether they exist, but whether the system can tolerate their failure.

Ethena is committed to securing our infrastructure while fostering a safer ecosystem. We encourage projects, security teams, and builders to collaborate on best practices, emerging threats, and mitigation strategies. If you’re interested in joining efforts around issuance security, reach out through secure channels to us directly.

As for other builders, we would caution that simply forking onchain smart contracts from Ethena, or any other protocol, is likely both insufficient and insecure, unless the smart contracts do not rely on any external / offchain actions or actors. If you do wish to fork Ethena’s smart contracts, please reach out to us directly and we can provide feedback on the implementation of your offchain components free of charge.