A Stablecoin Depeg Can Drain a Vault

Summary

Stablecoins are supposed to hold $1. When one breaks its peg, the damage doesn’t stay contained. Lending markets rely on price feeds that update slowly or not at all, so a collapsed coin keeps getting valued at full price, and automated systems keep lending against it. In March 2026, Resolv’s USR fell 97.5% in 17 minutes, yet feeds priced it at $1 for hours. Anyone could buy it cheap and borrow against the fake price. This was the fourth incident like it in fourteen months, in an industry now holding $6.6B in curated vaults.

Enforce the rules before money moves, not after. Newton adds a policy check between when a transaction starts and when it settles. If an asset has depegged, the transaction is simply blocked. Rules that today live in documents nobody can enforce become automatic. No system rewrite needed, and every decision leaves a verifiable onchain record.

1. Depeg risk for vaults

1.1 How stablecoins are used in vaults

A vault is a pooled position with a mandate. Three roles define it:

Depositors supply the assets.
Curators allocate them across markets and set caps and fees.
Allocators, the capital behind the deposits, set the limits the curator works within.

Why one depeg is three things at once:

Most vault capital is stablecoin-denominated, and the same stablecoins are accepted as collateral in the markets.
One stablecoin asset is therefore three things at once: a holding, a collateral base, and the denominator of reported performance.
With $6.6B now sitting in curated vault TVL (DefiLlama, early 2026), a depeg becomes a correlated event across the market.

1.2 What is a depeg event

Two variables describe a depeg, and they price very differently.

1.3 How oracle moves trigger cascades

While a feed is stale, a vault’s reported APY rises, because realised yield is divided by a risk input that has not moved. Allocation bots read that as opportunity and route more capital in. Capital flows toward the problem for as long as the feed lags, and the automation does exactly what it was told.

2. The Resolv depeg event

2.1 Incident Timeline

According to 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.

2.2 Incident losses

Downstream losses landed on protocols with no connection to the attacker:

Fluid absorbed more than $10M in bad debt and saw over $300M of outflows in a single day, the largest in its history.
The primary incident report cites $7.77M of locked lending exposure across four USR / wstUSR markets left at 100% utilisation with $0 available liquidity.

Every one of those losses followed from vault logic executing against a feed that had stopped reflecting reality fifteen hours earlier. The theft was the first failure. The second failure is the one that recurs.

2.3 Why vault operators and curators should care

Eighteen audits had reviewed Resolv’s contracts, and each confirmed the code behaved as written. The compromised component sat outside all of them.

Curators in the affected markets appear to have done nothing wrong. Their mandates were reasonable, and also unenforceable, because they existed as documents and alerting rather than as conditions on execution. A curator whose risk policy read “do not allocate into a depegging asset” would have been correct, and would still have been allocated in by a process with no way to read the policy. The controls and the execution path were never connected.

3. How Newton would have helped

Newton is an authorization layer: a policy check between the moment a transaction is initiated and the moment before it settles. Curators integrate through VaultKit, which wraps the instructions their existing tooling already produces and routes them through that check. No migration, no contract rewrite, nothing changes for depositors.

3.1 Vault flow, with and without Newton

Today: monitoring produces a notification after execution. The curator learns what happened and can’t do anything to undo it.
With Newton: a policy layer sits before settlement. The transaction does not occur.

3.2 The signal a policy reads

A policy is only as good as the data it references. Webacy produces the data signal; Newton enforces the constraint referencing it. Webacy also convenes DARC, the Digital Asset Ratings Council, on ratings standards.

3.3 Defining the policy

A policy is the full set of rules a vault enforces, evaluated as one decision.

Policy is held separately from contract code, so a revised threshold takes effect without redeployment.
Threshold and window are illustrative and differ by mandate.
In March, a deviation threshold in this range would have triggered within the first minutes of the cascade, well before the bottom and hours before any human alert would have been actionable.

3.4 Enforcing it

VaultKit routes the curator’s instruction to Newton.
An operator network evaluates the applicable policy against live data and issues a cryptographic attestation bound to that specific instruction, vault and amount.
Approved policy checks execute normally; denied ones block the transaction before settlement.
Evaluation fails: if a policy denies, or evaluation cannot complete, nothing proceeds.
Each decision, approved or denied, writes a signed record onchain at explorer.newton.xyz.