BGD. Correlated-asset price oracle

Development
1

TL;DR

Introducing the Correlated-asset price oracle, an adapter smart contract introducing extra upper price protections for assets highly correlated with an underlying, like LSTs (Liquid Staking Tokens) or stablecoins.


Context

On the Aave protocol, the pricing of assets is done in different ways: some feeds are coming directly from the Chainlink network and its algorithms, others combine multiple Chainlink feeds into one, and a last type combines some Chainlink and/or on-chain data to get a final price.

The most representative case of the last group of feeds using on-chain data is the price oracles for LSTs listed in Aave, like wstETH, stMATIC, or sAVAX. In these cases, the method of calculation is usually considering the price of the underlying, and multiplying by some type of exchange rate between the LST and the underlying. For example, for wstETH, the price is high-level calculated as the price of ETH in USD * exchange rate between stETH and ETH (assuming a 1:1 peg between ETH and stETH).

This approach for pricing is sound, as it reduces important price manipulation risks. However, there have been different discussions in the community surrounding the topic, and there is even the Killswitch project being developed in order to apply protective measures whenever the price of an LST based on the exchange rate deviates too much from a secondary market.

However, there is another protection that could be applied based on a clear principle: for certain type of assets, the price should never be above a certain threshold that can be defined with pretty high certainty in advance.


Correlated-asset price oracle

Let’s take wstETH as a high-level (not considering aspects like compounding) illustrative example to explain the new mechanism.

For the last 1-2 years, the yearly growth of wstETH’s exchange rate has fluctuated in the range of 3-5%. What that means is that at any point of time during that period, if you supplied 1 ETH into wstETH, after 1 year you would have between 3-5% on top of the 1 ETH.

Consequently, we can say that the price of wstETH has increased at an average rate of 3-5% yearly.

So the follow-up question is, can we say that the price of wstETH has a maximum increase over a period X of time? The answer is, kind of.



The Aave protocol prices its assets in USD, so for example it expects the price of wstETH in USD for its internal calculation. It is not totally straightforward to set an upper limit for that price, as wstETH (and ETH) is a volatile asset that could increase (and decrease) radically in price in a short period of time. However, we can set an upper limit on how much the correlation with the underlying can probabilistically change over X period of time. Naively, we could say that in the previous example, a number close to 5% is a good reference for the maximum growth of wstETH in ETH terms.


Our Correlated-asset price oracle solution is based on the previous idea and works the following way:

  • For each eligible asset we will apply a custom price adapter (Correlated-asset price oracle).
  • Each custom adapter will have the following configurable parameters in relation with the new functionality:
    • A ratio provider smart contract, to read the current exchange rate or any other correlation ratio between the asset priced and a reference. For example, the stETH contract itself in the case of wstETH, and its function getPooledEthByShares().
    • A ratioReference, which is the value of the ratio used as reference to calculate the growth from. For example, a valid value could be the exchange rate of wstETH/stETH two weeks prior, or a fixed value in the case of an stable-coin pegged to the USD.
    • A ratioReferenceTime, which is the timestamp of when the ratioReference was set, to be used to calculate the growth from then.
    • A maxYearlyRatioGrowthPercent, to be defined as the maximum yearly percentage growth to be accepted as “correct” by the system. For example, a value of 6% for wstETH.
  • By using the previous parameters, on each price query, the adapter will do the following calculation:
    • First, it will calculate an upper ratio limit at the maximum growth expected, normalised to the time passed.
    • Fetch the current ratio for the ratio provider smart contract, e.g. the current wstETH/stETH exchange rate.
    • With all the data available, two options:
      • If the current ratio is above the max ratio calculated, the price returned will be based on the max ratio, ignoring the current.
      • If the current ratio is below the max ratio, the price returned will be based on the current ratio.

The high-level implications of this mechanism are the following:

  • If the price of a correlated asset is above a pre-calculated maximum proportion with the reference, the system will circuit-break and return the price based on the maximum growth allowed.
  • This protects against any kind of unexpected inflation of the asset.
  • To not cause false positives mispricing down the asset, the system should be maintained in the following way:
    • The maxYearlyRatioGrowthPercent should be set with a certain margin based on the volatility of the growth rate of the correlated asset. This is perfectly fine, because the Aave protocol has extra protections with its risk parameters configuration.
      In the previous example of wstETH, if the historic fluctuation of growth is on the range 3-5%, it is recommended to set a value in the order of 6-8%.
    • Periodically, the ratioReference should be updated. The rationale of this is that growth rate naturally changes over time, and there can be periods where maybe the rate is 5%, and next one is 3%.
      The update frequency should be defined based on historic data and coordinated with the risk providers of the community, but with the type of quality assets listed on Aave, monthly or bi-monthly updates should be enough.
  • This is a biased mechanism: for certain assets, we consider there can’t be any rational reason for their price to increase radically in comparison with a reference. Therefore, we think it is legitimate for the Aave protocol to consider that anomaly as an event to simply ignore.
  • This system should be complemented with others being worked on, like Killswitch, as whenever the custom adapter will be returning the max accepted price instead of using the current ratio, extra actions could be applied risk-wise in the system (e.g. freezing, LTV 0, etc).
  • Changes on the configurable parameters of the system post-deployment (ratioReference, ratioTimestamp and maxYearlyRatioGrowthPercent mainly) are to be done via governance to start with, as for having non-governance parties, extra validations would need to be evaluated and introduced, which we think can be done later.
  • To start with, our intention is to apply this solution to all assets with a clear reference, so mainly all stable-coins and LSTs listed on all Aave instances.

Next steps

We welcome the feedback from the community on the new proposed system, and after some discussion, we will proceed with an ARFC Snapshot.

If that Snapshot is positive, after the security procedures are finished, we will proceed with the activation of the Correlated-asset price oracle on all the applicable assets.

Props to 0xaddi for our discussions on the topic and highlighting the importance of extra protections on some assets to apply this solution on.

11 Likes
2

Intro

Thank you BGD for this post and acknowledgement, in spite of the original dismissal of this issue in ImmuneFi submission (all good tho :wink:).

For context to those who don’t know me, I’m Addison, Founder of Thunderhead and also a first year at MIT. I’ve been working on LSTs for 2 years and have approached it from a first principles perspective (stFLIP is the first dual-governance LST and integrates DEX routing for users). You might also know me from the Curve/Vyper re-entrancy exploit.

I was doing architectural research on other LST protocols when I identified the issue described in the post above.

Concrete Problem

sAVAX/stMATIC rate oracles are EOA controlled and thus can be arbitrarily manipulated. Each EOA can trivially steal 9 figures from both Avalanche and Polygon Aave markets respectively. I think an expeditious remediation of this is very well warranted to prevent systemic risk to Aave and LPs. The existence of this problem undermines a significant portion of Aave’s “decentralization” market prop.

sAVAX

sAVAX appears to be a fully custodial solution; it’s unclear from the documentation but if you look onchain, an EOA withdraws AVAX from the token contract and stakes it to validators. None of the key management or practices here are transparently documented and I think this warrants an investigation into the soundness of sAVAX as collateral on Aave.

I’d possibly be interested in working with Benqi on this remediation effort.

Also as previously mentioned, their EOA (presumably hot due to frequency of transactions) can arbitrarily upwardly manipulate the rate oracle and steal $150m+ from Aave depositors.

Solution

If protocols want to allow EOAs to arbitrarily control their rate oracles, then they may do as they please but Aave should not accept this trust assumption. As mentioned in the proposal, the oracle should have an APR threshold set slightly above the expected APR from protocol rewards. This is straightforward to implement.

Downward Protection

The oracles can be downwardly manipulatable as well which could lead to the liquidation (theft) of all LST collateral. The conversion rate could organically decrease due to a slashing event - these are spontaneous and continous so the oracle should allow for a much more significant “negative APR.” This new oracle should definitely integrate a downward protection.

Next Steps

Glad to contribute to a blue-chip! I’d definitely be interested in a deeper collaboration as I have done a lot of thinking in this area already and already spent a considerable amount of time pondering on this complication.

5 Likes
3

Chaos Labs greatly supports this proposal to integrate correlated asset price oracles. Specifically, leveraging an internally derived bounded mechanism to deter theoretical mispricing in the context of externally derived rate oracles successfully mitigates the core reliance on explicit trust in external systems/EOAs. Much like the killswitch mechanism, however, rooted in an alternative thought process, through this ideation, we can effectively eliminate the inverse scenario from theoretically occurring, i.e., rate oracle spontaneously deviating upward from the actual priced-in rate. Naturally, the level of “trust” implied here has quite some variance, as explicitly mentioned in the comment above pertaining to the various rate oracle permission configurations. In addition, these various assets are not created equal from an economic perspective in the context of a deterministically derived upper bound/“margin” utilizing the underlying growth rate and growth rate volatility. As such, tailoring parameter recommendations for specific underlying assets, such as update frequency and maxYearlyRatioGrowthPercent, requires the creation of a framework leveraging the aforementioned economic components of a given asset.

Downside Protection:

From the lens of downside protection, to deter cases whereby the underlying rate oracle is arbitrarily manipulated to the downside, thereby leading to unreasonable liquidations and/or the theft of supplied LSTs, the integration of such a mechanism in tandem with Killswitch will allow for the optimization of both the mitigation of bad debt accrual & protocol UX. We elaborate on this with a few theoretical scenarios below:

image
On the contrary, attempted manipulation with the downward correlated asset price oracle implementation:

image

Slashing:

The integration of a lower-bounded framework does not concretely relate to slashing events in the context of “protecting” some underlying exchange rate. This is because, in an efficient market, we are under the assumption that the LST market price will converge to that of the thus-decreased exchange rate. In addition, the extrapolation to an annual calculation is risky with slashing, as if a slashing event occurs right after we update the reference time, extrapolating that decrease in the exchange rate will cause LST mispricing. This is because the reference time update to a negative APR calculation can lead to us hitting the lower bound when, in actuality, the market prices the slashing accordingly, not to a negative APR. This is, of course, assuming that some or multiple slashing events had occurred just after the ratioReferenceTime update, such that the normalized annual rate calculation returned a value lower than the maximum negative deviation. As such, converging on a maximum negative deviation value & ratioReferenceTime frequency equilibrium with respect to historical slashing frequency, rate oracle configuration & e-mode LTs is needed to maximally mitigate the “side effects” of this downward implementation. These considerations must be reflected in the methodology for setting a lower bound.

3 Likes
4

Gauntlet supports the introduction of the Correlated-Asset Price Oracle (CAPO) to safeguard highly correlated assets like stablecoins and LSTs

LSTs

Similar to our proposed Killswitch, the CAPO mechanism provides further safeguards to protocol when pricing LSTs using the current CSPA implementation. During severe dislocations between the secondary market price and the exchange rate, the killswitch mechanism automatically adjusts risk parameters to mitigate insolvencies, as mentioned in this post.

Upward Manipulation of Exchange Rate

The Correlated Asset Price Adapter functionality further protects the protocol from upward manipulation of externally derived exchange rates, as mentioned by @addison . This new adapter will be a risk mitigation complement to prevent oracle manipulation in the event the exchange rates are manipulated upwards to inflate the value of LST collateral, which could lead to significant funds being exploited.

Downward Manipulation of Exchange Rate

Downward manipulation of the ratio provider smart contract creates another risk vector for the protocol in the event the smart contract is compromised. An exploiter can force LST collateral positions to be liquidated to take advantage of liquidation incentives until the actual market pricing of the LST makes liquidations unprofitable.

With the killswitch implementation, if there is any dislocation between the secondary market and the exchange rate of the LST, the market will be set to freeze, so the potential threat of an exploiter borrowing LSTs with low non-LST collateral is minimized but still not fully mitigated.

As a note, this initial post for the correlated-asset price oracle primarily addresses the upward manipulation risk but can be adapted to address potential downward manipulation risk for LSTs. Integrating a downward bound threshold to the correlated-asset price oracle must consider slashing events.

Stablecoins

For stablecoins, it is advisable to include a mechanism to prevent upward price dislocations from the expected fixed value. However, implementing downward pricing thresholds for stablecoin assets is not recommended. In the event of a stablecoin downward dislocation, it’s crucial for the oracle price feed to enable liquidations if the asset loses its peg.

3 Likes
5

As an update of the project, we have progressed the implementation and, after the feedback from the community and risk providers, the next steps are the following.

  • There is clear consensus that upper price protections for LSTs and stable-coins are a net improvement, and the initially proposed design, sound. Therefore, in order to prioritise delivery speed, we will proceed with an initial release applying those upper protections, leaving lower bounds for the following iteration (scheduled just after the first, as the security procedures will be simpler).

  • In order to reduce complexity, the correlated-asset price oracle will be applied initially on all the Aave v3 instances, with v2 left for the following iteration.

  • The assets to apply the solution on are the following:

    Aave v3 Ethereum

    USDT, USDC, rETH, DAI, cbETH, sDAI, LUSD, FRAX, crvUSD, wstETH

    Aave v3 Polygon

    MATICx, USDC.e, USDC, stMATIC, USDT, DAI, wstETH, agEUR

    Aave v3 Avalanche

    sAVAX, USDC, USDt, DAI.e, FRAX

    Aave v3 Optimism

    wstETH, USDC.e, USDT, sUSD, USDC, DAI, rETH, LUSD

    Aave v3 Arbitrum

    wstETH, USDC, USDT, USDC.e, DAI, rETH, LUSD, FRAX, EURS

    Aave v3 Metis

    m.USDC, m.USDT, m.DAI

    Aave v3 Base

    cbETH, USDbC, USDC, wstETH

    Aave v3 Gnosis

    wstETH, sDAI, xDAI, USDC, EURe

    Aave v3 BNB Chain
    USDC, USDT

  • Given their purely technical/risk nature, the final initial configurations will be defined at AIP stage, as they will based mainly on historic data on each one of the assets. We will request the risk providers of the community to recommend the most appropriate ones.

  • We will proceed now with the creation of an ARFC Snapshot, while the security procedures on the solution are finished.


The codebase can be found on https://github.com/bgd-labs/aave-capo with only minor naming and audit-related changes expected.

4 Likes
6

We have created an ARFC Snapshot for the community to pre-approve the first iteration of Aave CAPO.

Voting will start in approximately 24 hours, participate :ghost:

https://snapshot.org/#/aave.eth/proposal/0x387f779952a20e850f941111ccf7aa49022ee35274fd219b9759c0ea240b72e1

2 Likes
8

Following the pre-approval on Snapshot, having finalised the security procedures and received the final recommendation from the risk provider of the community (@ChaosLabs), we have create an on-chain AIP to activate CAPO for all applicable assets, on all networks.

Voting will start in approximately 24 hours, participate :ghost:

https://vote.onaave.com/proposal/?proposalId=51

1 Like