Given that the thread is becoming very dense, and given our role implementing the multi-layer oracle adapters used by Aave up until today, we would like to comment on what we think about the different models:
- We think the linear and exponential discount models are, even if simpler “on-chain”, naive. The rationale is simple: a zero-coupon bond-like” asset with high volatility on the “interest claim” (YT in this case, with claims over underlying yield plus more speculative aspects like points/airdrops), if priced via any type of static discount, decouples very importantly from the real price. This is very clear from the data provided by both risk providers.
With those discount models, the way to be more sensible to the market is to have very dynamic risk configurations, and at that point, we are in ground zero: the solution resembles the same as the initially proposed by Chaos Labs: a risk oracle.
In our opinion, while not manipulatable, Aave should track the price as close as possible, while having risk levers to adjust dynamically, precisely the strength of the current v3 protocol architecture. - We think this conversation has derailed quite a bit from risk into technical architecture. No matter the components and who provides them, the Aave oracle adapter for a “complex” asset like Pendle PTs, should have the the same components as what we do in production at the moment for assets like LSTs, LRTs, or sUSDe.
This architecture is the following for example for sUSDe on v3 Core Ethereum:
This model has been explained in detail when CAPO was activated in the past on Aave, but to go more to the specifics, the following are important aspects of it (labeled on the diagram):
- Component 1. On the deepest/core layer sits a Chainlink feed for the underlying asset trading in the secondary market, USDe. This is what usually is understood as a price oracle, which needs to be decentralized and we think only Chainlink should be considered for it.
At this point, within certain sanity bounds and off-chain infrastructure protection, from Aave we assume an output of any type of value, depending on the oracle provider properly reporting. So technically from this component, we could get let’s say $1.10 for USDe/USD (overpriced). - Component 2. Then, the price feed is capped by the principle that an asset pegged to USD should not deviate long-term from a certain static upper threshold, e.g. price should not be permanently above $1.04.
At this point, we know on-chain that the output simply can’t be more than e.g. $1.04, no matter what the underlying feed reports. - Component 3. On top of that, and following the principle of not pricing certain assets in the secondary market, but on a “primary” rate, we read the rate from some rate provider contract.
This rate provider contract generally is the asset issuer, but sometimes it is an additional third party, like Chainlink bridging the rate from an Ethereum contract to an L2.
Same as with the first layer, here initially we expect any type of value for the rate, and on listing stage, we evaluate how is the infrastructure (usually fairly centralized) of the issuer to do the update, constraints of range in their contracts, etc.
So technically from this component, we could get let’s say a 1.50 exchange rate for sUSDe/USDe (overpriced) - Component 4. Lastly, as we know exchange rate is a parameter that should not change aggressively over time, the rate growth itself is capped. Simplifying, if we say that the cap of the exchange rate growth is 36.5%, it means that a rhythm of growth of 0.1% or more from one day to another would cause the feed to be temporarily capped.
This way, and considering that still we have protection by LTV/LT, we protect Aave even against the infrastructure of the rate provider, being the issuer or whoever.
There are multiple reasons for this design, but some important in this context:
- Aave owns the final layer plugged into the protocol to price assets, and delegates (constraint) trust however it is required. Like with any type of output to the protocol, there is always trust involved to more or less a degree, but from the technical side, our job is to, without disrupting operations, constrain that trust.
- Pricing an asset on Aave is not “fungible”: meaning that only in certain cases a price can be general enough to price the asset on Aave the same as in other protocols.
Factually this is done also with risk configurations, but it is even applicable on price.
Going back to Pendle PT’s pricing itself, our opinion is the following:
- In terms of layers, the system is kind of the same on the high-level price side, with the following differences.
- The rate risk oracle proposed by Chaos is sound to us if properly constraint on-chain on the Aave oracle layers. The issuer has also reviewed and backed the model, which adds another level of verification. So we think it can perfectly be applied.
- Dynamic lower CAPO on the PT/underlying rate. Given that the dynamics of price evolution are way more deterministic than other assets, and that price should tend to par (1 underlying) at maturity, it adds to the security of the system that, in addition to the upper CAPO cap, we add a dynamic lower CAPO cap that “follows” from the lower side the rate recommendation, factually creating an on-chain range constraint that the rate can’t ever go out of.
In addition, this acts as a protection towards the infrastructure (Edge) submitting the rate recommendation. - The aforementioned LTV0 “kill-switch”. This is very obviously required, with all risk providers in agreement. We still need to evaluate how to apply it, and if it should have disable/enable dynamics or only disable.
However, it should have a close relation with the dynamic lower CAPO cap. - LT/LB risk stewards. These are not new components or even part of the oracle layer. They are already running ones that accept risk recommendations from Chaos Labs and it is only the algorithm that will be slightly different, but respecting the stewards constraints (currently 0.25% change every 3 days, but should be enabled for eMode too).
- Given the imminent activation of Chainlink SVR for a sub-set of assets on Aave, we will discuss internally with Chainlink how to handle this case, same as with any other asset currently using rate feeds.
The following is a diagram of the oracle layer of the system, including our proposed dynamic lower cap.
Conclusion
To proceed with this topic, we agree that the proper path is to create an ARFC with the following options:
- Applying the dynamic architecture of risk oracle. Perfectly fine from our technical perspective.
- Go for a static model on the oracle layer, and move the complexity to exclusively the risk parameters configuration. Arguably less optimal, but perfectly fine from a technical perspective.
- Not proceeding with any type of Pendle PT’s pre-listing preparation, and consequently, with PT’s listing.