Resolv Labs USR Depegging Incident: Explained

First, the minting flow depended on an off-chain service that held a privileged signing key. Then, the on-chain contract failed to enforce a hard cap on how much USR could be minted compared with the collateral that users deposited. In practice, that meant the contract trusted the privileged signer too much.

Next, the attacker appears to have compromised the off-chain environment, which many reports describe as key management infrastructure. With that access, the attacker could approve an inflated mint amount during the final on-chain step.

Because of that, most analysts describe the incident as an infrastructure or private key compromise, not a traditional Solidity bug.

For crypto normies, the easiest way to think about it is this. USR tokens were like receipts. If someone can print fake receipts without depositing the actual goods, which in this case means collateral, then the system can no longer redeem every receipt at full value. As a result, the market price falls, and the issuer has to pause or change the redemption process.

Timeline of what happened and how

The table below uses UTC (block explorer timestamps)  for convenience. The exploit and immediate market collapse played out in minutes to hours.

How The Exploit Worked

The two-step mint process was the key design choice.

According to Chainalysis, users minted USR through a two-step flow.

First, requestSwap let a user deposit collateral, often stablecoins like USDC, into the USR Counter contract.

Then, completeSwap let an off-chain service with a privileged key, called SERVICE_ROLE, finalize how much USR the user would receive.

This kind of setup is common when a protocol needs off-chain checks for things like custody, market execution, or compliance. However, it also creates a major dependency. The privileged signer cannot be compromised.

On-chain data also shows why the unchecked mint amount mattered so much.

In the first minting transaction, the Etherscan-decoded call was:

completeSwap(bytes32 _idempotencyKey, uint256 _id, uint256 _targetAmount)

Here, _targetAmount was the key parameter. It effectively determined how much USR the protocol would mint. In the exploit transaction, the privileged signer called completeSwap(), and the logs showed 50,000,000 USR minted even though only 100,000 USDC was transferred in. Then the same pattern appeared again in the 30,000,000 USR mint.

Because of that, analyses, including discussions around a possible Amazon Web Services, or AWS, compromise, describe the incident in a simple way. The attacker did not break the Solidity code itself. Instead, they took over the authority that the Solidity code was built to trust.

This also helps explain why audits did not stop the incident.

The case is often used to show the difference between two very different statements.

One is: the contract has no re-entrancy, arithmetic, or access control bugs.

The other is: the full system, as deployed in the real world, is safe.

But How?

DL News reported that risk analysts, citing Credora’s analysis, said the immediate cause was operational risk tied to a single privileged access key with unchecked mint authority. They also argued that the damage became worse because the protocol lacked on-chain safeguards that could have limited losses even if that key was compromised.

Resolv had many public audits listed. Even so, this incident shows an important lesson. Audits often focus on whether the code works as written. They do not always fully address how much damage a compromised key or off-chain system can cause.

The attacker’s flow of funds followed a pattern that public reporting broadly agrees on.

First, the attacker deposited a small amount of collateral. Then they minted a huge amount of USR. After that, they converted it into staking or wrapped USR versions. Next, they swapped into major stablecoins, bought ETH, and spread the funds across multiple wallets.

Below is a beginner-friendly map of that flow using the contracts and wallets that public on-chain evidence mentions most often.

Key on-chain anchors for this flow:

• The mint transactions and privileged caller address: 
• The attacker-labeled wallet holding wstUSR and small remaining USR: 
• A consolidation wallet holding 11,408+ ETH

Impact On USR Price

CoinGecko’s daily history shows that USR traded very close to $1.00 through March 21. Then, on March 22, it closed at about $0.302. After that, it stayed in a range of roughly $0.26 to $0.30 through March 25 as the market reacted to the exploit. CoinGecko also lists an all-time low of about $0.1419 on March 22, which matches the sharp depeg seen during the incident.

At the same time, one detail matters here. The price was not the same everywhere. It varied a lot depending on the trading venue and the amount of liquidity available. On-chain pools with low liquidity can swing very fast and print extreme prices in a short time. Because of that, different tracking sites may show different spot prices depending on their method and which venues they include.

CoinGecko’s public Price History table gives daily closing price and volume, but it does not provide full daily OHLC data. Because of that, the candlestick plot below is only an approximation. In this approach, the open is set as the prior day’s close. Then, the high and low are set as the max and min of the open and close. For March 22, the low is replaced with CoinGecko’s known all-time low of $0.1419 so the chart reflects the intraday crash more accurately.

Meanwhile, daily trading volume jumped sharply right after the incident. CoinGecko shows about $20.9M in volume on March 23. By comparison, daily volume in the surrounding days was usually well below $1M.

Loading chart...

DEX liquidity and why the peg broke so hard

Curve Finance pool data for the USR/USDC pool on Ethereum, as tracked by GeckoTerminal, shows very thin liquidity, only in the tens of thousands of dollars. As a result, a print-and-dump event could move the market very quickly. Thin liquidity changes everything.

First, even relatively small sell orders can push the price down hard. Second, arbitrage becomes much harder and riskier when redemptions are paused. Third, panic selling can feed on itself and create a reflexive downward spiral.

Supply and token accounting signals

On-chain token pages also show that supply and market cap figures changed meaningfully after the incident. That reflects the fact that a large amount of unbacked supply entered the system and then had to be addressed. In practice, that usually means some mix of freezes, invalidation, burning, or a split between pre-incident and post-incident tokens. Resolv’s own messaging around allowing redemptions for pre-incident USR strongly suggests that this kind of segmentation approach was part of the response.

Impact On Resolv And Partners

Although the headline number is “$80M exploit,” that figure is better understood as the face value of the unbacked USR that was minted. In reality, the attacker likely extracted much less. That is because selling into markets with limited liquidity pushes the price down very quickly.

As a result, public reporting usually places the attacker’s realized proceeds closer to $23M, according to Chainalysis, while ecosystem hack trackers put the number around $24.5M. On-chain data also supports that lower realized figure. For example, an attacker-linked wallet labeled “Resolv Exploiter 2” held 11,408.85 ETH, which Etherscan valued at roughly $24.6M at the time that page snapshot was served.

Operational impact

In response, the protocol had to pause key components, and its live metrics reflected a system operating in crisis mode. DeFiLlama showed a hack entry dated March 21 or 22, 2026, with losses of $24.5M. It classified the technique as a private key compromise and the broader category as infrastructure.

At the same time, DeFiLlama displayed 24-hour fees and revenue at $0. It also showed tracked yields at 0%. That likely reflected paused or disabled product functions, rather than a normal change in market conditions.

This matters because stablecoin systems are trust-based products. Pausing minting and redemption may be necessary to stop further damage. However, it also removes the normal peg repair mechanism. Without mint and redeem arbitrage, the price can keep drifting lower in the open market.

Reputational impact and risk-management fallout

Before the exploit, Steakhouse Financial had published an economic and operational overview of Resolv on March 17. After the incident, it added an update saying that one of the risks it had highlighted had in fact materialized. The update also repeated that the backing collateral was not compromised.

That is reputationally damaging for two reasons. First, it suggests that the core failure mode was already known or at least knowable. In this case, that means key compromise combined with unchecked authority. Second, it shifts attention away from the idea of a random one-off hack. Instead, it raises deeper questions about system design and governance maturity.

Partner and protocol contagion channels

Stablecoins are often used as collateral across DeFi lending markets and structured products. Because of that, when a stablecoin loses its peg, the risk of contagion depends heavily on the surrounding infrastructure. In particular, it depends on oracle design, liquidation systems, and whether partner protocols have circuit breakers in place.

Nexus Mutual’s investigation points to one especially important contagion pattern. It says an oracle-related issue, specifically a lagging or stale NAV-based oracle, allowed depegged USR to still be treated as worth about $1 in some settings for a period of time. As a result, users could take on toxic borrowing positions and create liquidity stress. In some cases, markets reportedly reached 100% utilization and funds became locked.

DL News also stressed that multiple protocols had integrated USR. It further noted that curator-style models can amplify risk once assumptions about an asset break down.

What Has Happened Since?

Public communications and immediate containment

In its official Important Notice, Resolv said the incident involved about 80M USR of uncollateralized minting. It also said the collateral pool remained intact. At the same time, the team said it was working through its incident response process.

After that, both Resolv’s own ecosystem dashboards and third-party trackers described the incident as a key compromise or infrastructure issue. That matches the broader view that the real failure happened in the off-chain trust layer.

Redemptions and pre-incident USR

One of the most important reported steps was Resolv’s plan to enable redemptions for pre-incident USR. This process was expected to begin with allowlisted users, while affected users were told to coordinate with RDAL.

For beginners, this is a very important point. If fake receipts are already in circulation, then the issuer cannot simply promise $1 for every receipt. That only works if it either recovers most of the stolen value, invalidates the fake receipts, or spreads losses across everyone through a haircut. In that context, pre-incident redemption suggests that Resolv was aiming for some version of invalidating the counterfeit claims rather than treating all USR equally.

Recovery attempt and negotiation posture

At the same time, several outlets reported that Resolv adopted a whitehat-style recovery posture. In practice, that meant a limited-time offer or ultimatum. The attacker could return most of the funds and keep a smaller bounty.

This is a common playbook in DeFi incidents. First, it creates a public and on-chain record of the project’s intent. Then, it can slow the attacker’s cash-out if exchanges and other platforms begin monitoring the addresses. It also gives the team more time to coordinate with centralized venues and ecosystem partners.

Audits and the patch details reality check

Resolv had a large public audit footprint. Even so, the real remediation challenge here was not just about patching a single Solidity bug. Instead, it was about redesigning trust boundaries and reducing blast radius.

That likely means moving privileged signing away from a single key and toward multi-party controls. It also means adding on-chain mint caps, rate limits, and max-output checks. In addition, it means setting up monitoring that can automatically pause the system when mint ratios look abnormal, such as a $100k deposit producing tens of millions in minted tokens.

As of the sources reviewed through March 26, 2026, the best documented response steps were pause and containment, partner coordination, and the pre-incident redemption plan. By contrast, there was still no fully published technical post-mortem that clearly described a redesigned mint architecture.

Plausible Future Scenarios And Recommendations

Scenario: substantial recovery and a credible redesign

If Resolv recovers a meaningful share of the attacker’s proceeds, whether through negotiation, exchange freezes, or legal action, it could improve the outcome in several ways.

First, it could support redemptions for a larger share of holders. Next, it could recapitalize the system, either directly or through some form of restructuring. Then, it could start rebuilding relationships with partners that paused or limited integrations.

However, this outcome depends on more than recovery alone. It also requires clear proof that the system has changed. In other words, Resolv would need to show more than fresh audits. It would need to show that key-risk blast radius is materially lower. That means multi-signature controls, on-chain mint caps, verified mint-to-collateral checks, and strong real-time monitoring.

Scenario: partial recovery and permanent segmentation or haircuts

A more likely middle-ground scenario in incidents like this is partial recovery.

In that case, pre-incident USR could receive controlled redemption. Meanwhile, post-incident USR, especially the counterfeit supply, could be blocked from redemption or trade at a steep discount. At the same time, liquidity and integrations could remain damaged for months. As a result, the token could trade more like a distressed asset than a true stablecoin.

In practice, this kind of outcome usually leads to a long unwind across DeFi. Partners may need to rework collateral settings, oracle assumptions, and liquidation rules. Here, the lesson from the Nexus Mutual report matters. If price feeds lag or stay stale, the damage can spread further.

Scenario: failure to restore redemption credibility

If redemption remains uncertain, or if the pre-incident versus post-incident split cannot be enforced cleanly, then the stablecoin could enter a deeper negative spiral.

In that case, DEX liquidity would likely stay thin. Then peg confidence would remain weak. After that, integrations would stay offline or heavily restricted. Meanwhile, protocol revenue could dry up while operating and legal costs keep rising.

Recommendations for stakeholders

For users, including USR holders and stUSR or wstUSR holders, the key point is to focus on redemption reality rather than peg hope.

Right now, USR should be treated as a risk asset until redemption is clearly restored. The post-incident trading range and all-time low show that it is not behaving like a normal stablecoin.

At the same time, users should rely only on official channels for allowlist or redemption processes. Resolv’s public messaging has pointed affected users toward RDAL coordination.

Also, anyone using USR inside DeFi loops, such as lending or leveraged strategies, should assume collateral settings can change quickly. In edge cases, liquidation math can also break when price feeds lag behind the market.

For partners, including lending markets, vault curators, and integrators, the safer assumption is that any stablecoin with a privileged signer can be counterfeit-minted if controls fail.

Because of that, partners should use multi-source oracles and strict staleness checks. They should also add circuit breakers that freeze collateral use during rapid depeg events.

In addition, any model that relies on an off-chain signer should be scored more like centralized custody risk unless hard on-chain caps and multi-party approvals are in place.

Partners should also stress test extreme scenarios. For example, they should ask what happens if an asset falls to $0.20 in minutes, or if token supply suddenly expands. The Resolv timeline shows that both can happen very quickly.

For investors with protocol or token exposure, it helps to separate the situation into three different questions.

First, can the system become solvent again under a new rule set, especially with pre-incident and post-incident accounting?

Second, can trust be rebuilt through real design changes and transparent incident reporting?

Third, will partners turn integrations back on? That will likely depend on stronger oracle design and tighter collateral protections.

The main lesson running through all of this is simple. Audited contracts do not automatically mean a safe system. That is especially true when privileged off-chain infrastructure can still authorize on-chain minting without strict on-chain limits.