[Direct-to-AIP] Alter mUSD Oracle Price Implementation

[ChaosLabs]

Summary

This proposal recommends altering the implementation of the mUSD oracle on the Aave V3 Ethereum and Aave V3 Linea deployments from the current market price feed to a hardcoded value of 1. In parallel, we propose temporarily reducing the mUSD supply and borrow caps on both networks to 1 prior to the oracle migration. Upon AIP execution, the mUSD supply and borrow caps will be restored to economically meaningful levels.

This oracle change addresses observed short-lived but material negative deviations in the market feed, which are not aligned with the factual market value of mUSD and could enable opportunistic borrowing at artificially depressed prices. Given that mUSD is not enabled as collateral on these markets, the proposed change simplifies the oracle model, aligns it with mint/redeem parity, and materially reduces manipulation and mispricing risk for Aave, while preserving the protocol’s upside in adverse depeg scenarios.

Motivation

The core motivation for hardcoding mUSD to 1 USD stems from observed mismatches between mUSD’s reported on-chain price and its underlying economic value as a fully redeemable stablecoin, occurring against a backdrop of materially diminished mUSD liquidity. In particular, we have observed short-lived negative deviations in the mUSD/USD price feed on both Linea and Ethereum, even while broader on-chain markets with deeper liquidity continued to trade mUSD at or near parity.

These episodes seem consistent with the feed being skewed by low-volume venues, transient transaction-level distortions, or other opaque aggregation effects, rather than reflecting a true market-clearing price. As liquidity thins, even modest and temporary dislocations can generate oracle updates that are not representative of factual volume-weighted pricing.

From a risk perspective, it is essential to note that mUSD is not used as collateral in the relevant Aave deployments. As a result, negative market oracle moves do not produce liquidation shortfalls or threaten solvency through impaired collateral exits. Instead, the exposure is concentrated on the liability side: if the oracle were to briefly report a meaningfully sub-par price, the protocol is thus forced to treat transient, low-liquidity oracle prints as economically binding, even when they diverge from mUSD’s factual market value.

By hardcoding mUSD’s price to 1 USD, Aave explicitly encodes the assumption that mUSD remains redeemable at par in normal conditions and that short-horizon on-chain price noise is not relevant for risk management, given its non-collateral status. This removes the downside tail risk introduced by transient sub-par prints and prevents brief, low-depth price dislocations from translating into protocol-level accounting risk. The existing cap adapter ceiling already limits upside manipulation for stablecoins; moving to a static price effectively neutralizes oracle-driven tails on both sides, while remaining consistent with mUSD’s intended design as a par-redeemable asset.

In a true fundamental depeg scenario, where mUSD’s backing is impaired and its market price trades below $1 for a sustained period, the static oracle maintains a conservative posture for the protocol. Debt continues to be booked at 1 USD while the asset’s market value falls. From the protocol’s perspective, this improves resilience: liquidators can source mUSD more cheaply to repay a 1 USD unit of debt, increasing liquidation profitability and reducing the likelihood of bad debt. Borrowers are effectively “overcharged” relative to spot during a depeg, but that asymmetry is protective for the protocol compared to a dynamic oracle that would mark liabilities down in line with distressed, low-liquidity pricing.

Specification & Recommendation

We recommend a two-step implementation path.

First (immediate, strictly temporary mitigation): the Aave Risk Steward will reduce the mUSD supply and borrow caps on both the Ethereum and Linea deployments to 1 unit. This is an intentionally short-lived circuit breaker meant only to cover the brief window until the AIP executes the new oracle configuration. It freezes the effective growth of new mUSD liabilities while leaving existing positions untouched, with $3,500 in supply and $1,200 in borrows on Linea, and $155 in supply and $100 in borrows on Ethereum Core. This prevents opportunistic borrow expansion during the AIP’s voting and timelock period.

Second (at AIP execution): When the AIP is executed, the payload should (i) update the oracle configuration for mUSD on Aave V3 Ethereum and Aave V3 Linea to use a static 1 USD price source, implemented via the standard Aave price-oracle adapter mechanism, and (ii) raise the mUSD supply and borrow caps back up from 1 unit to a more conservative level than today’s pre-steward settings, reflecting the still-thin liquidity backdrop even after the oracle hardening. No other risk parameters for mUSD change under this proposal.

Chaos Labs will continue to monitor mUSD liquidity, peg stability, and user behavior across both deployments and will return to governance with further recommendations if either market structure or the stablecoin’s fundamental design changes in a way that warrants revisiting the 1 USD hardcoding assumption.

Current, via Steward

Instance	Current Supply Cap	Recommended Supply Cap	Current Borrow Cap	Recommended Borrow Cap
Ethereum Core	10,000,000	1	8,000,000	1
Linea	70,000,000	1	60,000,000	1

AIP Specification

Instance	Current Expected Supply Cap	Recommended Supply Cap	Current Expected Borrow Cap	Recommended Borrow Cap
Ethereum Core	1	5,000,000	1	4,500,000
Linea	1	20,000,000	1	18,000,000

Next Steps

We will move forward and implement the relevant updates via the Risk Steward process. AIP will follow shortly after.

Disclosure

Chaos Labs has not been compensated by any third party for publishing this AGRS recommendation.

Copyright

Copyright and related rights waived via CC0.

[bgdlabs]

As a follow-up to the previous analysis by @ChaosLabs, from a technical and pool-configuration perspective, we confirm that for this type of asset (reference-correlated and only borrowable), using a static USD feed doesn’t create any issues.

To reiterate:

• On price movements up. That the price is not sensitive to “spike” movements up is perfectly fine and desirable, the same strategy we currently use with CAPO on stablecoins, but even more strict. The rationale being that there is no realistic reason for a stablecoin like mUSD to trade at a premium over 1$ permanently, so Aave can be conservative and not allow dislocations whenever the secondary liquidity is fragile.
• On price movements down. Not being sensitive to them potentially sounds misaligned with a core principle of Aave to always detect and open liquidations when prices of assets decrease. However, as pointed out by @ChaosLabs, whenever the asset is only borrowable, assuming the asset is overpriced only causes the system to normalise liabilities of the borrower towards the protocol. This should be understood by borrowers, but it doesn’t really hurt them in any meaningful way, while really protecting the system:
  • If the price dislocation is temporary, it means the borrower will not be able to increase their borrowing position proportionally to the dislocation, but there is no other effect.
  • If the price dislocation is permanent (e.g. asset loses its backing), the borrowers would still need to repay the same borrowed units of mUSD (no matter if acquired at a lower price); consequently, the suppliers would receive the same units of mUSD, and the system would be healthy. It is important to point out that this scenario should be addressed with extra levers down the line, currently being worked on in other projects of the community (e.g., integrations with PoR mechanics, and others).

[LlamaRisk]

Summary

LlamaRisk supports replacing the current secondary market oracle for mUSD with a hardcoded 1 USD oracle as a temporary measure. This change is proposed due to the transient depegs observed during the initial asset launch phase, which were caused by low liquidity. However, it is essential to note that borrowers bear the downside price risk, as they would be required to repay at $1 even if mUSD were to depeg due to loss of backing, an unlikely scenario, but one that still needs to be acknowledged.

Importantly, this approach remains appropriate for the protocol as long as mUSD is not enabled as collateral. With collateral enabled, a hardcoded oracle would expose Aave to the potential risk of bad debt, as a genuine loss of backing resulting in a sustained depeg would not be reflected in the price feed. In such a case, a switch to a PoR-based oracle would be required.

Current Capped mUSD Oracle

The current mUSD oracle sources price data from secondary markets, making it susceptible to manipulation. Aave applies an upside cap of 1.04 to guard against upward price spikes. However, it does not include downside protection. In the historical price data, a few downward spikes were identified in the Oracle data on October 13, 2025, when the feed momentarily reported prices as low as 0.9621 on Ethereum and 0.9476 on Linea, as shown below.

Source: LlamaRisk, December 4, 2025

These observations raise the question of whether such deviations could be exploited. To assess this, we consider the scenario of a potential exploit, where a user borrows larger amounts of cheaper mUSD priced by the oracle during a temporary depeg. When the oracle price later returns to peg, the borrowed mUSD becomes more expensive relative to the supplied collateral, potentially resulting in bad debt for the protocol. Such a case would require d > 1 – LTV, where d is the negative deviation from peg. The maximum respective LTVs at which mUSD can be borrowed on Ethereum and Linea are 80.5% and 80%, both against WETH.

This exploit would require the oracle to publish a $0.8 price, implying a 20% drawdown, which is nearly four times larger than what has been observed in the current illiquid secondary market environment (Linea – 5.24%, Ethereum – 3.79%). This makes the scenario unlikely. Moreover, since October 13, 2025, the price data reported by the oracle has also remained highly stable, with the lowest downtick being just 14 basis points on November 4, 2025, for Ethereum.

Hardcoded Oracle

The use of a fixed 1 USD oracle works well in the current setup, as mUSD is not enabled as collateral, as it shields the system from short-lived deviations in the secondary market oracle due to thin liquidity. In this configuration, liquidations are not a factor as mUSD can’t be used as collateral, and the main downside price movement risk is borne by borrowers, who may need to repay at $1 even when mUSD’s market price trades lower, including in the case of a permanent depeg from loss of backing.

However, this approach could create issues if Aave were to enable mUSD as collateral in the future. A hardcoded oracle would expose Aave to a bad debt situation if a genuine loss of backing were to occur and mUSD experienced a sustained depeg. In that case, a live market feed, such as the current secondary market feed, or a PoR-based oracle would be required.

Disclaimer

This review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.

The information provided should not be construed as legal, financial, tax, or professional advice.

[ChaosLabs]

The AIP has been created here, with voting to commence in approximately 3 hours:

START
December 6, 2025 3:30AM UTC

END
December 9, 2025 3:30AM UTC