Resolv Protocol: Incident Report by Nexus Mutual

At 02:21 UTC on Sunday, March 22, an attacker deposited roughly $200,000 in USDC into the Resolv protocol. The protocol minted 80 million USR in return. Within 17 minutes, USR crashed from $1.00 to $0.025 on Curve Finance. The attacker walked away with approximately $23 - 25 million. Eighteen audits had reviewed Resolv's contracts. All of them confirmed the code worked as designed. The attack surface wasn't the smart contract. It was a private key stored in AWS.

What happened

Resolv's minting flow worked in two steps:

Step 1 - requestSwap: A user deposits USDC into the USR Counter contract and specifies a minimum acceptable amount of USR. This creates a pending swap request. Anyone can call requestSwap() - there's no provider whitelist.

Step 2 - completeSwap: An off-chain service operating under the SERVICE_ROLE calls completeSwap to finalize the mint, specifying the exact USR amount. An attacker gained access to that key through Resolv's AWS Key Management Service environment, called completeSwap directly, and minted 80 million USR against $200,000 in collateral. The contract verifies only that the caller holds the SERVICE_ROLE and the minted amount meets or exceeds the user’s minimum.

The contract had no oracle checks, no per-transaction mint limits, and no collateral ratio validation. Everything worked exactly as written. Nothing worked as intended.

This puts Resolv alongside Step Finance (January 2026) and Swissborg/Kiln (September 2025) as incidents that primarily revolved around operational security failures, not smart contract bugs.

How the damage spread

The attacker converted freshly minted USR into approximately 11,400 ETH across Curve, KyberSwap, Uniswap, and Velodrome. But the contagion didn't stop with Resolv.

Lending protocols across DeFi were using Resolv's NAV-based oracle, which hadn't updated since 15 hours before the exploit. With the oracle still reporting USR at $1.00, investors could deposit depegged USR as collateral and borrow at full face value. The result across Morpho: four USR and wstUSR collateral markets now sitting at 100% utilization with $0 available liquidity, representing approximately $7.77M in locked lending exposure. Fluid confirmed bad debt and has committed to covering its users' losses in full. Euler took precautionary action, disabling RLP as collateral in affected vaults.

It's worth separating two categories of exposure here. USR and wstUSR lending positions are directly impacted by the depeg. RLP, Resolv's junior tranche, is a different story: if Resolv successfully burns the illicitly minted USR and restores pre-incident supply levels, RLP holders may not face permanent losses. That outcome depends on Resolv's recovery execution.

What should have been different

Onchain mint limits and a time-lock on large mints would have stopped the attack at the contract level, even after the key was compromised. Off-chain, key rotation schedules and anomaly monitoring on the SERVICE_ROLE would have provided early warning.

The oracle design amplified the damage downstream. A NAV-based oracle updating every 24 hours isn't appropriate for an asset used as collateral in lending markets. Staleness checks that automatically freeze positions when oracles exceed defined thresholds would have contained the second-order losses. Backup oracles, so markets can switch feeds when a primary becomes stale, should be standard practice, not optional.

Does Nexus Mutual cover this?

The core loss event on Resolv, theft of a private key and unauthorized minting, isn't covered under Nexus Mutual Protocol Cover. Protocol Cover addresses smart contract vulnerabilities: code that behaves in unintended ways. This attack exploited operational security. The contracts worked exactly as written. Resolv Protocol Cover has never been available. Instead, our team opted to provide Resolv USR Depeg Cover due to the nature of Resolv's yield strategy.

The downstream bad debt in lending markets is a different story. When fixed-rate oracles are not updated to reflect the true value of an asset, prevent liquidation of unhealthy borrow positions, and bad debt is socialized across lenders, that's a covered event under Protocol Cover's liquidation failure clause. Investors who held Protocol Cover on affected lending markets are covered for those losses.

Nexus Mutual listed USR Depeg Cover in September 2025. At the time of the exploit, there was no active cover for the Resolv USR Depeg Cover listing. Investors who had previously held depeg cover let it lapse, citing lower DeFi yields as making the cost feel unjustified. That reasoning confuses the yield environment with the risk profile. Nexus Mutual prices cover based on its assessment of the probability of loss, not the prevailing APY. A higher yield doesn't make a stablecoin safer.

No claims have been received as a result of this event. We'll provide an update if that changes.

If you hold DeFi positions

If you have exposure in lending markets that used USR or wstUSR as collateral, check whether those protocols are listed on Nexus Mutual. Liquidation failures in listed markets are covered if you held active cover when the bad debt originated. If you hold stablecoin positions and aren't covered, USR Depeg Cover terms require a 20% or greater depeg sustained for at least seven days. According to CoinGecko, USR has depegged by 70-80% in the last two days. Whether the depeg holds for seven days depends on Resolv's recovery plan.If you hold RLP, the situation is different. Resolv has stated the collateral pool is intact. Recovery depends on whether the illicit USR supply can be fully burned. It's a live situation and worth monitoring closely.

Nexus Mutual has paid 100% of valid claims since 2019. That record exists because we're precise about what we cover and honest when we're not. If your positions aren't covered and you want to know why, reach out at nexusmutual.io/contact.

Appendix: Why parametric cover isn’t the solution

Two questions come up regularly: why does Nexus Mutual have a 14-day waiting period before filing a claim, and why don't we use fully parametric claims triggered automatically by onchain events? The Resolv incident answers both.

Twenty-four hours after the exploit, sophisticated investors were still working out what they'd lost and where. Mapping direct USR losses, second-order bad debt in lending markets, and positions frozen at stale oracle prices takes days. The 14-day window isn't a bureaucratic delay. It exists so that members can establish the full picture before they file. It also allows the Nexus Mutual Claims Committee to review the available onchain data and post-mortems, as well as help members calculate their claim amount when claim filing opens.

On parametric claims: the case for automated triggering is compelling in theory. But serious underwriting depends on visibility into reimbursements from the impacted protocol. In the Resolv case, this can take multiple days, maybe weeks. Fluid has already committed to covering bad debt in full, but it remains to be seen what other protocols downstream will do. A parametric trigger for the USR depeg would have fired before any of that was known. For the downstream impact on lending protocols, what oracle solution can account for bad debt scenarios when the cause of bad debt is a fixed-rate oracle used in lending markets? Parametric cover cannot handle complex loss events and cannot take into account reimbursement plans. Parametric triggers do not balance incentives between underwriters and cover holders, which results in mispriced risk. Mispriced risk makes it harder to attract, and retain, underwriting capital and results in higher premiums on a longer time horizon.