[ARFC] Onboard Pendle PT tokens to Aave V3 Core Instance

[ARFC] Onboard Pendle PT tokens to Aave V3 Core Instance

Author: ACI

Date: 2025-01-07

Summary

This ARFC proposes to onboard Pendle PT tokens to Aave V3 Core Instance.

Motivation

Pendle allows users to split yield bearing tokens into principal (PT) and yield (YT) components. This opens the door to trading yield for the growing number of yield bearing tokens, and gives users additional options for yield farming strategies. A notable feature of the PT tokens is that at the maturity date, the value of the PT equals the value of the underlying asset and can be redeemed for the underlying. This means PT tokens, which can be bought at a discount within Pendle pools, represent the fixed rate part of a Pendle asset pair.

Pendle has seen extremely high growth this year, with current TVL of circa $4.5 billion. Along with this growth has come the desire for yield traders to borrow against their Pendle PT tokens. This represents a multi-billion dollar growth opportunity for Aave, without a large increase in risk if PT tokens are onboarded for already listed assets such as sUSDe.

We propose listing an initial PT token as a test use case to see user demand and work through the full integration of a PT token:

Contract: PT-sUSDE-31JUL2025: PT Ethena sUSDE 31JUL2025 (PT-sUSDE-31JUL2025) Tok

In future we propose listing sUSDe and USDe PT tokens for new maturities as required.

Specification

Contract: PT-sUSDE-31JUL2025: PT Ethena sUSDE 31JUL2025 (PT-sUSDE-31JUL2025) Tok

Risk Parameters

Risk parameters will be provided by Risk Service Providers in the ARFC and will be updated accordingly.

Useful Links

[TEMP CHECK] Onboard Pendle PT tokens to Aave V3 Core Instance

[TEMP CHECK Snapshot] Onboard Pendle PT tokens to Aave V3 Core Instance

Disclaimer

ACI is not directly affiliated with Pendle and did not receive compensation for creation this proposal. Some ACI employees may hold Pendle tokens.

Next Steps

  1. Publish ARFC to gather community and Service Providers feedback.
  2. Escalate the proposal to ARFC snapshot stage if feedback is positive.
  3. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal.

Copyright

Copyright and related rights waived under CCO

2 Likes

Summary

Our risk assessment concludes that Pendle PT tokens can be safely onboarded to Aave with appropriate risk parameters. While PT tokens represent a significant opportunity for Aave and its user base, several challenges arise when pricing them and determining safe lending parameters. We evaluated two pricing methods - using onchain data from Pendle AMM and adapting the base asset oracle - and recommend the linearly increasing lower bound method, which requires developing a pricing adapter.

The protocol demonstrates robust security with multiple audits and a proven incident response track record. While the $250k Immunefi bounty could be increased given the $5b TVL, protocol mutability is appropriately limited to pause/caps controls - a feature that proved valuable during the September 2024 Penpie incident, where swift action protected ~$105M in assets. Each PT’s single liquidity source makes yield parameter management critical, though limit order functionality helps maintain base asset redemption.

The operational complexity of managing expiring tokens suggests exploring auto-rolling vault solutions to improve user experience. This implementation would need thorough technical and risk reviews by service providers.

For PT-sUSDe-29MAY2025 and other Ethena-related derivatives, we recommend delaying integration until ongoing discussions about Ethena exposure and pricing are resolved. Integration may also be more opportune after the deployment of Umbrella.

Read full Collateral Risk Assessment

1. Asset Fundamental Characteristics

1.1 Asset

Pendle operates as a yield-tokenization protocol that splits yield-bearing assets into two discrete components: Principal Tokens (PT) and Yield Tokens (YT). This mechanism parallels traditional fixed-income strip bonds, separating coupon payments from principal repayment. The protocol architecture requires yield-bearing assets to be initially wrapped as Standardized Yield (SY) tokens to ensure AMM compatibility before PT/YT tokenization.

The protocol enables several distinct use cases, each with specific risk considerations:

  • Fixed-yield asset creation (natively absent from DeFi)
  • Directional exposure to yield movements (both positive and negative)
  • Point/incentive reward speculation
  • Yield enhancement through AMM liquidity provision

1.2 Architecture

Yield-tokenization

When an underlying asset splits into PT and YT tokens, the PT token price equals the base asset price minus the expected yield until maturity. In contrast, the YT token price equals the expected yield until maturity. Over time, PT price increases gradually to match the base asset price at maturity, while YT price decreases slowly to $0 at maturity. YT holders profit when the actual yield exceeds the implied yield (determined by current PT and YT market prices) at purchase and lose when the actual yield is lower. This enables yield speculation on assets like wstETH and sUSDe. Conversely, buying and holding PTs functions as holding fixed-yield tokens.

Pendle’s invariant is as follows:
image

Below is a fictional example of wstETH tokenization with a 4% constant yield (January-December):

Jan 1st Jun 1st Dec 31st
wstETH price 1.1 ETH 1.122 ETH 1.144 ETH
PT price 0.96 ETH 0.98 ETH 1 ETH
YT price 0.04 ETH 0.02 ETH 0 ETH
Generated yield 0 ETH 0.02 ETH 0.04 ETH

Pendle Pool AMM

Through its AMM implementation, Pendle utilizes a single liquidity source for PT/YT tokens. After evaluating various AMM designs for yield-tokenization, Pendle adopted Notional’s AMM for its capital efficiency. The AMM employs two key parameters:

  1. rateAnchor: Determines the equilibrium point for optimal capital efficiency. In Pendle’s implementation, this parameter is time-dependent and should align with the underlying asset’s expected yield at maturity.
  2. rateScalar: Controls the liquidity range and should correspond to the underlying asset’s expected yield bounds.

The Notional AMM defines the asset price $p_t(asset)$ relative to the principal price $p_t(principal)$ at time $t$ through:

image

Where:

  • $rateAnchor(t)$ represents the optimal trading price at time $t$, matching accumulated yield from inception
  • $rateScalar(t)$ is derived from the fixed $scalarRoot$ parameter:

image

The AMM’s logit curve exhibits extreme slopes at the liquidity range boundaries, resulting in infinite price impacts at the edges. Pendle configures $scalarRoot$ to map the expected minimum and maximum asset yields to the 0.1-0.9 liquidity range to address this. The exact math needed to estimate the AMM parameters for a given underlying asset can be found in this research paper on the Pendle AMM design.

1.3 Tokenomics

Pendle tokenomics is built around its native $PENDLE token, which functions as the protocol’s core utility asset. A vote-escrowed model, vePENDLE, offers participants enhanced voting power while unlocking premium benefits such as amplified yield opportunities and preferential fee structures.


Source: Pendle documentation, January 8th, 2025

A milestone in Pendle’s token distribution timeline was reached in September 2024, marking the complete vesting of all team and investor allocations. The protocol maintains a calibrated emission schedule, distributing 216,076 tokens weekly as of September 2024. Following a model of a 1.1% weekly decrease until April 2026, the protocol will transition to a terminal inflation rate of 2% annually.

The following addresses are excluded from circulating supply calculations:

PENDLE emissions incentivize liquidity providers in Pendle pools, guaranteeing that PT and YT tokens are always tradable against their underlying tokens. A 3% fee is taken from the yield accrued by YT tokens, 100% of which is directed to vePENDLE holders. In addition, 80% of the swap fee collected by voted pools is distributed proportionately to vePENDLE holders. The protocol also implements a multiplier system that can boost LP rewards by up to 2.5x, with the exact enhancement factor determined by the vePENDLE holders relative to their share in the liquidity pool.

1.3.1 Token Holder Concentration

N/A (asset dependant)

2. Market Risk

2.1 Liquidity

2.1.1 Liquidity Venue Concentration

Each PT token and maturity date combination has its own liquidity pool within Pendle. Pendle pools are ephemeral in that they only last from the beginning of the tokenization period up to their maturity date. Here are the 3 active tokenization periods for sUSDe and their corresponding liquidity pools:

2.1.2 DEX LP Concentration


Source: Etherscan, January 8th, 2025

Here are the top-5 liquidity providers in the PT-sUSDe May 29, 2025 liquidity pool:

  1. EOA with 28.94% of the liquidity
  2. SafeProxy contract with 10.25% of the liquidity
  3. EOA with 7.32% of the liquidity
  4. EOA with 5.70% of the liquidity
  5. EOA with 4.89% of the liquidity

Although the biggest liquidity provider provides 28.94% of the liquidity, there are numerous medium to small liquidity providers, which reduces liquidity concentration risks.

2.2 Volatility

PT token prices are correlated to their base asset. The constant ability to trade PT and YT tokens for their underlying in Pendle pools offers profitable arbitrage opportunities that maintain this correlation through time. In addition, depending on changes in expected yield for the underlying, the market will adjust the PT token price to reflect the change in implied expected yield. For instance, a decrease in the expected yield will be reflected in a reduction in the PT token price and an increase in the YT token price, and conversely, if the yield is expected to decrease.

2.3 Exchanges

No CEX currently supports PT tokens, nor is any expected to support them in the future due to the ephemeral nature of each tokenization period.

2.4 Growth

Pendle launched in June 2021 and grew to reach $230m TVL by the end of 2023. The protocol then experienced significant growth, reaching a peak of $6.5b TVL in June 2024. Since then, Pendle’s TVL has strongly correlated with overall market sentiment.


Source: DefiLlama.com, January 8th, 2025

Currently, sUSDe tokenization periods represent 50.15% of the protocol’s TVL, followed by WBTC at 16.79% and USD0++ at 11.02%. The high proportion of sUSDe can be attributed to its high and volatile yield from Ethena, which increases demand for Pendle’s yield-tokenization services.


Source: DefiLlama.com, January 8th, 2025

3. Technological Risk

3.1 Smart Contract Risk

Yield-tokenization of an underlying yield-generating asset brings an additional layer of smart contract risks on top of the existing ones. For instance, in the case of wstETH, Pendle would be the second layer of smart contracts. Pendle has been audited by 2 auditing firms, which overall outlined professional security practices from the Pendle engineering team. ChainSecurity (August 15, 2024) found 2 medium security findings and 9 low-security findings, with no critical or high-security findings. Spearbit (July 26, 2024) found 1 high-security, 2 medium-security, and 5 low-security findings, with no critical security findings.

Several established Code4Arena auditors have audited the protocol. All audit reports are available on Github.

3.2 Bug Bounty Program and Incident Response

A $250k bug bounty is also available on Immunefi, which, given the $5b TVL of the protocol, could benefit from increasing. On September 4, 2024, the Pendle team detected a suspicious contract funded via TornadoCash interacting with Pendle. The breach occurred in Penpie, an external protocol built on top of Pendle. Acting swiftly, the team paused all contracts and safeguarded ~$105M from further loss. A detailed post-mortem highlights their exemplary security practices and incident response.

3.3 Price Feed Risk

We analyzed two approaches for pricing PT tokens in Aave: a conservative method using the discounted base asset price and a dynamic method using Pendle pools’ TWAP oracle.

Option 1 - Linearly Increasing Lower Bound Method

At the tokenization start, the market-estimated yield is reflected in two ways:

  • PT tokens trade at a discount to the base asset price
  • YT tokens are priced at this discount

As time progresses, the PT token price asymptotically approaches the base asset price while the YT price approaches zero. Given the positive yield assumption on yield-bearing assets, the PT price is guaranteed to increase over time and ultimately equal or exceed its initial price.

Since Pendle AMM is the only liquidity source for a given asset/maturity date, an Aave liquidator has two options:

  1. Sell PT tokens pre-maturity for base asset (with potential slippage but flash loan capability)
  2. Hold until maturity for guaranteed base asset redemption (no flash loans, opportunity cost)

Since scenario 2 is likely undesirable for liquidators due to the opportunity cost of capital lockup, we can implement pricing constraints to make scenario 1 viable. The Pendle AMM concentrates liquidity within an expected yield range, allowing us to calculate a safe lower-bound price.

Mathematically:

  • Let $p_t(PT)$ be PT price at time $t$ in base asset terms
  • Let $maxYield$ be the maximum expected yield at maturity
  • Then: $p_t(PT) \geq 1 - maxYield$

Red is the PT token price with a 4% expected yield upon maturity, and Black is the lower bound using an expected maximum yield of 8%

We can improve this static bound with a dynamic approach that increases linearly over time:

image

Red is the PT token price with a 4% expected yield upon maturity, Black is linearly increasing lower bound at $p=0.92$ using an expected maximum yield of 8%

To account for increased volatility near maturity, we can add a 5% safety margin:

image

Red is the PT token price with a 4% expected yield upon maturity, and Blue is linearly increasing lower bound using an expected maximum yield of 8% and 5% margin of safety applied to the maximum expected yield upon maturity

Example using wstETH (max yield 8%, realized 4%):

Jan 1st Jun 1st Dec 31st
wstETH price 1.1 ETH 1.122 ETH 1.144 ETH
PT price 0.96 ETH 0.98 ETH 1 ETH
YT price 0.04 ETH 0.02 ETH 0 ETH
Generated yield 0 ETH 0.02 ETH 0.04 ETH
Constant bound 0.92 ETH 0.92 ETH 0.92 ETH
Linear bound 0.92 ETH 0.96 ETH 1 ETH
Safe linear bound 0.92 ETH 0.958 ETH 0.996 ETH

This provides a conservative yet capital-efficient pricing method. The fixed lower bound offers maximum safety but reduced efficiency, while the linear bound optimizes efficiency but requires consideration of near-maturity volatility.

Option 2 - Pendle Pool TWAP Oracle

Pendle Pools provides an on-chain pricing mechanism for PT tokens through a built-in price oracle inspired by UniswapV3’s pool design. The system achieves capital efficiency by concentrating liquidity within ranges closer to expected trading prices. When users provide liquidity to Pendle pools, it is automatically distributed across a range corresponding to the expected minimum and maximum yield of the underlying asset at maturity. Pendle pools maintain a priceCumulative array that enables efficient on-chain computation of average prices up to 9 days prior, sufficient for providing outlier-resistant price feeds.

The cumulative price mechanism works as follows:

Let $p_i$ be the asset price at time $i$, and $log_{1.0001}(p)$ be the logarithm of price with base $1.0001$ (corresponding to 1 basis point spacing between ticks). The implementation accounts for varying tick durations, while we assume uniform tick duration for simplicity.

The priceCumulative value at time $t$ is:

image

The Time Weighted Average Price (TWAP) between times $t_1$ and $t_2$ can be computed efficiently on-chain:

image

As demonstrated in the UniswapV3 whitepaper, this TWAP calculation produces the geometric mean of prices over the interval.


UniswapV3 TWAP Oracle Design. Source: UniswapV3 blog, March 23, 2021

Aave could utilize this dynamic on-chain oracle for PT pricing to capture both time-based value appreciation and real-time market dynamics while maintaining high capital efficiency and ensuring trustless price discovery. However, this approach may expose borrowers to increased volatility during market turbulence or low liquidity conditions, requiring careful monitoring of pool depth.

While built-in TWAP oracles are typically not used as primary price sources for lending platforms due to manipulation risks, they are particularly suitable for PT tokens. Since Pendle pools are the exclusive liquidity source for these tokens, their built-in TWAP oracle provides the most direct and trustless price feed available. The mechanism is fully on-chain and transparent, with historical data readily available for the past 9 days. It is uniquely qualified as a reliable price source for PT tokens in Aave’s lending markets.

Comparison with other protocols

As a point of comparison, here is how other lending protocols are pricing PT tokens:

Method Safety mechanism
Moonwell Linearly increasing lower bound Hardcoded discount
ZeroLend Built-in TWAP Oracle Upper/Lower limit
SiloFinance Built-in TWAP Oracle None
Morpho Linearly increasing lower bound Hardcoded discount

Both Morpho and Moonwell are using the PendleSparkLinearDiscountOracle contract developed by Pendle, which implements a linearly increasing lower bound where the discount is hard coded.

3.4 Dependency Risk

Pendle pool parameters

Optimal parameter selection for Pendle pools is critical for maintaining capital efficiency. Efficiency deteriorates significantly at the liquidity curve edges, potentially preventing trading altogether. Incorrect ranges for minimal and maximum expected yield at maturity pose a direct risk by potentially blocking profitable liquidations in Aave.

Two critical mitigation strategies ensure continuous liquidation functionality:

  1. Pendle’s AMM limit order book enables trading beyond pool price ranges, crucially maintaining liquidation capability for Aave’s risk management
  2. The protocol can deploy new pools with optimized parameters, allowing liquidity migration from suboptimal pools. This solution relies on active protocol management by the Pendle team

Loss of principal from underlying

While underlying yields are typically positive, negative yields resulting in principal loss remain possible. These tail-end risks, already present in Aave’s base asset markets, can materialize through:

  • Smart contract vulnerabilities in Pendle, partially mitigated by external audits and a $250,000 bug bounty program
  • Smart contract vulnerabilities in underlying protocols (Lido, Ethena)
  • Oracle exploits, though the risk is limited due to the recommended PT pricing mechanism using Pendle pool parameters alongside existing Oracle infrastructure

Pendle values PT and YT tokens using the underlying protocol’s internal exchange rate. For sUSDe, a USDe depeg from USD wouldn’t affect protocol operations, as the sUSDe/USDe exchange rate remains stable - users would only realize dollar losses when converting redeemed USDe. However, for LSTs like wstETH, slashing events would affect the wstETH/ETH exchange rate, reducing both the PT token and YT token redemption value at maturity.

4. Counterparty Risk

4.1 Governance and Regulatory Risk

Governance

The Pendle governance is partly decentralized through vePENDLE, a vote-escrowed token. Through a dynamic locking mechanism, PENDLE token holders can commit their tokens for up to two years to receive vePENDLE, incorporating a decay function over time. This time-weighted voting power model creates an incentive structure, encouraging participants to actively manage their positions by extending their lock periods or increasing their positions to maintain influence. vePENDLE holders can vote to direct liquidity incentives to specific pools. This voting power is complemented by a revenue-sharing model that rewards active participation in protocol governance.

Source: vePENDLE dashboard, January 8th, 2025

A significant proportion of the circulating supply is being locked for vePENDLE rewards. Additionally, the average lock duration of over a year signals a long-term commitment from token holders.

Legal

The Pendle team retains significant control over the protocol, with no publicly disclosed plan for this to change. The assets to onboard, the tokenization periods, and the pool’s parameters are all decisions the development team makes in a centralized manner. The use of partly immutable contracts somewhat alleviates that issue.

While the Terms of Use do not explicitly identify the operating entity, an examination of the governing law provisions suggests that the entity managing https://www.pendle.finance/ and its associated applications is domiciled in the British Virgin Islands (BVI), as evidenced by the choice of BVI law as the governing jurisdiction. A noteworthy jurisdictional nuance emerges in the dispute resolution provisions, where Singapore is designated as the arbitration venue, creating an interesting divergence from the BVI governing law clause.

The structural similarities between Pendle’s PT tokens and traditional zero-coupon bonds necessitate a thorough legal analysis within the regulatory framework that can be attributed to Pendle’s operations. In this context, the Pendle team has procured a legal opinion from a Singapore law firm in 2023, addressing the regulatory status under two key pieces of legislation: the Securities and Futures Act and the Payment Services Act. The opinion provides valuable insights regarding the potential exemption status of the Pendle Earn interface from the Monetary Authority of Singapore (MAS) licensing requirements.

The legal analysis conclusively determines that PTs fall outside several regulated categories. Specifically, they do not meet the statutory definition of “securities”, cannot be classified as units in a “collective investment scheme”, fall outside the scope of “spot foreign exchange for leveraged foreign exchange trading,” and cannot be prescribed as “capital market products”. Moreover, the opinion presents compelling arguments against classifying PTs as derivatives contracts.

The professional determination that PTs do not constitute capital markets products under Singapore law provides a sound foundation for the current asset onboarding procedure. It is prudent to note that this conclusion remains valid until circumstances necessitate a fresh legal examination or regulatory changes warrant a reassessment.

4.2 Access Control Risk

The following contracts are deployed when a new tokenization period is created for an asset in Pendle:

The PendleGovernanceProxy contract, deployed behind a ERC1967Proxy contract, has two roles:

  • the guardian role is assigned to an EOA wallet.
  • the admin role is assigned to to a 2/4 Safe multisig.

The admin and the guardian can pause all listed contracts (including the PendleSY contracts) in a single transaction. Only the admin can upgrade the PendleGovernanceProxy contract.

4.2.1 Contract Modification Options

Two contract modifying functions are available:

  • pause() and unpause() in the PendleMarketV3 contract, accessible to the guardian and admin roles.
  • updateSupplyCap in the PendleSY contract, only accessible to the guardian and admin roles.

4.2.2 Timelock Duration and Function

No Timelock is currently present in the architecture, although this absence is mitigated by the almost immutable nature of the deployed contracts. The PendleGovernanceProxy contract can be upgraded immediately, and the trading of PT tokens can be paused instantly.

4.2.3 Multisig Threshold / Signer identity

The admin role, which can pause PT/YT/SY trading and upgrade the PendleGovernanceProxy contract, is assigned to a 2/4 Safe multisig with signers:

Note: This assessment follows the LLR-Aave Framework, a comprehensive methodology for asset onboarding and parameterization in Aave V3. This framework is continuously updated and available here.

Aave V3 Specific Parameters

While we do not recommend immediate onboarding of PT-sUSDe-29MAY2025, we use this asset as a starting point to present our thoughts on parameterizing PT tokens on Aave.

1. Supply/Borrow Caps

1. Supply/Borrow Caps

Liquidity Trend

PT tokens have a unique characteristic: their liquidity comes from a single source - the Pendle AMM. Each asset/maturity date pair has its own temporary pool during the tokenization period. Key observations about these pools:

  • Multiple tokenization periods operate simultaneously with different maturity dates
  • Pool liquidity typically starts near zero and increases monotonically over time
  • Liquidity provider diversity and retention are crucial factors

Consider the four existing tokenization periods for sUSDe on Pendle:

sUSDe with December 25th, 2024 maturity

sUSDe with February 26th, 2025 maturity

sUSDe with March 26th, 2025 maturity

sUSDe with May 28th, 2025 maturity

In this case, the growth in sUSDe TVL and expanding DeFi opportunities provide more capital for tokenization (macro trend), while liquidity providers gradually migrate between tokenization periods (micro trend). When analyzing TVL across different tokenization periods for a single asset (excluding macro trends), we typically observe relatively stable total liquidity over time. However, this liquidity migration pattern creates challenges for Aave delegates in setting appropriate supply/borrow caps. The positive aspect is that any conservatively set caps become progressively safer since liquidity increases.

Parameter Selection

The Pendle documentation outlines an approach for determining safe supply/borrow caps on PT tokens that align with traditional liquidity pool analysis. The methodology involves identifying the amount of PT tokens that can be sold into the pool for the base asset within a given price impact. For consistency with Aave’s existing framework, we consider twice the liquidity available within the liquidation bonus as the target price impact. This same approach can be applied to Pendle pools by simulating large swaps to measure price impact.

An important consideration is that while PT tokens are redeemable for their base asset 1:1 at maturity, this is purely from an accounting perspective. In practice, redemptions provide the underlying yield-bearing asset (sUSDe for PT-sUSDe) rather than the base asset (USDe for PT-sUSDe). This design choice reflects that sUSDe is the initially deposited asset, avoiding impractical redemption processes in underlying protocols (like Ethena’s 7-day unstaking delay).

The concentrated liquidity design of Pendle’s AMM creates distinct liquidity depth characteristics compared to traditional AMMs. PT tokens naturally converge to their underlying asset value at maturity, allowing the AMM to optimize liquidity distribution. While this design enables more efficient trading, it makes precise liquidity measurements at specific price impacts more nuanced, particularly near the transition points of the liquidity curve. This unique liquidity profile suggests a gradual approach - starting with conservative supply caps that could be increased as market liquidity grows, potentially followed by introducing specialized features like PT-sUSDe/USDe E-mode for efficient fixed-APY leveraged-looping strategies.

2. Auto-rolling PT vaults

2. Auto-rolling PT vaults

We recommend implementing auto-rolling PT vaults for improved user experience and governance efficiency. This would allow:

  • Users to interact with a single vault per yield-bearing asset
  • Automatic allocation across multiple maturity periods, weighted by time-to-maturity
  • More stable liquidity metrics for determining supply/borrow caps
  • Simplified management for delegates

While the technical implementation details need to be finalized and potential risks thoroughly assessed, auto-rolling PT vaults align with Aave’s commitment to user-friendly design while improving capital efficiency.

3. LTV/LT Thresholds

3. LTV/LT Thresholds

For PT tokens using the base price oracle method, we recommend matching their base asset’s LTV/LT ratios, including E-mode settings. This approach is justified since the PT token’s price oracle effectively uses the base asset’s oracle with a fixed yield discount.

For PT tokens using the onchain TWAP oracle, more conservative LTV/LT ratios are warranted. While this oracle design (inherited from UniswapV3) reliably reports TWAP prices, PT tokens typically have lower liquidity and higher price volatility than their base assets. Significant changes in DeFi yield opportunities for the underlying asset can cause PT prices to deviate from their theoretical valuations. As noted by Pendle, PT price volatility correlates with underlying yield volatility, which can be particularly impactful during market stress periods.

4. Other Parameters

4. Other Parameters

We don’t expect compelling use cases for PT borrowing beyond shorting the token. Since shorting the underlying or base asset offers better liquidity and more favorable parameters, we recommend turning off PT borrowing for now.

Price feed Recommendation

We recommend using the linearly increasing lower bound method with a 10% margin of safety at maturity.

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.

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

4 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Pendle PT (asset class) analysis

Summary

This is a technical analysis of all the Pendle PT asset-class smart contracts and main dependencies.

Disclosure: This is not an exhaustive security review of the asset like the ones done by the Pendle Team, but an analysis from an Aave technical service provider on different aspects we consider critical to review before a new type of listing. Consequently, like with any security review, this is not an absolute statement that the asset is flawless, only that, in our opinion, we don’t see significant problems with its integration with Aave, apart from different trust points.



Analysis

Pendle is a permissionless yield tokenization and trading protocol that allows splitting a yield-bearing token into two tokens: PT (Principal Token), which is the principal of the underlying yield-bearing token, and YT (Yield Token), which is the yield generated by the underlying yield-bearing token with different expiration dates.

The asset is based on a standard wrapper (ERC-5115) called SY (Standardized Yield) to separate the yield from the principal. This wrapper is an extension of ERC-20 with basic functionality for deposits, withdrawals, and transfers. Pendle uses SY as the main interface for minting PT and YT, and trading through Pendle’s AMM pools.

For the context of this analysis, our focus has been on the following aspects, critical for the correct and secure integration with Aave:

  • Mechanism to update the exchange rate of the SY for the underlying asset.
  • Access control (ownerships, admin roles) and nature of the entities involved.
  • Any miscellaneous aspect of the code we can consider important.
  • A recommendation of pricing strategy to be used in the integration of the asset <> Aave.


Criticality Description
CRITICAL It can compromise the system, leading to loss of funds if misused or exploited. e.g. proxy admin, default admin
HIGH It can control several parts of the system with some risk of losing funds. e.g., general owners that can set critical addresses.
MEDIUM It can cause system malfunctions and/or minor financial losses if misused or exploited. e.g., fee setter, fee recipient addresses
LOW It can cause system malfunctions but non-critical parts and or financial losses. e.g., updating descriptions or certain non-critical parameters.
Risk Description
GREEN :green_circle: The role is controlled via Timelock or Multisig wallet, which we assume is safely protected.
YELLOW :yellow_circle: The role is controlled via a Multisig or EOA, which could expose the system and users to some risk depending on the actions it can control.
RED :red_circle: The role is controlled via an EOA, representing risks for the system and users.


General points


  • FUNGIBILITY. PTs are zero-coupon bonds, fungible within the same maturity but not directly between distinct maturities. The Pendle’s AMM also provides a solution for swapping with other PTs of the same and different class and against other tokens.
  • Buying/selling mechanism. Users can mint PT by depositing a yield-bearing asset and redeeming it after maturity for the underlying. Also, it’s possible to buy and sell through Pendle’s AMM anytime.
    The Pools are composed of PT-SY, so swapping PT is straightforward. There’s also an auto-router for seamless swaps with any major asset.
  • Price mechanism. There is a built-in TWAP Oracle library. The PT oracle stores the cumulative logarithm of the interest rate implied by PT/asset pricing (called implied APY). From this, the geometric mean of Implied APY is calculated, which is used to derive the mean PT price.
  • Upgradeability. The contracts related to the creation of PY contracts and AMM market are non-upgradeable. The SY contracts are asset-specific, so some may be Transparent Proxy contracts. The pyYtLpOracle is a Transparent Proxy upgradeable by the governance multi-sig 2-of-4. Aave will not be exposed to the pyYtLpOracle, which can be classified as a peripheral contract that fetches cumulative implied rates from each PY market.
  • Security. Pendle V2 contracts have been audited by 8 auditors, with 3 of the top 10 renowned C4 auditors. The audits can be found in their GitHub repo here.

Contracts

The following is a non-exhaustive overview of the main smart contracts involved with Pendle Principal Tokens.


Pendle SY - Standardized Yield (SY)

The SY is an abstract contract that wraps and maintains a 1:1 ratio with any yield-bearing token. It implements the standard EIP-5115 interface, an extension of the ERC20 that includes deposit withdrawals and transfers, and provides the exchange rate of the ybToken and its underlying token. Each SY implementation is asset-specific, meaning the SY contract needs to manage deposits and withdrawals differently internally. For example, the management of deposits and withdrawals for the wstETH-SY differs from that of the aUSDC-SY.

Permission Owner functions Criticality Risk
*owner: Pendle’s Governance or Pendle’s Deployer pause, unpause HIGH :green_circle:

*owner may vary between SY deployer, Pendle’s deployer or Governance

  • Users can deposit and mint SY tokens using the deposit(tokenIn, amount) function. Any tokenIn from the getTokensIn() function can be deposited. For example, aUSDC-SY can be minted using either aUSDC or USDC, while wstETH-SY can be minted using native ETH, WETH, stETH, and wstETH.
  • Users can redeem valid tokens using the redeem(tokenOut, amount) function. Any tokenOut from the getTokensOut() function can be withdrawn. For example, aUSDC-SY shares can be redeemed for aUSDC or USDC.
  • Users can use the previewDeposit(tokenIn, amount) and previewRedeem(tokenOut, amount) to estimate their deposits and withdrawals based on their chosen tokens.
  • The exchangeRate() function returns the ratio between the yield-bearing token and its underlying asset. For example, wstETH-SY.getExchangeRate() returns the wstETH:stETH ratio.
  • Some SY implementations inherit the abstract SYBaseWithRewards contract, which allows the SY to distribute rewards to users, while the SYBase contract does not implement rewards.
  • For SY with rewards, users can check the rewards tokens by calling the getRewardTokens() function and claim them via the claimRewards() function.
  • The SY deployer is the contract’s owner and can pause and unpause the contract. In Pendle’s deployments repo, some SY contracts have their ownership transferred to Pendle’s governance right after the deployment, but this needs to be verified before listing new PTs.

PendleYieldContractFactory - PY Factory

The PendleYieldContractFactory is the contract that creates both the PT and YT contracts from valid SY contracts. It’s a permissionless contract where anyone can create PY contracts.

Permission Owner functions Criticality Risk
owner: Safe 2-of-4 setExpiryDivisor, setInterestFeeRate, setRewardFeeRate, setTreasury, pay. transferOwnership MEDIUM :green_circle:
  • PY contracts are created via the factory.createYieldContract(SY, expiry) function by passing a valid SY contract and expiration date.
  • The owner can call the setExpiryDivisor, setInterestFeeRate, setRewardFeeRate, and setTreasury functions to set the expiry divisor, interest and reward fees, and treasury address, respectively. The expiry divisor validates the expiry timestamp, and the interest and reward fees, and the treasury address are later used in the YT contract.

PendlePrincipalToken - PT

PT represents the principal value of the underlying yield-bearing asset. At maturity, the PT token can be redeemed at 1:1 for the underlying asset. It is an ERC20 contract with custom implementations from the Pendle team, such as built-in reentrancy protection. Every PT token is minted with a YT token, and PTs can only be minted by the YT contract and before its maturity.

Permission Owner functions Criticality Risk
correspondent YT contract mintByYT, burnByYT HIGH :green_circle:
  • The mint and burn are performed via the mintByYT(address, amount) and burnByYT(address, amount) functions, which have the onlyYT modifier. Only the YT contract can call them.
  • There is an isExpired() function that returns whether the PT is already mature and can be redeemed 1:1 for the underlying asset.

PendleYieldToken - YT

YT represents the yield of the underlying yield-bearing asset. By holding the YT token, the user can claim the yield + reward tokens generated by the underlying yield-bearing asset up to maturity. After the expiration, the yield stops accruing, and the YT price becomes $0. It is an ERC20 contract using the custom PendleERC20 implementation, where users can mint and redeem SY tokens in the form of PY tokens (PT + YT).

Permission Owner functions Criticality Risk
No access control - - -
  • Users can mint PY tokens by calling the mintPY(PTReceiver, YTReceiver). First, they must send the SY token to the contract, which will be minted at a 1:1 ratio. The mintPYMulti(PTReceiver[], YTReceiver, SYAmounts[]) can also be used to mint multiple PY tokens in a batch for multiple users. The PT tokens are sent to the PTReceiver, while the YT tokens are sent to the YTReceiver.
  • Users can redeem PT and YT in SY by calling the redeemPY(SYReceiver) function. They must send PT and YT to the YT contract first or only PT if maturity has been reached. Internally, it calls the _redeemPY() function, which burns the PT and YT tokens (YT only before maturity) and calls the _calcSyRedeemableFromPY() function to calculate the SY equivalent of the PY amount on the current index or in the first index after maturity, and then finalizes by transferring the SY to the user and adding any interest accrued post maturity to the treasury.
  • The redeemPYMulti((PTReceiver[], YTReceiver, PYAmounts[]) can also be used to redeem multiple PY tokens in a batch for multiple users.
  • Rewards and interest are paid in SY and distributed among YT holders before maturity. After that, YT holders do not receive any yield. They can claim the yield + rewards by calling the redeemDueInterestAndRewards(address, bool redeemInterest, bool redeemRewards) function. Internally, it accrues the rewards for the user in the inherited RewardManagerAbstract contract via the _updateAndDistributeRewards(user) function. Finally, it transfers the rewards if the flag redeemRewards is positive, and the same for the redeemInterest flag, which will first _distributeInterest(user) and then transfer the accumulated interest in SY tokens.
  • After maturity, interest and rewards are sent to the Pendle’s treasury via the redeemInterestAndRewardsPostExpiryForTreasury().

PendleMarket

PendleMarket is the contract that allows the creation of SY <> PT liquidity pools of the same type before maturity. Users can add or remove liquidity for LP tokens and swap directly between SY <> PT, where the LP holders receive swap fees. YT can be traded via flashswaps (via a router contract). It uses Pendle’s Math library MarketMathCore **for the swaps and liquidity provision logic and an OracleLib library representing the built-in oracle for the LP tokens.

Permission Owner functions Criticality Risk
No access control - - -
  • Users can add liquidity via the mint(address, SYAmount, PTAmount) function. This function internally calls the addLiquidity() in the MarketMathCore library to calculate the amount of LP tokens based on SYAmount and PTAmount. The tokens must be transferred to this contract before the LP tokens are minted.
  • To remove liquidity, users call the burn(SYReceiver, PTReceiver, LPAmount) function. This function calls the removeLiquidity() in the MarketMathCore library to calculate the amount of SY and PT and transfers the tokens for the SYReceiver and PTReceiver, respectively.
  • Back-and-forth swaps can be made via the swapExactPtForSy(receiver, PTAmountIn) and swapSyForExactPt(receiver, PTAmountOut) functions.
  • LP holders can collect rewards accrued via the redeemRewards(). The market contract implements the PendleGauge contract, which is responsible for distributing PENDLE tokens to the LP holders.
  • There is an observe(secondsAgo[]) function that returns the cumulative implied rates at specified time intervals. These cumulative implied rates can be used to calculate the Time-Weighted Average Price (TWAP) implied rate over a given interval by dividing the difference between two cumulative rates by the time elapsed.
  • To observe the cumulative implied rates, the oracle needs to be initialized in the market by calling the increaseObservationsCardinalityNext(cardinalityRequired) function, passing the cardinalityRequired (number of blocks) for the specified TWAP duration.
  • It is important to mention that the market is safeguarded against any kind of donation attacks, given its usage of internal accounting when dealing with the PT and SY tokens.

PendlePYLpOracle - Oracle

The Pendle Oracle contract provides the exchange rate between its tokens involved in the protocol, such as PT, YT, LP to SY, and PT, YT, and LP to the underlying asset based on the TWAP prices. It is an OZ Transparent Proxy that uses the PendlePYOracleLib **and PendleLpOracleLib to fetch rates from the PendleMarket contract and handle potential PT depeg scenarios and SY solvency.

Permission Owner functions Criticality Risk
owner: Safe 2-of-4 setBlockCycleNumerator HIGH :green_circle:
  • The rates are calculated by obtaining the exchange rate of the SY and PY tokens (syIndex and pyIndex) by calling the internal getSYandPYIndexCurrent(market) function, which calls SY.exchangeRate() for syIndex and YT.pyIndexStored() for pyIndex ensuring it is up to date otherwise it uses the max(SY.exchangeRate(), YT.pyIndexStored()) for handling the PT depeg. Then, it calls the getPtToAssetRateRaw(market, duration) that returns 1 if the maturity has been reached or calls the market.observe(duration) to compute the PT rate from the cumulative implied rate at duration.
  • (PT, YT, LP) <> Underlying Asset
    • The functions below handle cases where syIndex < pyIndex (insolvency) by returning the TWAP exchange rate multiplied by the SY exchange rate.
    • The getPtToAssetRate(market, duration) function calculates the PT <> underlying asset exchange rate of the market over the duration. For YT <> asset and LP <> asset, the exchange rate can be obtained by calling getYtToSyRate() and getLpToSyRate(), respectively.
  • (PT, YT, LP) <> Underlying Asset
    • The function below adjusts the exchange rate for syIndex when syIndex > pyIndex or adjusts for pyIndex, which handles insolvency cases.
    • The getPtToSyRate(market, duration) function calculates the PT <> SY exchange rate of the market over the duration. For YT <> SY and LP <> SY, the exchange rate can be obtained by calling getYtToSyRate() and getLpToSyRate(), respectively.


Miscellaneous

Introducing Principal Tokens as collateral into Aave can bring benefits such as increased liquidity with this new category of fixed-rate assets, similar to bonds with maturity. However, it also introduces several complexities regarding post-expiration management and pricing correctly until maturity, which the DAO must evaluate and consider before any listing.

PTs are traded at a discount to the underlying asset and gradually move to 1:1 parity at the expiration date, where they stop appreciating, and they must be redeemed for the underlying asset. By listing a PT token on Aave, as soon as it reaches maturity, the asset can be frozen or simply stay as a wrapper of the underlying with a 1:1 price.
To automate the management of PTs, we suggest a steward contract that can freeze the market so as not to allow further deposits after they reach maturity.



Asset pricing

Pricing PT has been extensively discussed in the forum, with different alternatives presented by Chaos and Llama risk also participating in the conversation. For different reasons, each suggestion has its pros and cons, and overall, the community showed no comfort with such approaches.


As we commented on the pricing options thread, we think the pricing algorithm proposed by Chaos Labs is the most efficient. However, we respect the arguments and decision of the community to not proceed with it, and designed a slightly different approach: what we call the dynamic linear discount rate oracle.

As presented by Chaos Labs on the pricing thread, one of the pricing methodologies out there is based on a linear discount rate forrmula: this rate is configured when the asset is listed, and by calculating the remaining time to maturity, it applies that rate to discount the price from par (1:1). This approach is, even if not representing how the market of PTs behave (volatile enough during lifetime), tries to approximate it based of the principle that the further a PT is from maturity, the higher the discount (lower the price), and at maturity, it becomes 1:1, as the underlying is fully redeemable.

Our dynamic linear discount rate oracle follows the same principle, but the main difference is that the discount itself is configurable during the lifetime of the PT.
For example, maybe at the very beginning of the maturity, the risk modelling indicates that due to high volatility, a conservative approach is to have a 40% discount rate, linearly increasing the price as time passes at a 40% “rhythm”.
But after 1 month, maybe the volatility profile of the underlying changed heavily, or the expected returns on the YT have substancially decreased, which means that becomes natural to reduce the discount rate itself to let’s say 20%.

Going more to the technical details, the adapter oracle contract and the way it should be configured have some extra limitations:

  • At a listing stage, the risk team should recommend a maximum discount rate. This is a conservative limit above which the dynamic discount configuration can’t go. The rationale is to protect the oracle layer itself from unexpected (big) discount rate changes.
  • In parallel, a discount rate is configured at listing time, which reflects a slightly closer discount for exactly the current market conditions of the PT, considering also the risk parameters on Aave (LT, LB). This is the dynamic configuration that later on will be updated if required.
  • Aside from the max protections, the dynamic change must be regulated via a risk steward, highly constrained to not allow change on the rate of discount more than X% %, every 2-3 days.
  • Additionally, depending on the underlying, the feed uses under the hood CAPO with Chainlink, or plainly Chainlink.

This approach for pricing seems less prone to manipulation. However, we must highlight that the risk partners should evaluate and understand how the base discount should be configured. Further monitoring must be made so it can be adjusted along the PT maturity based on market implications to reduce possible price discrepancies on Aave compared to other markets.


The dynamic linear discount oracle can be found here, and has been reviewed by @Certora.



Procedure to follow when listing PT instances

It is important to highlight that this analysis is meant to provide a general understanding of the Principal Tokens asset class and not a specific asset analysis like we have been doing for any asset listed on Aave.


However, aside from the risk analysis side of each PT instance listing, it is possible to already comment on “light” technical aspects that should be verified on each PT instance listing:

  • We should analyze the SY contract implementation and whether it inherits the logic from the base SY contract implementation, because some can use custom implementations reflecting unique aspects of the protocol/underlying yield-bearing token.
  • Check that the PT was deployed by the YieldContractFactory, where the PT and YT codes from the factory are immutable and were well audited with no issues so far.
  • The high-level permissions and access control of the related contracts, e.g., who the SY contract owner is.
  • Same procedure we have been doing for LRTs and LSTs is to check whether the underlying assets are already present on Aave, which reflects the security that we already evaluated. If the underlying of the PT suggested is not yet on Aave, an extra analysis must be made of it, too.
  • Like LRT/LSTs, the price feed coupled in the linear discount price adapter should be the same as its underlying asset on Aave, given that they are correlated assets.
  • Evaluating how long the time to maturity is is a must for listing new PTs due to the duration risks that could quickly change the price of the PT, where if the expected yield of the yield-bearing token increases, the YT will be tradable at a higher price while decreasing the PT price significantly. Longer maturities are less predictable in terms of expected yields, which means that, for Aave, a “good” PT should likely have its yield side within a range that will not expose the protocol to extreme volatility in the PT price.
  • Right now, we don’t see relevant cases for borrowing PT, as we expected that users would exchange their PTs for the referent underlying asset after maturity. Given its implications, any listing suggested as borrowable must be carefully evaluated, and if possible, avoided.


Conclusion

We think Principal Tokens doesn’t have any problem in terms of integration with Aave. However, some procedures addressed in the topics above must be followed before listing specific PT instances.

Additionally, we recommend on the governance side to have an ARFC for approving the pricing approach.

4 Likes

Thank you @bgdlabs for providing a solution to the pricing issue for Pendle PTs. A dynamic linear discount rate model, with Chainlink under the hood, seems like a good compromise. The market will have to be monitored carefully by the risk providers and the change in the discount rate (“X”%) needs to be discussed prior to implementation. This “X”% may also need to be different depending on the asset, but we could be conservative and incorporate a lower change by the Risk Steward in the beginning.

1 Like

I agree with @sid_areta, we have to monitor it and see how the market and assets behave. Hopefully that way Aave can finally profit from the potential market of Pendle token.

Summary

LlamaRisk acknowledges and appreciates the efforts of @bgdlabs in proposing a way forward for the pricing oracle of Pendle Principal Tokens (PTs). Resolving the Oracle question is crucial for onboarding PT assets, representing a significant opportunity for the Aave DAO.

The proposed dynamic linear discount rate oracle is a suitable and well-considered middle-ground solution. It balances the need for a market-reflective price feed without altering trust assumptions on external pricing sources while maintaining governance levers. The dynamic nature of the discount rate adjustment aligns with the broader view that each PT asset requires individualized monitoring and parameter calibration throughout its lifecycle, given the variance in underlying asset volatility and yield expectations.

Synopsis of the Dynamic Linear Discount Oracle

The dynamic linear discount oracle proposed by BGD Labs offers an approach that synthesizes elements from previously discussed models.

  • It builds upon the Static Linear Discount concept, where a PT’s price is calculated by applying a predetermined linear discount rate based on its time to maturity. The price converges towards par (1:1) as maturity approaches.
  • However, unlike the static model, the BGD proposal introduces dynamic adjustments to the linear discount rate during the PT’s lifetime. This allows the oracle price to adapt indirectly to significant changes in market conditions, underlying asset volatility, or yield expectations, which a static rate cannot account for.
  • This contrasts with the Dynamic TWAP Oracle previously proposed, which aimed for a more complex, data transformation-driven pricing mechanism based on observed prices, introducing different complexities regarding potential manipulation vectors and implementation robustness.

The BGD Labs proposal effectively acts as a bridge: it retains the predictability and simplicity of a linear discount framework while incorporating a necessary layer of adaptability managed through governance.

Key Differences in Pricing Approaches:

Feature Static Linear Discount Dynamic Linear Discount Dynamic TWAP
Discount Rate Fixed at listing Adjustable post-listing Implicit (derived from market)
Intervention Frequency None (time-based only) Moderate (Risk Steward changes) High (Edge enforced changes)
Update Mechanism Time progression Governance (Risk Steward) Market price changes (TWAP + Thresholds)
Complexity Low Low/Moderate High

General Considerations

Successful implementation relies on several key factors:

  1. Initial Discount Rate Calibration: Setting appropriate initial discountRate and maxDiscountRate parameters at listing is critical. This requires careful analysis of the specific PT, underlying asset, prevailing market conditions, and yield expectations.
  2. Onboarding Timing: We concur that onboarding PT markets only after an initial price discovery phase (e.g., 10-15 days post-launch on Pendle) is prudent. This allows the market to establish a baseline price and volatility profile, informing a more accurate initial discountRate setting for the Aave deployment.
  3. Risk Steward: The dynamic adjustment mechanism necessitates robust governance. The proposed use of a Risk Steward, constrained by limits on the magnitude (e.g., 5%) and frequency (e.g., every 2-3 days) of discount rate changes, provides a controlled and transparent adjustment method. All to be announced publicly to make it possible for LlamaRisk and other governance entities to peer-review the changes.
  4. Overpricing Risk: This approach inherently minimizes overpricing risk compared to potentially lagging market-based oracles, as the price is derived from a controlled discount. While underpricing relative to the secondary market is possible if the discount rate isn’t adjusted promptly, the over-valuation of collateral within Aave is the primary risk mitigated. Diligent monitoring and adjustment by the Risk Steward are key to keeping the oracle price reasonably aligned with fair value.

Future Improvements

The dynamic linear discount model provides a solid foundation. Nonetheless, based on future observations of its performance and the behavior of PT markets within Aave post-listing, we could propose further improvements:

  1. The effectiveness and optimal frequency/magnitude constraints for discount rate adjustments can be refined over time based on observed market dynamics and operational overhead.
  2. The linear model offers simplicity, but future iterations could explore a dynamic exponential discount model. As our initial comment on the original thread covered, an exponential curve might more accurately reflect the typical price behavior of zero-coupon bond-like instruments (such as PTs), where price sensitivity to rate changes is higher further from maturity. This could be considered for future PT listings or Oracle upgrades if the linear model shows limitations.

LlamaRisk supports proceeding with the dynamic linear discount rate oracle framework proposed by @bgdlabs, subject to careful parameterization and diligent ongoing management via the designated Risk Steward process. It offers a secure and adaptable solution to onboard PT assets to Aave.

Disclaimer

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

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

I have a minor concern with allowing PTs to be used on AAVE as collateral.

The issue being, similarly to Morpho, traders use this in order to do leveraged loop trading.

So they’ll convert AssetA into PT-AssetA, then take PT-AssetA into AAVE, borrow more AssetA (or AssetB, which they’ll convert into AssetA), and then redo the entire loop.

This allows users to essentially leverage their trades and if the PT or the asset depeg it will have serious consequences.

I’d advise against allowing PT to be used as collateral.

Summary

Chaos Labs strongly supports the addition of Pendle PT tokens to the Aave V3 Core instance and has collaborated extensively with @BGDLabs to design and develop a safe and manipulation-resistant oracle setup for the PT assets. This will enable Aave to provide unmatched capital efficiency while maintaining high-level security measures to prevent shortfalls. Chaos Labs has established a comprehensive methodology to best evaluate these assets and quantify optimal parameterization based on a dynamic risk oracle configuration, as extensively covered here; below we expand on the relevant adjustments based on the mathematical implementation of the dynamic linear discount oracle.

Adjusted PT Pricing Algorithm

Given the dynamic linear discount oracle’s approximative nature in modeling the logarithmic behavior of the PT token price, we apply a transformation to more accurately capture the real-time market dynamics based on the derived Aave price.

Recall that the PT market price is given by:
image

where t denotes the time to maturity in years. To operate our duration-based algorithm under the specified deviation threshold from the observed PTPrice_{market}, we transform the price expression linearly to determine the discountRatePerYear:
image

This linear transformation provides an effective approximation of the exponential market price derivation and will be directly incorporated into our quantitative modeling framework to enable adaptive updates to discountRatePerYear in response to real-time price behavior.

Max Discount Configuration

Due to the concavity inherent in the exponential pricing model of PTs, we quantify the upper bound of discountRatePerYear—denoted maxDiscountRatePerYear—based on the theoretical maximum implied APY, as constrained by the Pendle AMM mechanics. Notably, as t→0, the per-year discount rate converges to the logarithmic implied rate, given by:
image

Thus, we configure:
image

Here, maxlnImpliedRate corresponds to the implied rate when the PT price reaches its theoretical minimum within the configured Pendle AMM, occurring when PTs constitute 96% of the liquidity pool. The minimum PT price is determined by the Pendle AMM curve:
image

Setting maxDiscountRatePerYear below this maximum logarithmic implied rate can lead to misrepresentation of the lower bound on Aave, preventing the oracle from tracking further price decline due to configuration constraints. This could result in inaccuracies when the minimum PT price is reached within the AMM.

For instance, below we present the evolution of the transformed discountRatePerYear assuming a Pendle-configured maximum implied APY of 50%. It is thus integral that we parameterize the maxDiscountRatePerYear based on the assumption that the discountRatePerYear will increase as the asset converges to maturity.

We are looking forward to the addition of Pendle PT Assets to Aave. They provide the platform with a significant growth path into fixed-yield products and are expected to bring meaningful revenue to the Aave DAO. Chaos Labs will be providing technical and risk analysis when specific assets will be requested through the governance process.

Disclaimer

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

Copyright

Copyright and related rights waived via CC0

2 Likes

With the amount of work that has gone into the pricing issue with Pendle Tokens, we support launching this market while closely monitoring its performance.

Given the support from the community and risk providers on the proposed solution to price the Pendle asset class, the following is a summary of what should be approved in an ARFC Snapshot:

  • By default, Pendle tokens should be priced via a dynamic linear discount mechanism, with/without any other required protection like CAPO, depending on the underlying.
  • A maximum linear discount rate will be configured at the AIP stage; a threshold over which the linear discount rate parameter can’t ever go.
  • Similar to other risk parameters, a manual AGRS (risk steward) will be allowed to change the linear discount rate via the setDiscountRatePerYear() on the PT price adapter feed. Submitted to changes on the conservative side on AIP (potentially lower), but for ARFC, the constraints on the steward side will be of a maximum 20% relative change (compared with the current value of the linear discount rate).
  • Regarding risk parameters on the protocol, aside from governance, LB/LTV/LT will be changeable via automated AGRS, with a constraint of a maximum 50bps every 2 days. As clarification, these changes are expected to be generally increasing LT and decreasing LB, so factually on the positive side of user positions.
  • Any trigger of freeze/LTV0 will be done via Guardian, following a recommendation from @ChaosLabs, monitoring if the conditions would meet.

To proceed with the following activation AIP steps, we would appreciate if @ACI could escalate the ARFC via the Skywards program.

4 Likes

The current proposal has been escalated to ARFC Snapshot.

Vote is already open, we encourage everyone to participate.

Vote

After Snapshot monitoring, the current ARFC Snapshot ended recently, reaching out both Quorum and YAE as winning option, with 446.5K votes.

Therefore [ARFC] Onboard Pendle PT tokens to Aave V3 Core Instance has PASSED.

Next step will be the publication of an AIP for final confirmation and enforcement of the proposal.