[ARFC] Pendle Principal Token Risk Oracle

ChaosLabs · February 6, 2025, 11:04pm

Summary

Chaos Labs introduces a Risk Oracle framework centered on robust risk management for the integration of Pendle Finance’s Principal Tokens within Aave. This implementation proactively mitigates systemic and market risks while dynamically optimizing capital efficiency and user experience. By continuously adjusting risk parameters, optimally configuring the underlying asset price in accordance with its expected volatility and integrating a killswitch mechanism, the framework ensures resilient risk controls, safeguarding the stability of Aave’s lending markets while maximizing sustainable returns.

At a high level, the proposed specification will have the following components:

Volatility-Structured Pricing Mechanism – Dynamically streamlines the implied rate using a manipulation-resistant algorithm at defined intervals to determine the price of the Principal Token. Updates are triggered by significant changes in PT price, with their frequency decreasing as the asset nears maturity, ensuring a stable and adaptive pricing approach.
Liquidity-Responsive LTV Adjustments – Sets LTV to 0 when AMM liquidity is no longer accessible and the market reaches its minimum price due to market proportion constraints.
Dynamic Risk Parameters – Increases LTV and Liquidation Threshold as the asset approaches maturity.
Adaptive Liquidation Bonus – Gradually decreases the Liquidation Bonus as the asset converges to maturity.

The proposed design introduces a novel approach that diverges from conventional Oracle system implementations. Specifically, it integrates a pricing mechanism for certain components while simultaneously incorporating specific actions and constraints across various scenarios. This approach enhances the complexity and functionality of the system, making it more dynamic and adaptable to fluctuating conditions. Conceptually, it can be likened to an advanced and more intricate iteration of the Correlated Asset Price Oracle (CAPO), extending its capabilities by introducing additional layers of pricing dynamics and scenario-based decision-making.

Chaos Labs has conducted in-depth research on Pendle’s Principal Tokens, collaborating with Pendle on a Principal Token Risk Assessment and a Mechanism Design Risk Assessment. These assessments provide a comprehensive analysis of the protocol’s intricacies, offering key insights that underpin the rationale behind this implementation. We highly recommend reviewing them for a deeper understanding of the framework’s design and risk considerations.

Motivation

Pendle Protocol’s Principal Tokens (PT) provide a predictable, fixed-yield income by representing the principal value of a Standardized Yield Token (SY) that matures at a predetermined date. Similar to zero-coupon bonds, PTs allow users to lock in returns as a function of the PT price with respect to its 1:1 value with SY at maturity, making them a valuable tool for stable income generation in DeFi.

PTs are created by splitting an SY into Principal Tokens (PT) and Yield Tokens (YT). The PT holds the principal value until maturity, while the YT carries the variable yield component. This separation enables more flexible investment strategies, benefiting users who seek stable returns or speculate on the underlying yield generated within a predefined timeframe.

Since PTs have a fixed redemption value at maturity, they experience reduced volatility as expiration approaches, making them well-suited for traders leveraging yield with lower market risk, and thus integration within lending markets, specifically leveraging with correlated debt assets, creates an opportunity for significant demand and revenue accrual that can be scalably integrated.

Given the complex dynamics of PT tokens, the pricing methodology used within lending markets must be designed to scalably accommodate significant TVL relative to the underlying market. This ensures the mitigation of tail risks, such as bad debt accrual and price manipulation, while simultaneously enabling efficient utilization that accurately reflects the market state in expectation.

However, the current approaches to pricing PT tokens in lending markets remain limited to two relatively inefficient methods: the PendleSparkLinearDiscountOracle and a market TWAP feed. Below, we provide a comprehensive breakdown of these methods, along with their respective trade-offs and inefficiencies.

LinearDiscountOracle

The linearDiscountOracle, the first and most widely adopted pricing mechanism, has secured over $1 billion in PT collateral deposits. It is primarily utilized within Spark Morpho Vaults, underwriting various PT-sUSDe markets through a direct deposit module. This oracle establishes a deterministic price trajectory for PT tokens as they approach expiry, defined by a configured baseDiscountPerYear, ensuring predictable valuation based on time to maturity.

The core rationale behind this approach is its fixed assumption regarding the future state of the underlying asset at a predetermined maturity. By leveraging an exchange rate to price correlated assets with a fundamental underlying representation, the mechanism effectively functions as a derivative—pricing the expected exchange rate itself. This methodology reduces volatility-driven pricing inefficiencies, thereby minimizing potential liquidations.

Underpricing PTs in Expectation

Despite its name, the LinearDiscountOracle operates with an inherently approximative architecture. An alternative implementation could involve a fixed oracle that references a specific Pendle market’s rateAnchor, allowing the oracle-priced implied APY to be dynamically configured at the liquidity density’s highest concentration within predefined bounds. This effectively aligns with what can colloquially be referred to as the expected PT price with respect to time.

Formally, this relationship can be expressed as:

At the pool’s inception, the initialAnchor is strategically selected to concentrate liquidity around the expected implied yield, ensuring efficient pricing and minimizing distortions due to market fluctuations.

As such, mathematically, the expected PT price in relation to the implied APY follows a logarithmic transformation, due to the inherent price <> yield relationship. However, rather than adhering to this expected logarithmic relationship, the LinearDiscountOracle instead employs a linear approximation, expressed as
1 − baseDiscountPerYear * yearsToMaturity(t).

This distinction can be significant because baseDiscountPerYear does not directly represent the implied APY. Instead, due to convexity effects, it produces an implied yield curve that systematically underprices the asset relative to the actual expected implied APY.

To illustrate this effect, we examine the following respective price trajectories for PT-sUSDe-29MAY2025 along with their associated implied APYs:

Linear Discount Oracle Price
Expected AMM Price

The Expected AMM Price is derived from 1 / rate_anchor for the market, which is inversely configured to a 25% implied APY. For comparison, baseDiscountPerYear was set to an equivalent nominal value, which is currently utilized in the Morpho market today.

To better understand this deviation, we reconstruct baseDiscountPerYear by transforming it into an implied APY. As shown in the analysis, the LinearDiscountOracle deviates from the expected price. This transformation reveals an effective yield curve whereby the implied APY decreases exponentially over time.

Implications of This Pricing Approach

The outcome of this pricing structure is a dynamic rate of PT convergence:

Initially, the effective implied APY starts at a high value.
Over time, this rate gradually declines.
Although baseDiscountPerYear is set to the expected implied APY, this approximative method systematically underprices PTs in expectation.
As maturity approaches, the PT price converges to the expected value, in addition to the time-converging pricing properties.

This underpricing mechanism attempts to reduce the risk of overpricing the oracle, particularly as the market nears maturity. The extent of this effect depends on market configuration and time to maturity, akin to the Pendle team effectively deriving the parameterization for the underlying market, shaping how the LinearDiscountOracle interacts with expected market dynamics.

However, this can present further issues under the assumption of significantly large implied APY or time to maturity. The linear derivation implies that for such values, the retrieved PT oracle price can trade significantly lower than any nominal expected PT valuation. Under the assumption of an aggregate 100% implied yield with respect to time to maturity, the oracle price will effectively be worth 0, as can be seen below, rendering the utilization of the oracle infeasible or significantly constrained.

Overpricing PTs

While the linearDiscountOracle implicitly underprices in expectation with respect to 1/rateAnchor, on the flip side, its transformed baseDiscountPerYear can still trade significantly above the market price due to potential downward price volatility with respect to 1/rateAnchor, often causing deviations between market prices and their calculated or oracle-derived values. These deviations, particularly pronounced for assets with a moderate implied yield and time to maturity, such as sUSDe PTs, can result in mispricing that can constrain the listing of certain assets or expiries, especially depending on the initial value chosen. Such mispricing is especially problematic when the market price diverges downward significantly from the oracle price, intended to anchor valuations.

The inverse relationship between implied yield and the price of PT tokens adds complexity to this issue. Mispricing introduces multidimensional risks to lending protocols. As the market price of a PT token falls below the linearDiscountOracle price due to YT speculators, the expected demand for PT leverage dynamically increases both organically and artificially—driven by mispriced collateral and elevated PT yields. For instance, a sudden spike in implied yield causes the market price to deviate further downward from the oracle price. The interest rate willing to be paid by new positions relative to the in-house converging rate can lead to LTV appreciation (given by interest rate > baseDiscountPerYear) and is exacerbated by the additional capital efficiency presented through the overpriced oracle (given by the inverse relationship between yield and price).

As such, a user who acquires PTs at a relatively high implied APY in the market—exceeding the baseDiscountPerYear—is more willing to pay higher interest on the underlying debt when the linearDiscountOracle misprices the asset, compared to a scenario where the Oracle price aligns accurately with the current market price. In an adverse scenario, if the market price were to deviate from the oracle price by more than 1 - LT (effective LTV above 100%), a user can arbitrage the lending market and thus run away with debt, leading to rate-agnostic interest and utilization rate spikes. On the flip side, suppliers unintentionally underwrite mispriced debt, causing rapid debt accumulation within the system. In the plot below, the effective LTV is plotted with a nominal 91.5% LLTV and 25% baseDiscountPerYear as enshrined within the largest PT-sUSDe market today. For higher PT implied yields, the effective LTV can climb above 100% while directionally providing significant yield relative to baseDiscountPerYear.

In addition to the adverse dynamics previously discussed, net interest accrual—and consequently, LTV appreciation—is determined by the difference between the prevailing market interest rate and the baseDiscountPerYear. Given that the deviation between the Oracle price and the market price is significant while interest rates remain elevated, and as demand for the asset continues to grow—both organically and artificially—the rate at which collateral appreciates is fixed. As a result, this fixed appreciation, in expectation, leads to net debt accrual within the protocol.

This dynamic differs from a system that employs a market-driven oracle, where the price would adjust downward as implied yields rise. In such a setup, the expected rate of collateral appreciation would be lower than the interest rate the market is willing to pay. However, due to the presence of baseDiscountPerYear, the protocol exhibits a different behavior: liquidation eligibility becomes more probable, yet actual liquidations are unlikely to occur due to the significant discrepancy between the linear discount oracle price and the market price—particularly when maturity is sufficiently distant or the implied yield range is broad.

It is additionally worth noting that the majority of the debt underwriting PT liquidity utilizing the linearDiscountOracle stems from Maker/Spark. Thus, under the assumption that debt positions cannot be liquidated, the effective “break-even” can be defined as 1 - LLTV due to the ability to internalize liquidations. Our more detailed analysis of this phenomenon can be found here.

Market TWAP Feed

The second asset pricing mechanism is Pendle’s in-house time-weighted average price (TWAP) feed, which features a configurable twapDuration. This enables lending protocols to parameterize a market feed based on the market state.

A short TWAP window is more susceptible to manipulation but provides a more accurate reflection of recent trades, making it highly responsive during price movements and allowing for faster liquidations.
A long TWAP window reduces manipulation risks but may delay liquidations, necessitating a higher liquidation bonus to maintain profitability.

TWAP feeds geometrically derive their data exclusively from AMM prices, rather than incorporating order book dynamics typically observed in a given market. While AMM prices and order book prices are generally aligned, a market proportion constraint within the AMM prevents any transaction that would push the concentrated liquidity pool ratio beyond a threshold—specifically, where either PT or SY exceeds 96% of the pool’s composition.

When the pool reaches this 96% constraint in PT terms, the Oracle price effectively reports its maximum implied rate, thereby establishing a minimum price floor. Mathematically, the minimum price minPTPrice can be expressed as the following:

Akin to the initialAnchor, the scalarRoot effectively represents the raw variance of the liquidity distribution and thus the minimum price. This mechanism is crucial for mitigating both rate and price volatility as the pool nears its liquidity limits, reducing the risks associated with potential price manipulation.

This protection is particularly important given the sporadic nature of liquidity in order books. Since no efficiently arbitrageable external market exists to correct artificial price deviations, implied APYs can be manipulated at minimal cost when order book liquidity is low.

However, introducing a minimum price comes with its own set of risks. The market may still price PT lower than the AMM-reported value through the permissionless order book, creating a potential arbitrage opportunity if sufficient order book liquidity exists and there is ample time until maturity. Conversely, if liquidity is insufficient, this mispricing could lead to challenges in executing liquidations.

The chart below illustrates these dynamics within the USD0++ market. While the configured implied APY range within the AMM was heuristically capped at 30%, the market-implied APY derived from the order book ultimately traded well above this range, exceeding 50% with significant volumes. This sharp increase in implied APY stemmed from the realization of speculative points yield associated with the asset, which was ultimately reflected in the USUAL token distribution, causing a sudden spike in the underlying APY.

Additionally, relying on the TWAP feed introduces the risk of cascading liquidations. Speculative underlying yield, driven by points incentives, coupled with the lack of an efficient external market, can weaken fundamental arbitrage. This, in turn, may result in artificial price fluctuations, further destabilizing the market.

Conversely, the fundamental representation of the asset still aligns with an exchange rate oracle, as it is tied to a future date when the underlying will be credited. For example, a dynamic exit queue duration at the Ethereum consensus layer creates an inverse effective payoff for LSTs, influencing market valuation relative to its fundamental underlying exchange rate. This characteristic suggests that PT pricing could incorporate elements of a similar framework.

AMM TWAP Technical Risk

Historically, AMMs designed for swaps are inherently complex systems. To facilitate on-chain settlement, these systems are often artificially constrained, introducing certain limitations. As a result, on-chain pricing mechanisms—such as TWAPs—can experience contagion effects, where price distortions propagate through the system.

These mechanisms must account for numerous edge cases, particularly in scenarios where a nominally lower sale of YT negatively impacts PT pricing, as outlined in our Mechanism Design Risk Assessment. From a security standpoint, even with time-averaging, TWAPs remain more vulnerable to manipulation. This is because manipulation can often be executed feasibly—especially in cases where collateral utilization is significantly large relative to market size. In contrast, off-chain oracles typically employ aggregation, delays, and additional protective measures, making them more resistant to such attacks.

PT Risk Oracle Solution

PT Token Dynamic Risk Profile

As previously discussed and illustrated in various plots, the risk profile of the Principal Token (PT) decreases as the asset approaches maturity. Due to the pool’s market proportion constraint, we can dynamically determine that the maximum potential price drop for PT diminishes over time. As maturity nears, the market price becomes increasingly confined within a tighter range.

This reduction in price volatility means that any decline in PT’s value—relative to its upper bound—becomes progressively smaller. The accompanying plots illustrate this effect, showing how the liquidity distribution density converges over time. Additionally, they highlight the relationship between the minimum PT token price, the expected price, and the maximum implied APY for this market as maturity approaches.

pendle_animation_0.4_6.35_b_output

pendle_animation_0.0_31_b_output

The animation on the left illustrates the liquidity dynamics of a pool, without trades, with high expected yield and a relatively small scalarRoot, highlighting how liquidity can be distributed over a bigger range if necessary.
The animation on the right illustrates the liquidity dynamics of a pool without trades, with a small expected yield relatively large scalarRoot, highlighting how liquidity remains concentrated around the implied exchange rate but narrows the effective trading range.

Given this relationship, risk parameters such as LT (Liquidation Threshold) and LB (Liquidation Bonus) can be quantified dynamically and multidimensionally—as a function of time to maturity and expected implied rate volatility. This allows for an optimal adjustment of max LTV, LT, and LB over time, reflecting the positive drift of PT as it converges toward SY at maturity, alongside reduced price variance due to the monotonic increase in liquidity pool concentration.

This effect is illustrated in the plot below, which represents the amount of liquidity available under 3% slippage for the PT-sUSDe May listing as the market nears expiry, given the current liquidity distribution within the AMM. As the market matures, slippage associated with PT swaps becomes progressively less extreme. This trend is particularly pronounced for assets with lower scalarRoot values, which exhibit greater expected implied yield fluctuation and inherently higher variance in liquidity concentration.

Optimal PT Pricing Methodology

Building on the principles outlined above, we establish an optimal pricing strategy for PTs by integrating the most effective elements from both pricing mechanisms. This approach combines a manipulation-resistant off-chain algorithm to determine the effective implied market rate with deterministic components dynamically tailored to the asset’s risk profile.

A Risk Oracle smart contract processes the lnimpliedrate—a logarithmic representation of the implied APY—before being converted into the PT price in a manner akin to providing continuous recommendations for the Correlated Asset Price Oracle (CAPO). This ensures that pricing remains closely aligned with relative market conditions, enhancing accuracy and resilience against manipulation.

PT Pricing Strategy

The pricing strategy emphasizes a structured, market-driven valuation for PTs, ensuring an accurate and reliable pricing mechanism. Unlike a continuously updated TWAP, this off-chain algorithm updates the lnImpliedRate only when the internal deviation threshold—set at 1% in PT price terms—is exceeded, alongside a configured heartbeat. The internal computation of the lnImpliedRate incorporates duration-based factors, requiring a significant time lapse before adjustments occur. This approach ensures that rate updates only take place when a meaningful market-driven price deviation exists, reducing the risk of manipulation.

Moreover, with the deviation threshold remaining constant in PT price terms, its impact evolves dynamically with time to maturity. As illustrated above, the asset’s risk profile and expected volatility naturally diminish as maturity approaches. Consequently, as shown in the plot below, the lnImpliedRate Delta required to trigger a rate update grows exponentially over time under the 1% price deviation threshold, following:

This results in a logarithmic decline in update frequency, ultimately converging to zero as maturity nears. For context, the maximum hypothetical lnImpliedRate change in the PT-sUSDe-29MAY2025 market—assuming an oracle price movement from its highest to its minimum price—is 17.09%. Under this framework, the PT-sUSDe price would effectively cease updating once it reaches 21 days until maturity, converging deterministically thereafter.

Any interest accrual resulting from rate mispricing relative to market value would be minimal, as the frequency of updates naturally decreases as the asset approaches maturity. This effect is further mitigated by the implemented risk controls, ensuring stability and alignment with market conditions.

Moreover, since PT price is logarithmically defined in relation to implied APY, triggering a new rate update requires a larger effective APY shift for higher lnimpliedrate values. This ensures that rate adjustments align with the asset’s expected volatility. As maturity approaches, market prices naturally converge toward the oracle price, reducing the need for frequent adjustments. Additional safety precautions at the minimum price, which will be explored in the next section, further reinforce this.

Below is a simulation of the streamlined rate algorithm for the PT-sUSDe26DEC2024 market, assuming a 0.5% deviation threshold and no heartbeat (for further visuality). The simulation also presents the performance of alternative price trajectories, including:

Market Rate and Price – Tracking real-time movements.
Expected Price (1 / Rate Anchor) – The theoretical price derived from the rate anchor.
linearDiscountOracle – Calculated with a 25% base discount per year to provide a structured rate adjustment.

As observed, the required lnImpliedRate to warrant an update grows significantly over time.

Secondary Pricing Component

Each SY token contract calculates an exchange rate that determines the value of each SY token—and, by extension, each PT at maturity—in terms of the underlying asset. This rate ensures accurate yield pricing and guarantees that 1 PT redeems for exactly 1 unit of the underlying asset at maturity. The method for determining this exchange rate varies based on the underlying token: some contracts use fixed rates (e.g., LBTC, where yields are not compounded), others query the yield-bearing token’s smart contract directly (e.g., sUSDe), and certain assets rely on Pendle’s custom off-chain oracles (e.g., rsETH).

For example, the value of PT-sUSDe is anchored to 1 USDe per SY token at maturity, rather than 1 sUSDe. Consequently, the asset’s aggregate pricing is implicitly defined by the underlying exchange rate, represented as:

sUSDe(SY) * PT price * (1/(sUSDe/USDe exchange rate)

Notably, this formulation is intentionally redundant, as sUSDe must be the input asset in this context.

Tertiary Pricing Component (Underlying)

This component primarily involves anchoring the quote asset to USD. In ETH-anchored markets, this is relatively straightforward. However, USDe can theoretically follow multiple pricing methodologies, as extensively discussed in this thread.

Currently, Spark Morpho Vaults underwrite PT-sUSDe using a LinearDiscountOracle, with USDe hardcoded to 1. Meanwhile, a proposal to adjust the configuration from a USDe/USD market feed to a USDT/USD feed on Aave is currently at the ARFC Snapshot stage.

Conditionally Setting LTV to 0 When Reaching Minimum Price (Killswitch)

As outlined in the TWAP section, the minimum price represents the point at which the AMM reaches the market proportion constraint of 96% in PT.

At this stage, the AMM can no longer facilitate liquidity provision or influence price downward movements. However, within the internal market order book, the PT can still be permissionlessly priced below this threshold if the implied APY surges significantly relative to the time to maturity and the configured range. This mechanism provides a potential avenue for acquiring the underlying PT token at a market-determined value.

Thus, when the minimum price is reached, there exists a “killswitch” functionality within the risk oracle, in which the LTV ratio is automatically set to 0, effectively freezing the market. This ensures that new debt cannot be issued when market prices fall below the oracle’s minimum hypothetical valuation, preserving the integrity of the system. By setting LTV to 0, Aave remains insulated from arbitrage risks that could arise if the traded price of PT drops below the oracle-reported minimum price, as well as surging interest rates while the underlying rate of collateral appreciation remains fixed at the maximum implied APY within the AMM yield range. Moreover, on the flip side, the possibility of liquidating debt positions would likely be infeasible, either due to a significant market price deviation coupled with sporadic and potentially sparse liquidity. The implications of such a configuration imply that the lending market can feasibly mitigate risks associated with an implied APY repricing event, given the fact that the initialized liquidity range is immutably configured by Pendle at market genesis.

Once reaching the tail of the market, the trigger for unfreezing the market leverages the reasonable trading range of 90%, as referenced in the liquidation bonus section.

Pause LTV: (LTV=0)

Where PT and SY are the nominal token values, not normalized by the price.

Re-enable LTV:

Threshold for re-enable: 0.9
if in the last 3 days, 80% of the time pool ratio was below the re-enable threshold
And the current ratio is below the re-enable threshold

→ activate LTV again using the function above.

Dynamic Liquidation Bonus

The Liquidation Bonus can be dynamically defined as the relative difference between the minimum reasonable trading range price and the expected price, where liquidity density is at its highest. This definition emerges naturally from the concept of continuously concentrating liquidity with respect to price.

A key parameter in this framework is the scalarRoot (or rateScalar), which effectively serves as the variance component of the liquidity distribution. It also acts as a representation of the expected price volatility relative to the expected value, rateAnchor (or initialAnchor). The derivation of this parameter is crucial in determining the “reasonable trading range”, spanning from 10% to 90% proportion p of the AMM pool, as mathematically outlined in the Pendle whitepaper. This is illustrated through the function ln(p/ 1−p), which highlights that price impact increases substantially when p > 0.9. Consequently, liquidations are not expected to occur beyond this threshold. Mathematically defining our lowerTradingRangePrice_t:

Furthermore, this representation aligns with the expectation of liquidation events arising due to downward PT price movements. It accounts for a combination of factors: the expected frequency of liquidations, the price level where liquidity is most concentrated, and the lower bound of the trading range where liquidators can efficiently execute liquidations before liquidity becomes too thin.

The relationship between the minimum price and the minimum reasonable trading range price can be expressed logarithmically over time, reflecting the downward convergence of expected volatility. The plot below visually represents this trend.

Interplay with Underlying Asset LB

The mathematical derivation can be expressed in the context of the Pendle AMM framework. However, when considering a scenario where the correlated debt asset differs from the underlying asset, the liquidation process involves two sequential steps:

Conversion of PT to SY (the underlying asset)
Exchange of the underlying asset for the debt asset

This creates a two-legged liquidation event, requiring liquidators to be compensated for both steps. A defined exchange rate governs the PT-to-SY conversion—for example, sUSDe/USDe—meaning potential market price deviations may necessitate additional compensation. To maintain proper incentives, the liquidation mechanism should incorporate an additive compensation structure, leveraging the underlying asset’s liquidation bonus available in the market.

Dynamic Liquidation Threshold

To dynamically model the Liquidation Threshold, we establish a worst-case scenario condition that ensures bad debt does not accrue. This requires maintaining the inequality:

This inequality accounts for the worst-case price movement of the PT token, assuming that its price, starting from 1, converges to the minimum possible value without any Oracle updates within the timeframe. This assumption considers the collateral obtained by a prospective liquidator, both adjusting dynamically, under the assumption of no net interest accrual.

Given the inverse relationship between the PT token price and implied yield—where the PT price deterministically converges to 1 as it approaches maturity—the LTV 0 constraint plays a crucial role in preventing debt accrual from mispriced PT collateral. Furthermore, in such a scenario, the expectation that the oracle updates in a controlled manner—particularly in response to significant changes in implied APY—ensures that the expected rate of collateral appreciation is redefined after an initial price drop. This mechanism helps stabilize the system by aligning liquidation dynamics and collateral valuation with updated market conditions. As a result, this structure significantly reduces the likelihood of net interest accrual, further reinforcing the validity of the inequality governing the Liquidation Threshold.

Below, we illustrate the dynamic liquidation threshold for PT-sUSDe-29MAY2025 as it converges toward maturity. Under our proposed implementation, the liquidation threshold is determined as the minimum between the calculated LT and the underlying LT currently used in the market. This approach ensures an additive structure that fully accounts for the risk profile of the underlying asset, maintaining a robust and adaptive liquidation framework.

Additional Considerations

PT Collateral Debt Assets

This framework assumes that the protocol does not permit traditional collateralization of PTs in a generalized manner. Instead, borrowing is restricted to assets that are either directly correlated with the PT token’s underlying asset or exhibit strong correlation through Liquid Emode configurations. This approach minimizes the impact of market volatility and helps maintain stable collateral-to-debt ratios.

Restricting PT Borrowing

At maturity, a sharp increase in PT token withdrawals is expected, potentially straining liquidity if PT were borrowable. Furthermore, the borrowing mechanism—where an attacker can buy YT by borrowing SY from the pool, minting PT and YT, and then selling PT back to the pool—creates an opportunity to artificially suppress PT’s price with minimal capital. These combined risks suggest that allowing PT borrowing would introduce unnecessary market vulnerabilities. To mitigate these tail risks and ensure sufficient liquidity for withdrawals, we strongly advise against permitting PT borrowing in any protocol.

Pendle Market Parameterization

The feasibility of listing specific PT tokens additionally depends on the Pendle market’s parameterization. If the implied APY range is too narrow relative to the expected underlying APY, the likelihood of hitting the minimum price increases. Therefore, when evaluating new listings, it is essential to assess the asset’s implied APY range to determine whether it aligns with sustainable market dynamics.

Underlying Asset Integration

Before a PT can be listed, its underlying asset must first be deemed suitable for listing on Aave, having met the necessary criteria, including the associated implied Secondary Pricing Component enshrined within the PT pricing structure.

PT Underlying as Debt Asset

If the underlying debt asset is configured to be the underlying of the PT token, we will no longer adhere to underlying parameters given the correlation with its underlying counterpart. For instance, LBTC-denominated debt for PT-LBTC collateral would result in a parameterization that solely looks at the Pendle AMM, thereby further increasing capital efficiency.

Benefits of Utilizing Chaos’ Risk Oracle

The pricing mechanism is structured as a function of time to maturity and market-implied yield, ensuring a manipulation-resistant market price. It updates more frequently when far from maturity and follows an effectively deterministic price trajectory as maturity approaches, aligning with tail risks.
The killswitch mechanism prevents toxic debt accumulation at the minimum price, mitigating excessive interest rates and maintaining liquidity stability even if the price moves out of range.
Capital efficiency improves as the market nears maturity, with LT increasing and LB decreasing, aligning with the asset’s evolving risk profile.
Net interest accrual is reduced when the deterministic linear discount oracle rate is replaced by an updated, higher implied rate. However, deterministic behavior emerges only as the market nears maturity, minimizing cumulative net interest accrual.
Liquidators remain well-incentivized through the updated oracle, ensuring efficient market operations when intervention is necessary.
The mechanism eliminates the risk of AMM TWAP manipulation, reinforcing market integrity.
Systemic events occurring within the underlying asset are greatly mitigated due to the associated risk controls.

Disclaimer

Chaos Labs has not been compensated by any third party for publishing this proposal. The Pendle team has compensated Chaos Labs for the referenced risk reports.

Copyright

Copyright and related rights waived via CC0

PaperImperium · February 7, 2025, 12:51am

Was Chaos Labs compensated by Pendle for these reports? If so, this should be in the disclaimer about conflicts of interest.

Edit: This has now been fixed. Thank you for the prompt revision.

EzR3aL · February 9, 2025, 6:47pm

Hello, I do have a few questions regarding the proposal and Pendle itself.

What does that mean, and how is it manipulation resistant? How does it work that it cannot be manipulated?

What are significant price changes?

What are the trade-offs and inefficiencies of using the Risk oracle? Maybe compared in a table against the other two options mentioned.

This means this is the SPOF and a centralized system in combination with an algorithm the DAO has to trust? Who is in control and what would happen is someone would “switch it off”?

What would happen if the risk oracle decides to set LTV to 0 because of low liquidity but there would be the need to liquidate positions and there isn’t enough liquidity? Aave would end up in bad debt. How to make sure that liquidatiions are basically available all the time?

In general, how much upside does the DAO have for example implementing a Pendle token only market?
Is there such big demand to borrow against those positions that it makes sense to take the risk associated with this type of collateral?
Again, im not very familiar with Pendle as I haven’t used it yet for any kind of strategy. Im just trying to understand what kind of risks we have. Especially thinking about Ethenas stablecoin related Pendle token which basically create another layer of risk together with the already big sUSDe market Aave has.

ChaosLabs · February 11, 2025, 11:43pm

Thank you for the thoughtful questions and response, @EzR3aL. We appreciate your request for a deeper understanding of the system’s technicalities.

The proposed oracle system integrates the PT implied rate into an Aave smart contract, which ingests the rate to establish a price relationship between PTs and their underlying “anchor” assets. Typically, this anchor corresponds to the SY token’s underlying asset, though variations exist depending on the specific PT (e.g. PT-sUSDe to USDe, PT-stETH to stETH).

The provided implied rate serves as the foundation for determining exchange rate dynamics, while additional pricing components are sourced from existing oracle infrastructure. This approach ensures a robust, efficient, and manipulation-resistant framework for pricing and risk management.

Manipulation Resistance

The system’s resistance to manipulation stems from its rate update mechanism and time-weighted algorithm. To submit a new implied rate to the contract, the calculated PT price must deviate beyond the last recorded update, as determined by the PT rate-to-PT price relationship. This means an attacker would need to sustain an artificial price shift for a significant period to trigger an update. Additionally, the oracle enforces a minimum price and ties the dynamic liquidation threshold to this floor, making manipulation economically impractical.

Practical Implementation

For additional context, it’s important to understand how the Oracle system works today within Aave for LSTs and LRTs, as well as any asset that expresses an aggregation of many different feeds to derive the final price in USD. For example, the referenced wstETH price leverages the following aggregate structure:

First component: wstETH/stETH exchange rate sourced from the stETH token smart contract by querying getPooledEthByShares with an input of 10^18, providing a representation of the nominal ETH in the Lido system (total staked + historical staking rewards), relative to the amount of stETH in circulation. This ratio is colloquially known as the exchange rate.
Second Component: In order to minimize artificial growth in the exchange rate under specific adverse manipulative scenarios, there exists a secondary component that limits the maximum exchange rate growth of the asset, known as the Correlated-Asset-Price-Oracle (CAPO), governed by getMaxYearlyGrowthRatePercent. This is determined by Risk Providers, and can be altered through the Risk Steward today, quantified as a holistic upper bound on the maximum exchange rate growth observed during a specified timeframe.
Third Component: The protocol operates under the assumption that stETH presents a 1:1 representation with ETH itself, given by the inherent ability to withdraw stETH and obtain the underlying ETH with a predefined duration through the Ethereum Consensus Layer Exit Queue. Moreover, when a Lido oracle report occurs, the token supply adjusts algorithmically based on staking rewards, slashing penalties, execution layer rewards, and withdrawal requests. During a significant slashing event, Lido may activate “bunker mode,” temporarily pausing withdrawals to prevent opportunistic exits and socializing losses among stETH holders. In such cases, totalPooledEther decreases, leading to a proportional reduction in stETH supply, ensuring stETH maintains its 1:1 backing. For wstETH, the wstETH/stETH ratio decreases accordingly, reflecting the socialized loss and preserving its proportional representation of stETH.
Fourth Component: Finally, to derive the price in USD terms, the protocol utilizes an ETH/USD feed provided by Chainlink. So, overall, the implementation of the wstETH price on Aave, as referenced in the description of the oracle itself, can be thought of as Capped wstETH / stETH(ETH) / USD.

Proposed Aggregate Oracle Implementation

As above, our proposed implementation captures only a portion of the full expression of the PT token’s price in USD terms. The quantified PT rate is integrated into an Aave-implemented smart contract, which determines the PT token’s price relative to its underlying “anchor” asset. Typically, this anchor asset corresponds to the underlying asset of the SY token, establishing a fundamental exchange rate that resembles—but functions as a derivative of—the exchange rate oracles currently used on Aave. For instance, PT-sUSDe is anchored to USDe, while PT-wstETH is anchored to WETH. In some cases, this structure varies: the SY token itself may serve as the anchor (e.g., PT-beraSTONE to beraSTONE), or the asset may lack an existing exchange rate (e.g., PT-LBTC to LBTC).

Broadly speaking, the component provided by Chaos Labs can be viewed as a specialized algorithm that represents the implied rate, which is then utilized to calculate the underlying exchange rate of the PT, which is only the first component in deriving the final price of the PT in USD. As outlined in the Secondary and Tertiary Pricing Component sections, the remaining elements required to price the asset in USD terms will be sourced from existing Oracle infrastructure. This includes the Chainlink ETH/USD Oracle for WETH-anchored PTs, the USDT/USD Oracle for USDe-anchored PTs (pending AIP approval), and the BTC/USD Oracle for BTC-anchored PTs, among others.

The equivalent implied rate corresponds to a 1% PT price deviation threshold, determined by the time-weighted algorithm that governs the implied rate calculation. Refer to the explanation above for details.

The risk oracle enhances existing solutions by addressing inefficiencies through its streamlined rate infrastructure, dynamic risk parameterization, and killswitch mechanism. Overall, it serves as a purely additive improvement. We have detailed these components extensively in the report; below, we outline key design trade-offs at a high level.

	linearDiscountOracle	Market TWAP	Chaos Risk Oracle
Liquidations	No expected liquidations. Significant interest accrual may make positions eligible, but such positions would not be liquidated and potentially accrue bad debt.	Liquidations depend on market price and TWAP length configuration. Depending on its configuration and the lending market size, this can trigger cascading liquidations, given the underlying speculative-driven market where fundamental arbitrage mechanisms are weak or absent.	Liquidations can occur depending on the associated implied rate updates. Defining periodic “market rate” updates only when a significant relative price deviation persists over a substantial period leads to two key implications: (1) The frequency of rate updates is correlated with the asset’s expected volatility as time to maturity approaches zero. (2) The risk of “accidental liquidations” is mitigated, as price manipulation concerns do not arise.
Capital Efficiency	Highly capital-efficient when the implied yield is within the configured baseDiscountPerYear. However, significant underpricing can occur, especially for assets with high implied yield and long maturity. The linear pricing model may misalign with expected implied rates at higher values.	With fixed risk parameterization, assets are priced conservatively based on market conditions at listing, reducing capital efficiency by leaving potential gains unrealized.	Risk parameterization scales dynamically as a function of expected volatility and associated duration risk. Depending on the configuration of the Pendle market (implied yield range, time to maturity, etc) initial parameterization at Pendle market genesis will be at its most conservative, which implicitly aids the assumption that AMM liquidity is likely to be insufficient when the market initially launches and its furthest to maturity.
Tail Risks	Faces multidimensional risks from asset overpricing. If market price deviates downward, users can arbitrage or drive interest rates above the collateral appreciation rate. Lacks protection against low AMM price and liquidity shortages.	Technical risks arise from on-chain TWAP calculations. No safeguard against minimum AMM price or liquidity issues.	The oracle mitigates risk by freezing the market during extreme events, preventing excessive debt accumulation while ensuring risk parameterization aligns with a no-bad-debt assumption. In Aave’s worst-case scenarios—such as technical risks of the underlying asset or economic shocks—the payoff can nearly resemble that of the vanilla underlying asset listed on Aave given its oracle configuration (e.g., sUSDe). However, for LSTs and LRTs, exchange rate dynamics can introduce additional complexities. These worst-case scenarios can become significantly worse when utilizing the other pricing strategies.

We recommend viewing the above as a high-level overview. For a deeper understanding of the underlying mechanics, please refer to the full report.

The Edge Infrastructure supporting all Risk Oracles is currently provided by Chaos Labs. We are collaborating with BGD Labs to implement a set of on-chain enshrined constraints, ensuring that the associated dynamic infrastructure remains technically limited at the contract level. These constraints include enforcing a maximum implied rate within the smart contract, guaranteeing that even in the event of an oracle failure, the Aave protocol will never report a price lower than the predefined minimum.
As previously mentioned, this minimum price does not introduce bad debt and naturally converges to the underlying asset’s value at maturity. At that point, the PT can simply be burned for the underlying asset or sold on the market.

PT tokens are always redeemable for their underlying asset at maturity, ensuring their value converges to a 1:1 relationship and inherits the asset’s on-chain liquidity. If liquidity is minimal before maturity and the market becomes frozen, outstanding eligible positions can either be liquidated at maturity or earlier if Pendle AMM liquidity returns before expiry.

Our mathematical derivation of the dynamic Liquidation Threshold shows that even in a worst-case scenario—where a user takes on maximum debt at the highest PT price of 1 (0% implied yield), followed by a drop to the minimum price (maximum implied yield) while absorbing all available AMM liquidity—the protocol remains protected from bad debt.

If the PT price declines and triggers liquidations, the implied rate rises due to the inverse price-yield relationship, effectively reflecting the annualized rate of collateral appreciation. Combined with safeguards against exploitative debt issuance (LTV 0), the debt position’s health is expected to improve over time, allowing for full offloading at maturity. Alternatively, if liquidity returns before maturity, positions can be liquidated by any market participant.

Finally, for a PT token to be listed, its underlying asset must already be approved on Aave, ensuring fundamental robustness.

EzR3aL · February 12, 2025, 12:41pm

Thank you for the detailed answer. Its helping a lot to better understand some mechanics.
But I still do have one main question.

So overall this would be a combination of Edge oracles, which we are using right now for dynamic parameter changes, but also now price oracles. Am I correct?
It would be a ChaosLabs inhouse built price oracle instead of the Chainklink DON we are using right now for every other asset listed on Aave.

Why aren’t we going this way then

Chaos creates framework for risk management as risk SP
Llama gives second opinion as risk SP
Chainlink is building the oracle as oracle provider

That way we take the expertise of several parties in their designated fields and make sure we use the same decentralized infrastructure we are using right now for pricing assets on Aave.

There may be trade-offs I don’t see right now, for example in terms of TVL and borrowing power for an user, but in the end its about security. This is and has always been top notch at Aave because we have experts in different fields doing their best.
And as an Aave user myself I prefer security over a few percentage of extra yield. We don’t need to be much better than our competitors using Pendle token, but getting as close as possible is probably enough for them to migrate to Aave.

LlamaRisk · February 14, 2025, 5:10pm

Summary

The integration of Pendle within Aave represents a sizeable opportunity, where the goal of becoming the most capital-efficient home for Principal Tokens (PT) must be balanced with technical, economic, and counterparty risks. Here are our priorities as an Aave DAO risk provider:

Clear separation of critical pricing infrastructure and Risk Functions: Critical pricing infrastructure must operate independently from risk advisory functions—just as risk management is separate from growth strategies. While efficiency and automation are valuable, integrating risk advisory directly into critical pricing infrastructure could compromise the credible neutrality of price data transmission. Historically, Aave has only used pricing directly from Chainlink’s DONs or the asset issuer.
Balancing capital efficiency, simplicity, and risk: While the dynamic pricing method through @ChaosLabs’ Edge Oracle offers notable capital efficiency, increasing the number of adjustable parameters also demands more rigorous oversight. Our testing indicates that adjusting distinct parameters within the proposed methodology may be necessary for safety during varying market regimes. However, streamlining these parameters can simplify on-chain implementation, boost predictability, and strengthen long-term stability and auditability while delivering enhanced capital efficiency compared to other venues. Moreover, reducing complexity minimizes unnecessary operational and centralization risks.
Ethena exposure and pre-umbrella deployment: Given that the Pendle protocol currently contains a significant proportion of Ethena assets, and considering our recent cautionary warning on sUSDe market liquidity, adopting a conservative exposure on Aave until Umbrella is activated is imperative. This precaution is especially critical since the intended use case pertains strictly to PT and its underlying assets, designed for leveraged looping.

Given the above, we advocate for a simpler, entirely onchain executable solution: the Exponential Lower Bound (ELB) method. Our preferred solution enhances capital efficiency, especially during the early market phase, while delivering a conservative pricing curve that mitigates overpricing risks. Such risks arise when inflated PT prices distort collateral values and borrowing power, potentially leading to rapid overexposure to a given asset and heightened risks of accruing bad debt. Below is our detailed analysis for stakeholder consideration.

We believe this ARFC vote should allow stakeholders to vote on their preferred pricing method for PT.

Detailed Analysis

In this section, we detail and compare three pricing methodologies for PT tokens—Linear Lower Bound (LLB), Edge Oracle (EO), and Exponential Lower Bound (ELB)—and discuss system safeguards and comparative performance.

1. Linear Lower Bound (LLB) - least capital efficient

We previously recommended using a linear lower bound to price PT tokens on Aave. It is a straightforward approach that some of Aave’s competitors have successfully adopted. This method consistently underpins the Principal Token (PT) price in expectation, even in worst-case scenarios, by considering the maximum expected yield configured in the Pendle pool. The primary advantage of the LLB lies in its simplicity and predictability for borrowers. Additionally, it can be fully implemented onchain, reducing reliance on external components. However, as demonstrated by @ChaosLabs, the LLB decreases capital efficiency, particularly over longer durations or in high APY environments. The analysis provided highlighted extreme scenarios—such as 100% APY—which, while theoretically possible, are typically observed in highly speculative assets that do not align with Aave’s lending market. That being said, it is true that the LLB is less capital-efficient than other pricing methods and that there is room for improvement.

2. Edge Oracle (EO) - Max efficiency but complex and offchain components

The oracle proposed in this ARFC utilizes a TWAP mechanism with an exponential threshold, updating the on-chain price as infrequently as possible. This method outperforms the linear lower bound (LLB) in pricing efficiency. However, infrequent updates and yield volatility may temporarily lead to overpricing of PT. When coupled with high LTV ratios, this overpricing can turn Aave into a repository for PT assets, as users exploit near-100% loan values by purchasing PT tokens, depositing them on Aave, and looping the process. This could result in accrued bad debt and impede profitable liquidations.

@ChaosLabs proposes dynamically adjusting the LTV, Liquidation Threshold (LT), and Liquidation Bonus (LB) to mitigate these risks. Our testing indicates that modifying distinct pricing parameters is likely to be necessary under different market regimes. While this flexibility improves market responsiveness, it also increases complexity, complicating onchain implementation, predictability, stability, and auditability.

Additionally, the offchain implementation of this complex pricing method—relying on an external price oracle managed by a risk provider—raises concerns about centralization and transparency. As @EzR3aL noted, best practice recommends separating the roles of price feed and risk providers to avoid conflicts of interest. Implementing the pricing method on a Decentralized Oracle Network (DON) could enhance decentralization and transparency, though it would add another layer of complexity that must be carefully managed.

3. Exponential Lower Bound (ELB) - Balanced middle ground

Building on @ChaosLabs analysis, we propose an Exponential Lower Bound (ELB) as an alternative that enhances capital efficiency compared to the linear oracle while maintaining simplicity and the possibility of an on-chain implementation. This approach effectively addresses concerns related to centralization while ensuring predictable behavior. As demonstrated by @ChaosLabs, under normal market conditions, the PT price follows an exponential trajectory over time due to the effects of interest compounding. Considering such an exponential trajectory in a worst-case scenario, underpricing the PT until maturity consistently is possible.

Similar to the previously proposed LLB, our ELB is calibrated using the maximum expected yield configured within the Pendle pool. This approach ensures that the PT remains consistently underpriced under normal conditions, guaranteeing the protocol’s safety and borrower stability. Given the expected use case of leveraged looping of PTs with their underlying assets, we believe stability should be prioritized over absolute capital efficiency. Moreover, this method demonstrates superior efficiency over competing approaches.

The ELB presents an optimal balance between capital efficiency, safety, and transparency and a competitive alternative to the linear lower bound from a business standpoint.

Modeling different solutions

We compare the proposed pricing methods by visualizing their performance under different conditions. Our plots include three Edge Oracle curves (using different thresholds), the exponential lower and linear lower bound. To illustrate capital efficiency, we analyze two Pendle-onboarded assets with varying APY levels—PT-weETH (normal APY) and PT-ENA (high APY). This comparison highlights the similarities and differences in PT token pricing through a working example and simulations across different APY levels.

Edge Oracle (EO)

The Edge PT Oracle adjusts prices when the reported lnImpliedRate deviates beyond a predefined threshold combined with TWAP parameters. These settings can be tailored per asset, allowing us to examine their sensitivity and impact on Oracle’s reported price.

Observations:

Thresholds: Higher thresholds result in fewer updates and greater underpricing. This effect is more noticeable in lower APY tokens like PT-weETH, whereas lower thresholds help capture temporary price fluctuations for volatile assets like PT-ENA.
TWAP Intervals: Longer TWAP intervals reduce sensitivity to short-term volatility, while shorter intervals (e.g., 0.1 days) enable rapid responses to sharp market changes, as seen with PT-ENA.

Considerations:
To balance update frequency and stability, a 1-day TWAP is preferred. Threshold values should be calibrated individually based on asset-specific risk assessments.

Linear Lower Bound (LLB)

The LLB Linear Discount model employs a single rate parameter. By default, Pendle sets MaxRate to mitigate overpricing risk; using a custom rate may introduce risks, as seen with PT-ENA, although overpricing is minimal with the default value. Therefore, while it was pointed out that baseDiscountPerYear can trade significantly above the market price due to potential downward price volatility, discounting with a MaxRate demonstrates minimal overpricing even in downward pricing shocks. The observed sharp PT-ENA price movements support this example.

Observations:

The model leads to significant underpricing in the early stages.
While this may suit certain PT pricing curves, the PT-weETH example indicates that a linear discount may not capture all asset price dynamics. PT-weETH pricing curve follows a steeper logarithmic curve, suggesting an exponential reduction in expected APY over time.
Due to that, the LLB model fails to fit the PT-weETH curve when using any curve, contrary to PT-ENA, where a 20% rate fits the curve accurately. Such steep pricing curves reflect market consensus misalignment, which may stem from speculative activity, e.g., related to the points programs.

Considerations:

Stick with the default MaxRate to minimize overpricing, especially for volatile assets.
Evaluate the suitability of a linear discount on a per-asset basis; if early-stage underpricing is an issue, consider alternative pricing strategies.
PT pricing movements are very volatile in the early bootstrapping phase of the PT market (10-15 days); markets are expected to be onboarded after the period ends, lowering overpricing risks.

Exponential Lower Bound (ELB)

The ELB Exponential Discount model addresses the early-stage underpricing seen with the linear model by considering yield compounding, which results in an exponential trajectory of the PT price through time. However, careful selection of the MaxRate parameter remains critical.

Combined Comparison

The Edge of the ELB compared to the LLB model is visible. @ChaosLabs’s Edge Oracle tracks the price with much higher accuracy, providing a more responsive and dynamic pricing representation; however, when the threshold is set above 1%, instances of overpricing become apparent.

Over-pricing vs. Under-Pricing

Quantifying the risks is crucial, as overpricing presents far greater dangers than underpricing. When the underlying base asset experiences fluctuations, slight overpricing can rapidly erode the safety parameter buffer, intensifying the risk. Additionally, there is a concern that Aave could be used as an exit venue if the overpricing persists. Overpricing under sharp downward volatility is generally temporary due to inherently higher buying pressure. Therefore, these instances are less likely to generate bad debt for the protocol.

The implications of underpricing depend on the model’s consistency. If the pricing model is static (LLB/ELB), underpricing would be of minimal impact since the temporal evolution of the pricing curve is deterministic and non-decreasing, which lets users set more predictive expectations and safety buffers, only needing to align with the underlying risk of base asset. On the other hand, dynamic pricing models (EO) may underprice assets when the price updates are executed due to downward volatility. These updates are susceptible to cause cascading liquidations. Consequently, users must actively manage their positions to mitigate the risk of such unexpected liquidations.

The extent of overpricing is also critical. If the overpricing exceeds the LT-to-LTV buffer, positions that should become liquidatable will remain unaffected, accruing risk to Aave’s lending market. It is important to compare each proposed pricing method to infer the probability and significance of such risks.

PT-weETH

We begin with an overview of PT-weETH. The overpricing issue observed with the Edge Oracle is largely eliminated only when using very high thresholds (around 10%). This behavior is rational because such high thresholds converge the model’s dynamics to those of the exponential or linear models. In contrast, both the linear and exponential models demonstrate the elimination of overpricing when configured with either more conservative or the default MaxRate values.

Furthermore, the overpricing under @ChaosLabs’ Oracle configuration was notably severe. Similar problematic values were observed for PT-weETH, particularly in the first 15 days. This initial period was marked by heightened volatility during the PT price discovery phase when rapid market deployment was not anticipated. Consequently, while the early overpricing is significant, it is less concerning given its occurrence during a transient and volatile period. In the following calculations, we have ignored the initial 15 days of PT price movements to discount these initial pricing movements.

It can be observed that larger, though contained within a 3% buffer, overpricing was observed with EO model pricing. As for ELB, as discussed before, choosing the MaxRate eliminates overpricing completely.

PT-ENA

Similar findings follow for PT-ENA. Here, we observe more frequent overpricing for all pricing methods but can infer the same relationship between the parameter values and mispricing probability. Nonetheless, in this case, choosing the MaxRate still eliminates most overpricing instances, once again supporting the case of selecting the discount rate conservatively.

Given the less speculative nature of the initial pricing for PT-ENA, the real differences in overpricing between the models can be discerned with greater clarity. The differences between EO and ELB methods are much more critical. It can be observed that the overpricing with the EO model would have reached 19-34%, while the MaxRate choice for ELB constrains the overpricing within a 3% threshold:

While the performance of each model highly depends on the PT asset’s volatile nature, the overall findings demonstrate generally larger risk coverage with the LLB/ELB pricing models. As outlined above, this is made available via the conservative MaxRate parameter.

Problematic Cases

It is important to approach PT markets cautiously, as overpricing remains possible. Typically, point programs and speculative yield opportunities will result in yield volatility. Incorrect parameters set into the Pendle pool by the Pendle team or significant changes in the underlying asset could also result in overpricing.

Consider, for example, the case of PT-weETH-27JUN2024, where the Pendle team incorrectly estimated the maximum expected yield for the asset. Our analysis shows that overpricing would have been reached if the MaxRates configuration in the corresponding pool had been used. This is a strong reminder that careful calibration of the lower bound is essential and that we should not blindly use the MaxRates parameter.

Another instance where overpricing would have ensued is the PT-USD0++-27MAR2025. Due to an unexpected change in the guaranteed redemption price of USD0++ by the Usual team, from 1$ down to 0.87$, significant market disruption occurred on USD0++ and the various DeFi applications that integrated with it. As seen below, this resulted in substantial implied yield volatility and severe asset overpricing. In those situations, we believe a manual intervention is necessary to prevent bad debt from accruing.

Other considerations

Circuit Breaker

The ELB consistently underprices the PT price as long as the implied yield remains below the maximum expected yield configured in the Pendle pool. However, swapping within the Pendle ecosystem becomes impossible once the implied yield exceeds this threshold.

Although trading can still occur through the limit order book, where significant liquidity can be accessed, in cases of sustained out-of-bounds implied rates, it is best to pause the market and wait for Pendle to deploy a new pool with updated parameters. This precautionary measure prevents bad accrual for Aave and ensures that profitable liquidations are always possible.

We, therefore, align with @ChaosLabs’ proposal to implement an off-chain circuit breaker that sets the Loan-to-Value (LTV) ratio to 0% to protect the protocol from bad debt scenarios. Additionally, this mechanism guarantees that liquidations remain profitable at all times, preventing cascading failures in volatile market conditions. A Chainlink’s DON providing such a circuit breaker can be implemented to keep a clean separation of concerns.

Disclaimer

This review was independently prepared by LlamaRisk, a community-led non-profit decentralized organization funded in part by the Aave DAO. LlamaRisk serves as a member of Ethena’s risk committee. LlamaRisk did not receive 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 · February 14, 2025, 6:50pm

We appreciate the detailed feedback.

@EzR3aL - To clarify a key point: our proposal focuses on an Edge Risk Oracle for PT Rates, not a price Oracle. This builds on the success of existing Edge Risk Oracles in Aave, which are essential for scaling across 20+ planned network instances securely, efficiently and with industry leading risk controls.

Our extensive research into dynamic rates with real-time risk signals aligns with Aave’s risk management requirements, as we advance and diversify the onboarding of derivative asset classes. During development, we consulted with @bgdlabs (who designed Aave’s current oracle adapters) to validate the technical approach. While they’ve confirmed feasibility, we welcome their additional public feedback and review of final connected components.

Regarding recent @LlamaRisk critiques, it’s important to clarify a few key points:
• The proposed alternative largely repurposes the fallback mechanism within our solution. This is not introducing a fundamentally distinct approach not already addressed by the Edge Risk Oracle solution.
• Llamarisk is using arbitrary PT pricing configurations to suggest significant overpricing in Edge’s implementation. However, these assumptions—such as configuring a 5% price deviation threshold with a much smaller TWAP—do not reflect the actual setup. In reality, as they present, our configuration with a 1% deviation threshold resulted in a P95 overpricing of just 0.71%, which is highly efficient. Cherry picking an arbitrary configuration is misleading at best, or indicates a lack of understanding of the mechanism at worst.
• Llamarisk have not addressed a core aspect of the proposed Edge design: The dynamic parameters in our model ensure that neither bad debt nor arbitrage can accrue, even in scenarios where overpricing occurs. Security and risk mitigation are a key component in the proposed design, and have guided our research towards this solution.
• A specific asset (PT-ENA) with an unusually long duration and a brief 5-minute wick down was selectively highlighted to claim a momentary 33% overpricing. However, PT-ENA is highly unlikely ever to be listed on Aave, making the example misleading and not reflective of practical risk concerns.

• The implementation of an exponential lower bound mechanism in Pendle is not a result of interest compounding, but rather a consequence of discounted pricing shaped by the inherent negative skewness in price returns (e.g., a 50% decrease requires a 100% increase to recover). As a result, the price-to-yield transformation in Pendle follows a logarithmic structure, ensuring that the minimum price aligns precisely with Pendle’s internal pricing model.
• We’ve recently reviewed a similar proposed implementation by Llamarisk; this still carries the same downsides we outlined in our previous response.

After careful considering all points, we maintain that the Edge Risk PT Oracle presents the optimal solution for Aave, balancing the strongest dynamic model, with security and granular risk controls. Given the thorough discussion of both benefits and considerations, we’ll proceed to a snapshot vote for governance decision.

Thank you for your continued engagement in improving Aave’s infrastructure.

bgdlabs · February 15, 2025, 11:09am

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.

RaoulSchipper-CLL · February 15, 2025, 7:50pm

Hey everyone, Raoul from Chainlink Labs here.

As the price oracle provider for all Aave market deployments over the past five years, Chainlink stands ready to support Pendle Protocol’s Principal Tokens. Chainlink DONs are equipped to use any pricing methodology for both the PT and underlying rates desired by the Aave community, including the methodologies proposed by @ChaosLabs and @LlamaRisk, or a different approach. It is our strong recommendation Aave avoids introducing new infrastructure and instead leverages Aave’s established model of using Chainlink’s Decentralized Oracle Network (DON) infrastructure to bring this data onchain in order to maintain the same security, reliability, and neutrality guarantees that Aave has for all other asset pricing. The ethos of decentralization has been the bedrock of Aave’s security and reliability, and there is no reason to begin introducing unnecessary risk vectors and centralization.

Chainlink DONs have ensured Aave has had continual access to reliable, accurate pricing data, even during the most extreme market volatility, blockchain network congestion, and black swan events (e.g., FTX collapse). The result is five years of continual operation, without a single oracle-related incident impacting user funds.

Additionally, given the dynamic nature of the PT/underlying rates, the future expansion of Chainlink Smart Value Recapture (SVR) to these markets will require PT pricing methodology delivered through Chainlink DONs to recapture the value leakage that occurs with liquidations caused by PT-token rate updates. Given the correlated nature of PT-tokens with the underlying assets, the majority of OEV in these markets will be due to the exchange rate changes.

Chainlink DONs are highly flexible and agnostic to the pricing methodology required for a newly supported class of assets, such as Pendle Tokens, while maintaining strong decentralization guarantees.
Maintaining Aave’s decentralized approach to risk by using Chainlink’s feeds would also maintain the neutrality and separation of risk advisory and price oracle infrastructure, reducing risks that come with one actor playing both roles.

We’re here to help ensure the continued success and safety of Aave for years to come

ChaosLabs · February 16, 2025, 3:02pm

As reiterated numerous times, Chaos Labs is providing a Risk Oracle, while the actual pricing component within the system is done through @BGDLabs. Edge is providing a rate, based on the algorithm and risk framework detailed above, created in conjunction with the asset issuer, Pendle.

Chaos Labs Risk and Edge have been integral to Aave for the past two years, operating across every network through Risk Stewards. Rather than introducing a new concept, Edge streamlines and enhances this existing framework, enabling the necessary scale to support Aave’s 25+ deployments. With the DAO already voting in favor of Edge, it is now live and actively contributing to Aave’s risk management. Given the complexity and scale of Aave’s ecosystem, effective risk management would not be possible without Edge Risk Oracles, which play a crucial role in ensuring system integrity and scalability.

Building on this infrastructure, the proposed PT oracle emerges as the most effective and optimal solution for this asset class. Moreover, the technical risks associated with its integration are minimal, with a systemic nature that remains largely abstracted from traditional decentralization and liveness concerns. The specific setup of such a system is not new to Aave, as explored further below.

Technical Risks

Unlike continuous systems that require stringent liveness contingencies, this system operates in a highly discrete manner, generating updates once every 24 hours. The underlying algorithm for deriving the risk oracle’s components is designed with this structure in mind. Even in scenarios of sharp and sudden rate volatility, the system does not automatically adjust its reports to reflect such fluctuations in real-time. Instead, the risk oracle represents a factual market rate averaged over a significant period. Consequently, liveness concerns are significantly mitigated, as the marginal difference between an immediate update and one triggered slightly later has little impact on the overall outcome.

Additionally, the ingested rate naturally converges toward a stable price value, regardless of whether a rate update occurs. Even in the absence of any updates, the price at maturity would still align with its anchored value (1:1). The system’s deeply integrated risk parameterization is designed to respond dynamically to this convergence, ensuring that, under any rate update, it remains mathematically safeguarded against bad debt. This tight linkage between rate updates and risk parameterization reinforces the system’s resilience, positioning risk management as the foundational backbone of its design.

From a technical standpoint, robust fallback mechanisms mitigate risks in the event of an Oracle failure. Any rate update written on-chain is strictly constrained and cannot exceed the maxRate parameter embedded within the smart contract developed by BGD, akin to a CAPO implementation. As previously mentioned, this constraint ensures that no adverse scenarios arise for Aave, as the rate is derived through a rigorous risk framework.

On the LT/LB side, the smart contract enforces an additional safeguard, limiting updates to a highly constrained maximum every 24 hours, regardless of market conditions. This tightly controlled framework, combined with the system’s interconnected mechanics, ensures seamless operation without risk exposure to the DAO.

Alternative Aave Oracle Implementations

It’s important to once again note that, despite claims to the contrary, Chainlink is not the sole price provider for Aave in all realms, especially in the context of deriving exchange rates. This principle applies to most LSTs and LRTs, as well as sUSDe, where the exchange rate is fundamentally derived directly through native smart contracts. For sUSDe and LSTs like wstETH, this process is relatively straightforward, whereas, for LRTs, it often involves more complex mechanisms to account for additional layers of staking and reward distribution.

For instance, Aave derives rsETH’s exchange rate through its LRTOracle, which calculates asset value as staked assets in ETH / rsETH supply. The system queries getTotalAssetDeposits() to retrieve staked amounts from the Deposit Pool, Node Delegator Contracts, and EigenLayer, then multiplies them by their respective, centrally derived exchange rates (for LSTs such as wstETH and ETHx) or 1 (for native ETH). As such, the system fully relies on Kelp, the asset issuer, to derive the exchange rate component through a structured and intricate process. During an adverse scenario such as a slashing event, this system would be required to algorithmically report the associated exchange rate decrease, regardless of network congestion or the occurrence of black swan events.

Expanding on this, rsETH enables minting on L2s such as Arbitrum, utilizing the internally derived exchange rate to facilitate the process. To ensure accurate cross-chain pricing, the system leverages interoperability providers like LayerZero, chosen by the asset issuer, to securely and efficiently transmit the rsETH/ETH exchange rate across networks. Aave will then ingest this exchange rate to accurately price the asset within its ecosystem.

Decentralization Concerns

As @BGDLabs has noted, the centralization inherent in these processes for deriving the exchange rate—driven by the asset issuer through EOA or low-quorum multi-sig access control—necessitates external risk mechanisms like CAPO, which mitigate manipulation risks by capping the maximum per-second and annual growth of an asset’s exchange rate. This is functionally similar to the aforementioned on-chain constraints inherent within this risk oracle. Given the previously mentioned considerations regarding liveness and technical risk—and the fact that the system is mathematically designed to function without strict dependencies on sharp movements—the quality of the provided rates is governed by Chaos, while verification and validation are embedded within smart contracts developed by BGD. Ultimately, pricing is determined by the BGD contract itself.

In this context, further decentralization wrappers do not improve the quality of the solution. While Edge is set to transition to a decentralized model in the coming weeks, our commitment to transparency has been clear from the outset. Decentralization, in this sense, is upheld through governance-approved bounds and contract-enshrined checks, preventing any single provider from unilaterally dictating parameters, akin to the CAPO implementation. In contrast, price oracles rely on consensus to mitigate the risk of front-running. Functionally, multiple nodes verifying a signature offer no advantage over on-chain validation by the BGD contract, as both ensure the same level of security and reliability. Ultimately, it is the economic constraints and risk methodology that serve as the key deterrents against adverse outcomes.

ChaosLabs · February 16, 2025, 3:20pm

We have now escalated this proposal to ARFC snapshot, with the options mentioned by @BGDLabs:

Adoption of the Principal Token Risk Oracle in its entirety
The Exponential Lower Bound for PT pricing, as proposed by @LlamaRisk, with dynamic risk parameterization for Liquidation Thresholds and Liquidation Bonus through AGRS, and a LTV0 “kill-switch”
No PT Listing on Aave

Voting will commence in 24 hours, within the following timeframe:

Start
Feb 17, 2025 · 2:54 PM UTC

End
Feb 20, 2025 · 2:54 PM UTC

TokenLogic · February 16, 2025, 8:05pm

Hi @ChaosLabs

Aave has a long standing proven history of only using Chainlink to provide oracles and from what we understand, as of tomorrow (17th Feb) Chainlink will have already deployed a Chaos Labs methodology DON oracle that is more easily integrated into SVR. Given the Edge Risk oracle is relatively less compatible with SVR, the Chainlink implementation appears the more optimal technical solution.

Given the Aave Protocol only uses Chainlink and this features strongly in the branding of both Chainlink and Aave as bedrocks of DeFi, we want to see this tradition upheld and for it to be extended to include derivative and base asset oracles alike.

We prefer a Chainlink oracle that is a lot more SVR compatible relative to the voting options currently presented.

Would it be possible to vote on a methodology and provider of the oracle separately ?

EzR3aL · February 16, 2025, 8:27pm

I agree with Tokenlogic and would like to see Option 4: Chaos methodology+ Chainlink DON

RaoulSchipper-CLL · February 16, 2025, 8:46pm

Hi @chaoslabs. Based on the discussion in this thread I want to formally request an extra fourth option be added to the ARFC. We believe the vote for Pendle PT tokens and the pricing methodology should be separated from a major infrastructure decision about how the offchain data is delivered onchain.

We want the following option to be available for DAO participants:

“Pendle PT pricing methodology as proposed by Chaos Labs provided through a Chainlink DON with accompanying risk parameters separately managed by Aave service providers.”

We believe this provides all relevant options to the Aave DAO while not bundling key decisions together unnecessarily. This option maintains the decentralized DON infrastructure Aave has relied upon for half a decade, while having the Volatility-Structured Pricing Mechanism, and can be made SVR compatible whenever Aave wants to recapture liquidation MEV.

ChaosLabs · February 16, 2025, 11:13pm

Aave’s Risk Infrastructure: Clarifications, Facts, and the Path Forward

First and foremost, we appreciate the engagement and feedback from all participants in this discussion. For years, our singular focus within Aave has been to deliver the most robust and forward-thinking risk solutions—grounded in research, driven by technology, and shaped by innovation. Our goal is to serve the DAO’s best interests, ensuring that every solution aligns with Aave’s established best practices and long-term security. It is important to ensure that the conversation remains grounded in accurate information and a clear understanding of Aave’s operational framework. Certain perspectives expressed in this thread appear to reflect misconceptions or misunderstandings about Aave’s oracle and data architecture, which merit further clarification. In the spirit of constructive dialogue, we will systematically address key points, reaffirm the technical facts, and provide clarity on the rationale behind the Edge PT Risk Oracle’s design and implementation.

Economic Constraints Are the Real Security Mechanism, Not Chainlink’s Wrappers

Much like the Correlated-Asset Price Oracle (CAPO) enforces per-second and annual growth caps to mitigate manipulation risks inherent in centralized native exchange rate derivation, the onchain fallbacks and constraints within the PT oracle serve a similar function, ensuring that economic constraints—NOT additional decentralization layers—are the primary security mechanism.

Chainlink’s DON does not address the core risk (essentially acting as a decentralized “wrapper” over Edge’s rate derivation), so its addition would offer no meaningful security benefits. This is precisely analogous to how Aave directly relies on native LST and LRT smart contracts for exchange rate calculations on Ethereum rather than introducing a Chainlink Oracle feed as an intermediary. During an adverse scenario such as a slashing event, the native system would be required to algorithmically report the associated exchange rate decrease, regardless of network congestion or the occurrence of black swan events.

Aave does not rely on Chainlink oracles for LST/LRT exchange rate calculations on Ethereum or for natively derived exchange rates within their respective chains. This is in line with the design and Architecture of the Edge Risk PT Oracle, which was backed by asset issuer Pendle and reviewed by BGD.

Chainlink is Not the Sole Data Provider to Aave

Despite repeated assertions, Chainlink is not the exclusive provider of rate data to Aave—this is misleading, not reality. Aave has always worked with asset issuers and their preferred technical stacks to determine the most appropriate methodology for ingesting exchange rates, particularly for LSTs and LRTs. Instead, rates are determined on-chain via methodologies developed by asset issuers themselves, as seen in the case of rsETH and other assets. For a more detailed breakdown, refer to the rsETH example previously provided.

This precedent is well established, and ensuring flexibility in Oracle infrastructure is critical to the security and long-term resilience of onboarded assets.

Edge PT Risk Oracle Does Not Price PT Assets—BGD’s Contracts Do

A fundamental misconception in this discussion is the role of the Edge PT Risk Oracle. To be clear:

The Risk Oracle does not compute or dictate the price of PT assets.

Wrapping Edge Rates with the Chainlink DON Adds Complexity Without Benefit

The notion that piping Edge rates through a Chainlink DON improves the solution is fundamentally flawed and serves only to complicate implementation while providing zero additional security benefits. Moreover, the Aave DAO has already demonstrated its trust in Edge Risk Oracles, relying on them for critical functions in the ecosystem today.

All updates are mathematically validated within the smart contract itself, ensuring accuracy and security without requiring Chainlink consensus. The system’s security and stability are already upheld through deterministic onchain enforcement, economic constraints, and governance-approved safeguards—this is nothing new to Aave for assets with exchange rates.
The system is designed to update infrequently, averaging rates over time instead of reacting to short-term volatility. This approach ensures a stable and controlled mechanism, reducing reliance on frequent oracle updates.
Even without an update, the system naturally transitions into a PT price that converges to 1 at maturity, maintaining stability and ensuring it remains mathematically unlikely to accrue bad debt due to its intricate built-in risk management framework.
Because the system does not depend on real-time updates and is designed to operate smoothly without immediate rate adjustments, liveness risks are inherently eliminated.
The system enforces strict onchain constraints, including a maxRate limit and LT/LB update constraints (as per AGRS today), preventing excessive rate deviations and reinforcing overall resilience.

In other words, the additional Chainlink wrapper is unnecessary bloat and complexity, rather than for any technical or risk-management improvement.

SVR Is Not Blocked by the Risk Oracle

BGD has explicitly clarified that SVR is not blocked by Edge or any Risk Oracle implementation:

SVR can be adapted to a generalized framework where exchange rates, whether from Risk Oracles or other sources, remain compatible with OEV capture. Given the widespread reliance on exchange rates not derived through the Chainlink DON, this applies not just to Risk Oracles but to any Aave Oracle implementation.

SVR Has Not Passed Governance

• SVR has not advanced beyond the ARFC stage.

• No governance vote has taken place.

• There are unresolved concerns about its feasibility, revenue projections, and potential risk underestimations—all of which will be addressed once a formal proposal is submitted.

To present SVR as an immediate dependency or as a justification to block the PT Oracle is dishonest and misleading.

Shifting Concerns and the Need for a Clear Path Forward

Throughout this discussion, the concerns raised around Edge have continued to evolve, often shifting focus as previous objections were systematically addressed:

• Methodology Concerns → Initial critiques sought to challenge the Edge methodology, but in doing so, revealed a misunderstanding of how Aave’s rate calculations function.

• Liveness Risk → Once it was demonstrated that Edge operates a highly smoothed and discretized algorithm on a 24-hour heartbeat with multiple fallback layers, concerns over liveness were effectively put to rest.

• Decentralization → The conversation then moved to decentralization, despite the fact that Risk Oracles inherently differ from Price Oracles and additional network layers do not enhance security but rather add complexity.

• SVR as a New Consideration → With the previous concerns addressed, the discussion has now pivoted to whether Edge would impact SVR, a proposal that has yet to pass governance and remains in its early design stages, yet seemingly has the ability to support any feed external to Chainlink.

This pattern of shifting concerns suggests one of two possibilities: either the solution is not fully understood— in which case, we trust that the multiple explanations provided have offered the necessary clarity— or there are other motivations at play. Regardless, the focus should remain on evaluating solutions based on their technical merit and alignment with Aave’s best interests, rather than introducing unnecessary obstacles.

Chaos Labs Operates in Aave’s Best Interests

Chaos Labs has served the Aave DAO with integrity for nearly three years, consistently prioritizing its long-term success over any external interests.

• The Edge PT Risk Oracle was developed after months of research in collaboration with Pendle, the asset issuer, to advance Aave’s capabilities.

• Principal Tokens (PTs) introduce a fundamentally new asset class, requiring a novel risk management solutions—not retrofitted price oracle infrastructure.

• Chaos Labs leads Aave risk and takes full accountability. We will not cede control of risk solutions to third-party intermediaries, especially when it serves no technical purpose.

Conclusion: Aave’s Risk Strategy Must Be Driven by Excellence, Independence, and DAO-Centric Decision Making

The Edge PT Risk Oracle was developed with the DAO’s best interests at heart, leveraging months of rigorous research, technical refinement, and alignment with Aave’s risk-first principles.

As outlined above, the Edge PT Risk Oracle does not introduce any new practices or novel data dependencies. It follows similar risk frameworks and mechanisms that already exist today within Aave, leveraging well-established on-chain exchange rate methodologies. The only proposed deviation from Aave’s existing structure is the introduction of the Chainlink DON—a hybrid solution that does not exist today for natively deriving exchange rates and adds unnecessary complexity without providing any technical merit or security benefits.

As Aave’s risk managers, Chaos Labs holds the greatest accountability for the outcomes of any risk decision. The DAO will turn to Chaos for answers, for revisions, and for accountability. It is only logical that those responsible for risk outcomes should also be responsible for proposing the best path forward.

• Security & Risk Excellence – Risk solutions should be tailored to Aave’s specific needs, leveraging onchain security mechanisms and economic safeguards rather than unnecessary complexity. The Edge Risk Oracle achieves this without reliance on third-party dependencies.

• Technical & Governance Integrity – The proposal to add a Chainlink wrapper offers no technical improvements, only additional friction and reliance on an external entity. Delegates should evaluate solutions based on merit, efficiency, and alignment with Aave’s existing risk frameworks.

• Scalability & Innovation – Principal Tokens represent a new asset class, requiring a bespoke risk framework rather than retrofitted methodologies. The Edge PT Risk Oracle is designed specifically for Aave’s evolving needs, ensuring long-term flexibility and resilience.

Chaos Labs remains committed to our mission of continuing to drive risk innovation for the DAO.

stani · February 17, 2025, 10:34am

First I would like to say that its great to see a very detailed proposal and research explaining the problem solving regarding the Pendle PTs pricing and I also like the thinking around improvements that can be made compared to the other weaker lending protocols’ implementations.

That being said, my fundamental issue with this proposal is the same as highlighted by @LlamaRisk about separating the critical pricing infrastructure providers from risk service functions.

Infrastructure pricing is a very critical operations within the DAO and it was decided since the inception of the DAO and Aave Protocol V1 to use ChainLink, mainly due to the resiliency ChainLink has been able to provide in asset pricing infrastructure. Major part of the pricing infrastructure is relied actually offchain and is related to areas such as DevOps, business continuity etc. ChainLink has been able to set a very high bar in operations of this particular focus area and any new provider would need to provide more evidence on how these offchain parts of the system work to prove resiliency.

Currently it is too risky to introduce a new provider without track record on critical pricing infrastructure operations and secondly, these functions should be separate between pricing infra and risk functions. There for I am voting NO on this proposal.

I am open to a setup where Chaos Labs works with existing pricing infra provider, adding more guardrails into the system and would like to see an updated proposal set forward that reflects the concerns.

@ChaosLabs given the density of the discussion recently its pre-mature to escalate the proposal into a snapshot in the middle of the on-going discussions, especially as a Temp Check was not provided for the proposal while it touches a very critical piece of software of the Aave system, the pricing infrastructure. The proposal needs more time for discussions.

Disclaimer: I don’t hold any LINK or have any ties with ChainLink. I did participate in the Chaos Labs seed round in 2021.

Kene_StableLab · February 17, 2025, 1:47pm

We appreciate the research that has assessed how Aave can price Pendulum Tokens effectively.

We would be more comfortable if Chaos Labs worked with Chainlink to implement this solution. This would ensure that the Risk Framework is covered by Chaos Labs while the Oracle aspects would be covered by Chainlink and closely vetted by BGD Labs.

sid_areta · February 17, 2025, 3:30pm

The amount of depth in this proposal and the responses is fantastic. Having delved into it (as much as possible, given the depth), it is clear that there is still significant disagreement on how PTs should be priced, which is fair, given the technical complexity.

There has been no discussion about the “timing” of this proposal and the decision to go to Snapshot this quickly. If we’re spending such significant time on understanding how to price these tokens, it is even more paramount to understand the benefit of supporting PTs from a revenue and competition perspective. Once we understand this, we can then tackle the question of pricing them.

Regarding some of the analysis provided by Chaos Labs, we think it would be helpful to simplify it and make all options easily comparable. Transparently, it is not easy to understand the benefits and drawbacks of the proposed options from a risk/reward perspective, and we think it’s premature to rush into a vote on this with so much still up in the air. We’d also appreciate an unbiased view on the Edge Risk Oracle vs. Chainlink DON methodology; there should be a crystal clear reason to go against the established process of separating the risk providers from pricing infrastructure, and while we would be open to this if it made sense, we’re currently not sure why this is critical.

We’re happy for there to be a vote to add PT tokens (backed by the appropriate justifications) to not delay the process any further.

midpeach · February 17, 2025, 5:55pm

Forgive the new account: I’m a longtime participant and ACI-delegated $AAVE holder. Allow context for my view before sharing it.

Broader Market Context

This proposal is indicative of broader market pressures. VCs, pressured by underperformance vs BTC and ending fund lifecycles, are pushing portfolio projects (e.g., Redstone, Plume) to accelerate token launches for liquidity events. These VCs must return funds to their LPs to secure modest ROI against perceived cycle tops. This cycle has been unique with winds shifting toward an anti-VC “meta” (low-FDV, accessible price discovery), but bloated valuations from 2021 linger.

Introduce a Little Chaos

Chaos Labs’ $55M Series A in August last year was led by Haun Ventures’ flagship $1BN (oversized) fund. Haun has scored little this past cycle. LPs are likely requesting withdrawals. Haun, as round leads, are applying significant pressure onto Chaos Labs to launch $EDGE / Chaos Chain. By integrating their oracle into Aave, Edge gains significant social proof, accelerating Chaos Labs sales teams integrating risk oracles (e.g GMX). Wider TVS for Edge increases token valuation, facilitating Haun (who also invested in Plume - another rushed TGE) to exit. Smaller fundraises avoid this issue. Excluding Chainlink’s DON option in the vote reinforces this strategy (Chaos Labs chose growth by unseating incumbents). It highlights a broader Service Provider issue: their business does not scale, mirroring Gauntlet’s (raised at $1B) upcoming Aera token.

ACI’s investment into Chaos Labs likely shields them from accountability - another SP acting in a juvenile and forceful manner would be off-boarded. Their silence is notable.

This ARFC

Chaos Labs fail as a partner risk steward by bulldozing a proposal rife with complexity, sideswiping stakeholder concerns. BGD and LlamaRisk fail to simply inform the DAO of the issues. Chaos’ rushed process bypasses established due diligence processes, and results in Chaos Labs prioritising Haun liquidity over Aave’s stability. This aggression is beneath Chaos Labs, and they must be reminded who is paying their Service Provider fee. This particular process exemplifies Service Providers failing their duty to stakeholders.

Conclusion

It cannot be reiterated enough: while Chaos Labs’ contributions are highly valued. But, this proposal prioritises VC exits (via $EDGE’s success) over the Service Provider contract role. The DAO must reject misaligned incentives: users pay for Service Providers, not VCs (who do not use protocols). Aave’s reputation hinges on institutional-grade safeguards, not short-term gambits. Chaos Labs should refocus on risk, leaving growth to mandated teams. Their return to “Aave first” is critical to restoring DAO confidence in their capacity to balance priorities.

ChaosLabs · February 18, 2025, 8:03pm

Given the complex nature of this proposal, it has become evident through this thread that certain delegates may not fully grasp the solution, the opportunity, or the risks involved in onboarding PT markets. To ensure further deliberation, we have decided to cancel the snapshot. In the meantime, we will work closely with @BGDLabs and other DAO SPs to refine the solution in alignment with the feedback received.

Topic		Replies	Views
[ARFC] Onboard Pendle PT tokens to Aave V3 Core Instance Governance	2	321	February 8, 2025
Chaos Labs Risk Oracles Governance	4	1127	May 13, 2024
[TEMP CHECK] Onboard Pendle PT tokens to Aave V3 Core Instance Governance	11	1107	January 19, 2025
Proposal: Dynamic Risk Parameters Governance	23	8559	August 13, 2021
[ARC] - Risk Parameter Updates for Aave v2 Ethereum - LT and LTV (2022.12.01) Governance	12	3467	April 2, 2024

[ARFC] Pendle Principal Token Risk Oracle

Summary

Motivation

LinearDiscountOracle

Underpricing PTs in Expectation

Overpricing PTs

Market TWAP Feed

AMM TWAP Technical Risk

PT Risk Oracle Solution

PT Token Dynamic Risk Profile

Optimal PT Pricing Methodology

PT Pricing Strategy

Secondary Pricing Component

Tertiary Pricing Component (Underlying)

Conditionally Setting LTV to 0 When Reaching Minimum Price (Killswitch)

Dynamic Liquidation Bonus

Interplay with Underlying Asset LB

Dynamic Liquidation Threshold

Additional Considerations

PT Collateral Debt Assets

Restricting PT Borrowing

Pendle Market Parameterization

Underlying Asset Integration

PT Underlying as Debt Asset

Benefits of Utilizing Chaos’ Risk Oracle

Disclaimer

Copyright

Manipulation Resistance

Practical Implementation

Proposed Aggregate Oracle Implementation

Summary

Detailed Analysis

1. Linear Lower Bound (LLB) - least capital efficient

2. Edge Oracle (EO) - Max efficiency but complex and offchain components

3. Exponential Lower Bound (ELB) - Balanced middle ground

Modeling different solutions

Edge Oracle (EO)

Linear Lower Bound (LLB)

Exponential Lower Bound (ELB)

Combined Comparison

Over-pricing vs. Under-Pricing

PT-weETH

PT-ENA

Problematic Cases

Other considerations

Circuit Breaker

Disclaimer

Conclusion

Technical Risks

Alternative Aave Oracle Implementations

Decentralization Concerns

Aave’s Risk Infrastructure: Clarifications, Facts, and the Path Forward

Economic Constraints Are the Real Security Mechanism, Not Chainlink’s Wrappers

Chainlink is Not the Sole Data Provider to Aave

Edge PT Risk Oracle Does Not Price PT Assets—BGD’s Contracts Do

Wrapping Edge Rates with the Chainlink DON Adds Complexity Without Benefit

SVR Is Not Blocked by the Risk Oracle

SVR Has Not Passed Governance

Shifting Concerns and the Need for a Clear Path Forward

Chaos Labs Operates in Aave’s Best Interests

Conclusion: Aave’s Risk Strategy Must Be Driven by Excellence, Independence, and DAO-Centric Decision Making

Broader Market Context

Introduce a Little Chaos

This ARFC

Conclusion

Related topics