DEV Community

ohmygod
ohmygod

Posted on

The Resolv Labs USR Exploit: How a Compromised AWS Key Printed $25M in Unbacked Stablecoins

#security #blockchain #web3 #defi

TL;DR

On March 22, 2026, an attacker compromised Resolv Labs' AWS KMS infrastructure, gained control of a privileged minting key, deposited ~$200K in USDC, and minted 80 million unbacked USR tokens — extracting roughly $25 million in ETH. The smart contract code was never exploited. It worked exactly as designed. That's the problem.

The Architecture That Failed

Resolv's USR stablecoin uses a two-step minting flow:

  1. requestSwap — User deposits USDC into the USR Counter contract
  2. completeSwap — An off-chain service (the SERVICE_ROLE key) calls back to finalize how much USR to mint

Here's what the contract enforced:

  • ✅ Minimum USR output (floor)
  • ✅ Valid signature from the SERVICE_ROLE key
  • ❌ No maximum mint ratio
  • ❌ No on-chain oracle check
  • ❌ No per-transaction or per-block mint cap

In other words: whatever the key holder signed, the contract minted. No questions asked.

The Attack Chain

Step 1: Infrastructure Compromise

The attacker didn't touch the smart contract. They went after the cloud infrastructure — specifically Resolv's AWS Key Management Service (KMS), where the SERVICE_ROLE private key was stored. Once inside the KMS environment, the attacker could sign any minting operation they wanted.

Step 2: The 500x Mint

Armed with the signing key, the attacker executed two primary transactions:

Transaction USDC Deposited USR Minted Ratio
Tx #1 ~100K USDC 50M USR ~500x
Tx #2 ~100K USDC 30M USR ~300x

Total: 80 million USR minted from roughly $200K in collateral.

Step 3: The wstUSR Conversion

Instead of dumping 80M USR directly into DEX pools (which would immediately crash the price and limit extraction), the attacker converted USR → wstUSR (wrapped staked USR). This derivative represents a share of the staking pool rather than a fixed token count — a smarter extraction vehicle.

Step 4: Cash Out

From wstUSR, the attacker rotated through multiple DEX pools:

USR → wstUSR → USDC/USDT → ETH
Enter fullscreen mode Exit fullscreen mode

Final attacker wallet holdings:

  • ~11,400 ETH (~$24M)
  • ~20M wstUSR (~$1.3M at depressed prices)

The USR peg collapsed to $0.025 at its lowest — a 97.5% depeg.

The Root Cause: Off-Chain Trust Without On-Chain Guardrails

This exploit belongs to a growing category I call "trusted backend" attacks. The pattern:

  1. Protocol delegates critical logic to an off-chain component
  2. Smart contract trusts whatever the off-chain signer says
  3. Attacker compromises the signer, not the contract
  4. Contract executes perfectly — minting exactly what was "authorized"

The fix isn't complicated. Any one of these on-chain checks would have prevented the exploit:

// Option 1: Hard ratio cap
require(
    usrAmount <= usdcDeposit * MAX_MINT_RATIO,
    "Mint ratio exceeded"
);

// Option 2: Per-block mint limit
require(
    blockMinted[block.number] + usrAmount <= MAX_PER_BLOCK,
    "Block mint cap exceeded"
);

// Option 3: Oracle-validated pricing
uint256 fairValue = oracle.getPrice(USDC) * usdcDeposit;
require(
    usrAmount <= fairValue * 105 / 100,  // 5% tolerance
    "Exceeds oracle-validated amount"
);
Enter fullscreen mode Exit fullscreen mode

Lessons for Protocol Developers

1. Never Trust Off-Chain Alone

If your minting, burning, or transfer logic depends on a single privileged key — even one stored in HSM/KMS — you need on-chain invariant checks as the final line of defense. The contract should encode business logic constraints, not just signature validation.

2. Implement Circuit Breakers

A 500x deviation from expected behavior should trigger an automatic pause. Time-locked mint caps, anomaly detection thresholds, and automated pause mechanisms exist precisely for this scenario.

3. Defense in Depth for Key Management

The SERVICE_ROLE key should have been:

  • Behind a multi-sig (requiring 2-of-3 or 3-of-5 signers)
  • Rate-limited at the KMS policy level
  • Monitored for unusual signing patterns
  • Rotated regularly with the old key revoked on-chain

4. Real-Time On-Chain Monitoring

Even with all the above, monitoring tools like Hexagate, Forta, or custom alert systems should watch for:

  • Mint-to-deposit ratio anomalies
  • Sudden supply inflation
  • Unusual privileged role activity patterns

With monitoring in place, the attack could have been caught after Transaction #1 (~$8M exposure) instead of running to completion ($25M).

The Bigger Picture: Q1 2026 Exploit Trends

The Resolv hack fits a pattern. In Q1 2026, over $137 million has been lost across 15+ DeFi protocols. The common thread isn't reentrancy or arithmetic bugs — it's trust assumptions:

  • Resolv Labs: Trusted an off-chain key → $25M lost
  • Venus Protocol: Supply cap bypass via oracle manipulation → $3.7M lost
  • AAVE: Oracle misconfiguration for wstETH → $1M in bad liquidations
  • Foom Cash: ZK verifier misconfiguration → $2.3M lost

The OWASP Smart Contract Top 10: 2026 confirms this shift. Access Control Vulnerabilities now rank #1, and Reentrancy has dropped to #8. The attack surface has moved from code-level bugs to architecture-level trust failures.

For Auditors: What to Check

When auditing protocols with off-chain components:

  • [ ] Does the contract enforce invariants independent of the signer?
  • [ ] Are there per-transaction, per-block, and per-epoch mint/burn limits?
  • [ ] Is the privileged key behind a multi-sig or timelock?
  • [ ] Does the contract have a circuit breaker / emergency pause?
  • [ ] Are oracle checks enforced on-chain, not just off-chain?
  • [ ] Is there real-time monitoring for anomalous privileged operations?

The Resolv exploit wasn't a code bug. It was an architecture bug. And those are the ones that keep getting more expensive.

Top comments (0)