[ARFC] Upgrade PT Risk Oracle to Protocol-Owned Infrastructure on CRE
Summary
LlamaRisk proposes upgrading the Pendle PT risk oracle stack to an automated pipeline that enhances Aave’s protocol-owned risk infrastructure: Aave Governance owns every contract, the risk manager only proposes, and every parameter and tuning decision is recorded onchain. The proven linear discount-rate model and the Risk Agents middleware carry over unchanged; what changes is the offchain sender and the path each update takes onchain. Three Chainlink Runtime Environment (CRE) workflows will compute the smoothed implied rate, the discount rate, and the per-E-Mode LT, LTV, and LB parameters, each publishing a signed report that a new router validates and writes onchain. The methodology parameters that drive them live in an onchain ParameterRegistry.
The pipeline executes atomically: a single signed report writes to the oracle and triggers execution via the existing AgentHub in a single onchain transaction. The same architecture is built to bring the next oracle families (slope2, CAPO, the supply/borrow-cap oracle, and the automated freeze guardian) onto the same router, oracle, and registry, consolidating Aave’s risk surfaces on one protocol-owned stack with no change to the integration, transparency, or access-control surface.
Motivation
When Chaos Labs stepped down from risk management for Aave, the PT risk oracle stack was effectively deprecated. Since then, LlamaRisk has ensured continuity by monitoring the in-scope markets and pushing just-in-time parameter changes through the Risk Stewards path, running its own methodology manually. This transitional path was never meant to be permanent: it carries ongoing manual overhead and key-person risk, and like the system it replaced, it asks the DAO to trust an offchain process it cannot directly verify.
That opacity is the core problem this proposal addresses. The prior Chaos Labs setup gave the DAO no visibility into the offchain system that computed its risk parameters, and LlamaRisk observed cases in which the parameters deployed onchain diverged from the published methodology.
This proposal moves PT risk onto transparent, protocol-owned infrastructure where the methodology parameters, every input, and every resulting change are recorded onchain and independently verifiable. Computation runs in battle-tested Chainlink CRE workflows, the parameters they read live in an onchain registry, and execution flows through the Risk Agents middleware that Aave Governance already owns. Every published value is signed by a registered CRE workflow and gated by the AgentHub’s generic safety checks before it reaches a pool. The linear discount-rate model and the Risk Agents architecture are unchanged; the same risk assumptions hold, now with predictable behavior, clear thresholds, and a public onchain audit trail of every parameter change.
Integration Path
This proposal leaves the onchain surface Aave Governance owns intact and replaces only the offchain sender. Computation runs in three independent CRE workflows: a single new router, a new middleware layer in front of the Risk Oracle, receives each signed report and, in a single onchain transaction, writes to the Risk Oracle and triggers the existing Risk Agents middleware. Aave Governance still owns every contract; the risk manager only proposes.
Overall Flow
A parameter update moves through four layers:
- Offchain CRE. Gathers Pendle market state, reads the onchain
ParameterRegistryandLlamaguardRiskOracle, runs the methodology rule, and emits one signed report. - Router. Validates the report’s source tuple, then publishes it and triggers execution in a single atomic step.
- Oracle and AgentHub. Stores the typed update and re-runs the existing generic safety checks for delay, expiration, replay, and range.
- Aave-side execution. The typed agent mutates the state on the
PendlePriceCapAdapteror thePoolConfigurator.
The defining property is one signed report, one atomic onchain transaction. The router decodes the report, publishes to the oracle, calls AgentHub.check, and, if actions are returned, calls AgentHub.execute, all in the same transaction. This collapses a publish step, an offchain keeper poll, and a separate performUpkeep call into a single router call. CRE never holds direct write authority over Aave pool configuration: every mutation goes through a typed agent under the existing AgentHub permission model, and the AgentHub re-runs its full safety checks at execute time regardless of the caller.
Chainlink CRE Workflows
Three CRE workflows share a common library that handles Pendle AMM reads, registry reads, risk-oracle reads, and CRE report signing. Each owns its own publish-and-execute cycle and runs on its own cadence. Two are primary: the discount-rate and risk-parameters workflows, which produce the parameters that reach Aave. The third, the EMA workflow, is peripheral: it supplies a smoothed implied rate that the two primary workflows read.
- Discount-rate workflow. Consumes the latest
r_emaas a single number, applies the rule from the Dynamic Discount Rate section below, and publishes the result asPendleDiscountRateUpdateto the existingRiskOraclefor the existingAaveDiscountRateAgentto inject into thePendlePriceCapAdapter. - Risk-parameters workflow. Applies the rule from the Dynamic Risk Parameters section below and publishes
(LT, LTV, LB)per(PT, E-Mode category)reserve asEModeCategoryUpdateto the existingRiskOraclefor the existingAaveEModeAgent. One workflow run can emit multiple records, one per reserve the PT is listed in.
The EMA workflow computes a one-step EMA of Pendle’s lastLnImpliedRate per PT and publishes it as EmaImpliedRateUpdate, the r_ema that the two primary workflows consume. It has no Aave-side agent and does not directly drive any parameters.
All three workflows are deterministic by construction. Reads are taken at finalized confidence; randomness and wall-clock times are taken from the CRE runtime rather than process-local sources; and workflow IDs are pinned per environment and validated by the router on every report. Rotating a workflow requires a coordinated multisig action on the router; it cannot land silently.
Smart Contract Stack
This proposal reuses all contracts on the existing Risk Agents path and adds three new contracts upstream of AgentHub. Reused contracts (AaveOracle, PendlePriceCapAdapter, AgentHub, RangeValidationModule, AaveDiscountRateAgent, AaveEModeAgent) are pulled from aave-address-book per network. The PT price surface and the typed agents that inject discount-rate and E-Mode updates are exactly the same code that Aave Governance already owns.
Three new contracts sit upstream of the AgentHub:
LlamaguardRiskOracleis a variant of the standardRiskOraclethat accepts writes only from the router. It stores the Price EMA and Pool Proportion EMA, keyed by(updateType, market), and exposes theIRiskOraclesurface, which the two primary CRE workflows use to obtain the smoothed implied rate and proportion. The router writes it from thependle_ema_oracleworkflow’s signed report.LlamaguardRiskOracleRouteris the onchain atomic actor for every published update. It receives signed CRE reports through the Chainlink Forwarder, validates the source tuple(forwarder, author, workflowName, workflowId)against the workflow registered for that update type, publishes to theRiskOracle, and triggersAgentHub.check/AgentHub.executein the same transaction. It is designed to route across multiple risk oracles, such as slope2, CAPO, and future workstreams, as they come online.ParameterRegistryis the onchain home for the per-asset risk methodology parameters that the workflows read on every evaluation. It is the same registry shape as audited for LlamaGuard NAV, extended to cover PT and future Oracle families under the same contract.
Router authority is not load-bearing for execution safety. The publish call is the load-bearing step: if it reverts, the whole router call reverts, and the workflow retries on the next trigger. The subsequent AgentHub.check / AgentHub.execute calls are best-effort. A revert in either is caught and logged, leaving the oracle record in place for the next router call (or for a permissionless automation call to check and execute) to pick back up. The oracle is the source of truth; injection is a separate concern.
Ownership and Access Controls
Aave Governance owns every contract on this path; the risk manager only proposes. The Risk Agents middleware (AgentHub, AgentHubAutomation, RangeValidationModule, AaveDiscountRateAgent, AaveEModeAgent) does not move; it remains under the same Aave V3 ACL, is governance-owned, and remains unchanged. The PoolConfigurator and Pool are likewise unchanged. The three new contracts are also Aave-Governance-owned: the LlamaguardRiskOracle accepts writes only from the router, the router validates the workflow source tuple on every report, ParameterRegistry exposes an Updater role held by LlamaRisk so the per-asset methodology slice can be tuned transparently without a CRE redeploy, and LlamaguardRiskOracleRouter is provisioned to be Aave-Governance-owned, with LlamaRisk holding an Updater role for limited rights over update routes. Authorized-sender rotation on the oracle, workflow-tuple rotation on the router, and Updater-role changes on the registry are all multisig actions.
This is the same risk-manager handover pattern that occurred when Chaos Labs stepped down. Every onchain check that constrained the previous sender also constrains the new one, with the added constraint that the new sender is bound to a signed CRE workflow whose identity the router validates on every report.
Auditing
The incremental onchain surface is limited to three new contracts: LlamaguardRiskOracleRouter, LlamaguardRiskOracle, and ParameterRegistry. The LlamaguardRiskOracle and ParameterRegistry were already audited by two security teams as part of LlamaGuard NAV, so the router is the only contract that has not been audited. Certora audits will cover both the new contracts and the CRE workflow code, reviewing the offchain computation surface and the onchain enforcement surface as one integrated system.
Methodology
This section explains why the PT collateral price and the three reserve risk parameters, the liquidation bonus, liquidation threshold, and loan-to-value ratio, must move with the life of the position rather than be held fixed.
A PT is a zero-coupon bond whose volatility decays toward maturity
A Pendle PT is a claim on one unit of its accounting asset at a fixed maturity, where the accounting asset is the asset the PT price is denominated in. For a PT on sUSDe, this is USDe, so the PT redeems for the quantity of sUSDe worth one USDe at maturity rather than for one sUSDe. Before maturity, it trades at a discount to that redemption value. This is the payoff of a zero-coupon bond, and the AMM prices it as one. In units of the accounting asset, the PT price is
where r is the continuously compounded implied rate stored by the market and \tau is the time to expiry in years. As \tau \to 0 the price converges to par, P_{\text{amm}} \to 1, independent of r. Pendle enforces this pull-to-par mechanically: the redemption value is fixed at maturity, and the AMM shifts its curve over time, pushing the price toward that value as expiry approaches.
The same structure makes the PT less volatile over time. From P_{\text{amm}} = e^{-r\tau},
So the modified duration of the PT equals its time to expiry. For a given level of implied rate volatility, the PT price return volatility scales with \tau and decays to zero at maturity. The risk carried by a PT position, and the buffer needed to liquidate it safely, are therefore functions of \tau. A single fixed discount rate, liquidation bonus, or liquidation threshold is too loose far from maturity, where price uncertainty is largest, and too tight near maturity, where the position is close to riskless, and a wide buffer only locks up collateral. Parameters that move with \tau track the risk that is present.
How Pendle prices a PT: the AMM, the order book, and the trading range
Pendle V2 holds liquidity in a single pool of PT and SY, where SY is the wrapped yield-bearing form of the underlying. The AMM prices PT against SY in implied rate space through a logit curve adapted from Notional Finance. With pool proportion p = \texttt{totalPt}/(\texttt{totalPt} + \texttt{totalSy}) and \mathrm{logit}(p) = \ln(p/(1-p)), the pre-fee exchange rate in PT per SY and the PT price in SY per PT are
with \texttt{scalarRoot} a per market constant. On every trade the anchor a(\tau) is rebuilt from the stored implied rate r_{\text{last}} and the post-trade proportion p_{\text{last}},
so the implied rate stays continuous as \tau runs down between trades.
Alongside the AMM, Pendle runs an onchain limit order book. A taker swap fills resting limit orders first, in the direction the implied rate is moving, before touching the AMM. A single swap can be split across the order book and the AMM to reduce price impact. A limit order deepens executable liquidity at one implied rate but does not change the pricing curve. The order book is optional, and the AMM is the structural price reference.
The AMM trades within a bounded range. The constant \texttt{scalarRoot} sets the width of the tradeable implied rate range, with liquidity concentrated inside it, and the pool proportion is capped at \texttt{MAX\_MARKET\_PROPORTION} = 0.96. Selling PT into the pool raises p and the implied rate and lowers the PT price; buying does the reverse. The implied rate is strictly increasing in p, so the two move together: the AMM’s lowest quotable price, equivalently its highest quotable implied rate, is reached exactly at the proportion cap, while on the other side, PT is not quoted above par.
This makes the proportion cap the single boundary that matters for collateral. Heavy PT selling drives p toward 0.96; at the cap, the AMM rejects any trade that would push p higher, the marginal price is pinned at the boundary value, and additional PT can only be absorbed by resting limit orders if any are present. The boundary price is finite and computable from the curve. Separately, as \tau \to 0 the proportion term in E scales with \tau and shrinks, so near maturity the same proportion move produces a smaller price move, and the PT price range narrows.
For a liquidator unwinding PT collateral under stress, the worst price is the boundary value at the proportion cap. Resting limit orders cannot be assumed present in stress, so the collateral must be sized against that boundary price rather than a more favorable one.
High-leverage borrowers need a stable oracle; the protocol needs a solvency buffer
A borrower’s health factor on a PT position is
where P_{\text{oracle}} is the oracle price of the collateral and \mathrm{LT} the liquidation threshold, so the collateral valuation feeds the health factor directly. The market price P_{\text{amm}} moves on every AMM trade, because r_{\text{last}} is updated on every trade. An oracle that tracked the market price one for one would pass that trade-by-trade noise into the health factor, and a borrower close to the liquidation boundary could be liquidated on a transient swing rather than on a real fall in value. Borrowers who run PT positions at high leverage need a valuation that is smooth and predictable, so they can compute the distance to liquidation and rely on it.
At the tail, the protocol needs the opposite. For a liquidation to clear without leaving bad debt, the oracle value of the collateral must not exceed what a liquidator can realize when selling it, and there must be a buffer for the gap between the oracle price and the realized execution price under stress. A valuation that is only smooth is not enough; it must also stay defensive when the market moves against the position. These two requirements cannot both be met by one setting: a fast oracle is defensive but noisy, and a slow fixed oracle is stable but cannot be both defensive and efficient: set loose, it drifts above realizable value, set tight, it locks up collateral.
A dynamic risk oracle delivers stability, predictability, and a defensive posture
The two requirements are reconciled by separating the central valuation, which is kept smooth, from the loss-absorbing parameters, which are stressed. The collateral is valued by a linear discount that pulls to par along a known line, moved only by a slow trigger with a cooldown and a cap on each downward step, so it is smooth and predictable for a borrower. The liquidation bonus is sized to the cost of unwinding the collateral at the edge of the trading range, and the liquidation threshold stays solvent at the worst price the AMM can quote, so both stay defensive when the market moves. The discount rate carries a ceiling, so the worst price the oracle can quote is tied to the worst price the AMM can quote on the same convention. Because each parameter depends on the time to maturity and the live pool, one rule provides a high-leverage borrower with a stable, predictable valuation and the protocol with a defensive buffer against bad debt.
Dynamic Discount Rate
This section specifies the discount rate, the parameter that sets the central valuation of the PT, and the rule that maintains it over the life of the position.
Definition and formulas
The oracle stores one number per market, d = \texttt{discountRatePerYear}, and quotes the collateral at
where \tau is the time to maturity in years. Between updates d is fixed, so the quoted price is a straight line in \tau that reaches par at maturity, as set out in the preceding section.
The rule keeps d aligned with the market by comparing the oracle price to the AMM price P_{\text{amm}}(\tau) = e^{-r\tau} from the preceding section, with r the implied rate, and updating d only when the gap is large enough. Each update is smoothed, rate-limited by a cooldown, and capped on the downside.
Deviation. The signed relative gap between the two prices is
A positive deviation means the oracle prices the PT above the AMM, so the lender is exposed. A negative deviation means the oracle prices it below the AMM, so the borrower carries a wider discount and the lender is protected.
Target. When the rule updates d it targets the value that makes the oracle price equal the AMM price at the current \tau. Setting 1 - d\,\tau = e^{-r\tau} and solving for d gives
This is the simple discount rate over horizon \tau whose terminal price matches continuous compounding at rate r over the same horizon. It is well-defined for any PT price strictly between 0 and 1, which holds for every PT before maturity. Because the implied rate moves with every AMM trade, the rule uses a smoothed rate in place of the instantaneous rate r. The smoother is an exponential moving average of the implied rate, taking the last observation in each hour, with span s in hours:
The target is then evaluated as d_{\text{target}}(\bar r, \tau).
Update rule. The rule steps forward by one hour at a time and fires only when both the deviation gate and the cooldown hold.
On a fire, the update splits into two arms. On the price down arm, where d_{\text{target}} > d and the oracle price falls, the single step is capped. Since P_{\text{oracle}} = 1 - d\,\tau, holding \tau fixed at the firing instant gives |\Delta P_{\text{oracle}}| = \tau\,\Delta d, so the cap on d is
which forces |\Delta P_{\text{oracle}}| \le \texttt{MAX\_PRICE\_DROP\_BPS}/10000 on every downward fire. Combined with the cooldown, the oracle price cannot fall by more than \texttt{MAX\_PRICE\_DROP\_BPS} within a single cooldown window. On the price up arm, where d_{\text{target}} < d and the oracle price rises, the update goes straight to the target with no cap,
The two arms are not symmetric. From the health factor in the preceding section, a fall in the oracle price lowers every borrower’s health factor against this collateral, while a rise raises it. The downward move is therefore rate-limited and capped, so it cannot move faster than the bound, and the upward move, which only relaxes positions, is not throttled.
Inputs and outputs
At each step, the rule reads the implied rate r from the AMM, the time to maturity \tau, the current stored amount d, and the time of the last fire. It outputs the updated d, from which the oracle quotes P_{\text{oracle}}(\tau) = \max(1 - d\,\tau, 0).
The configuration parameters are:
| parameter | role |
|---|---|
| \texttt{THRESHOLD} | symmetric gate on \lvert\mathrm{dev}\rvert that must be exceeded for a fire |
| \texttt{MIN\_DELAY\_HOURS} | cooldown, the minimum time between two fires on one market |
| \texttt{MAX\_PRICE\_DROP\_BPS} | cap on the single-step price fall on the down arm; the up arm is uncapped |
| s | span of the exponential moving average on r, in hours |
| \texttt{MAX\_DISCOUNT\_RATE\_PER\_YEAR} | ceiling on d, fixed per market at onboarding (see Onboarding parameters) |
The cooldown \texttt{MIN\_DELAY\_HOURS} rate limits fires and the smoothing span s sets the averaging window, so updates are infrequent and the rate fed to the target is smooth. The gate and the downward cap determine how closely the oracle tracks the AMM and how quickly it can fall; their trade-off is shown below.
Threshold tradeoff
The gate sets how far the oracle may drift from the AMM before it updates. Running the rule across the full history of all sixteen markets and pooling all hours, with the downward cap held at 10 bps, the share of time the oracle sits above the AMM (overpriced, lender exposed) and below it (underpriced, lender protected), with the median deviation in each state, moves with the gate:
| \texttt{THRESHOLD} | time overpriced | time underpriced | median over (bps) | median under (bps) |
|---|---|---|---|---|
| 0.05% | 49.16% | 50.84% | 1.74 | −2.55 |
| 0.10% | 45.35% | 54.65% | 2.62 | −3.74 |
| 0.20% | 33.35% | 66.65% | 5.55 | −6.84 |
| 0.30% | 30.41% | 69.59% | 7.02 | −8.62 |
| 0.50% | 29.41% | 70.59% | 9.93 | −12.75 |
As the gate widens, the oracle spends less time above the AMM and more time below it, so a wider gate moves the rule toward the protected side. At the same time, the median gap in both states widens because a wider gap allows the price to drift further before it corrects. A tight gate holds the oracle close to the AMM with small deviations on both sides, at the cost of more frequent updates. A wide gate updates infrequently, providing the stability a high-leverage borrower needs at the cost of larger, more typical deviations and more time spent away from the AMM.
The downward cap governs only the down arm. A smaller cap lets overpricing accumulate over more days, since the oracle lags a sharp fall and stays above the AMM longer, while a larger cap closes the downward gap faster at the cost of a larger single-step price move.
Case studies
Three prices can be compared on the same hourly grid: the deployed Aave oracle P_{\text{aave}} = 1 - d_{\text{deployed}}\,\tau, driven by the steward’s discount rate; the Pendle AMM price P_{\text{amm}} = e^{-r\tau}; and the proposed oracle P_{\text{base}} = 1 - d_{\text{mechanism}}\,\tau, driven by the rule above. The mechanism targets the AMM rather than replicating the steward, and every deployed steward update moves the discount by exactly 1 percentage point, so the mechanism’s discount can sit up to about 1 percentage point away from a given deployed level.
PT sUSDE 25SEP2025, down arm. The AMM discount rose over the life. The rule stepped the discount up in capped increments, firing the down arm four times, and ended at 9.94% against the deployed 9.69%. This is the rule tracking a rising AMM discount in bounded steps.
PT USDe 27NOV2025, up arm. The AMM discount fell. The rule fired the arm once and refit straight to the target, ending at 7.94% against the deployed 7.51%. This is the uncapped upward refit, relaxing the discount in a single step.
PT sUSDE 7MAY2026, near maturity. The steward cut the discount from 5.02% to 4.02%, but the rule did not fire, holding at 5.02%. With both prices close to par, the same rate gap yields a smaller |dev|, and the gate is not crossed. Because the price is 1 - d·τ, a discount gap Δd is only Δd·τ in price terms, here under twenty basis points and falling to zero at maturity.]
Onboarding parameters
Two values are set per market at onboarding: the starting discount rate and the ceiling on the discount rate.
The starting \texttt{discountRatePerYear} is the value the mechanism begins from and then maintains through the rule above.
The ceiling \texttt{MAX\_DISCOUNT\_RATE\_PER\_YEAR} is immutable, set once in the adapter at listing and not changed afterward; the steward setter enforces d \le d_{\max}, so the discount is bounded above and the oracle price is bounded below by 1 - d_{\max}\,\tau. The ceiling is the simple discount that matches the AMM’s quote at the proportion cap \texttt{MAX\_MARKET\_PROPORTION} = 0.96, the highest proportion the AMM allows, and so its lowest quotable price, taken to leading order in the time to maturity and at the implied rate fixed when the Pendle market was created. It reduces to a closed form in three Pendle market immutables,
where \texttt{scalarRoot} and \texttt{initialAnchor} come from the Pendle market and its creation event, and \texttt{yearsLeft} is the original term length of the Pendle market, (\text{expiry} - \text{market creation}) in years. \texttt{yearsLeft} is the full term fixed at market creation, distinct from the time to maturity at listing, the adapter deployment, and the current time. The resulting ceiling is specific to each market.
Dynamic Risk Parameters
This section specifies the three reserve risk parameters, the liquidation bonus, the liquidation threshold, and the loan-to-value ratio, and the rule that computes each from the time to maturity \tau and the live pool. The discount rate from the preceding section sets the collateral’s central valuation; these parameters determine how much loss the reserve absorbs when a position is liquidated against that valuation.
Throughout, P_{\text{oracle}}(\tau) = 1 - d\,\tau is the oracle price from the discount rate section, with d the live discount the mechanism maintains, and E(p,\tau) with P_{\text{amm}} = 1/E is the Pendle AMM rate from the AMM pricing section above. Where the rule needs the implied rate or the pool proportion, it consumes the same exponential moving average used for the discount rate, of span s on hourly observations: \bar r is the smoothed implied rate and \bar p the smoothed proportion.
Definition and formulas
Liquidation bonus. The bonus is a floor plus a slope,
both in percentage points, with [\,\cdot\,]_+ the positive part. The floor L_u^{\text{net}} is the slope-free cost of unwinding and depends only on the debt category D and the underlying U. The slope is the extra bonus a liquidator needs when the oracle prices the PT above the AMM’s fill price.
A liquidator who repays D units of debt receives PT worth D(1 + \mathrm{LB}) at the oracle price, that is D(1 + \mathrm{LB})/P_{\text{oracle}} units, and sells them into the AMM at P_{\text{exec}}. Setting the proceeds equal to the debt repaid gives the break-even bonus
With the debt asset price canceled. The slope is this quantity evaluated at a reference endpoint on the AMM curve. A liquidator selling PT raises the pool proportion, so the endpoint is set as a fixed multiple of the smoothed proportion, clipped at the Pendle ceiling.
and the execution price there is P_{\text{exec}} = 1/E(p^\star, \tau). Writing the AMM rate at the endpoint with the anchor rebuilt from the smoothed state gives
This is P_{\text{oracle}}(\tau)\,E(p^\star, \tau) - 1. At maturity E(p^\star, 0) = 1 and P_{\text{oracle}}(0) = 1, so the slope is zero and the bonus reduces to the floor. The positive part is taken before the floor is added: when the oracle sits at or below the AMM execution price at the endpoint, the slope contributes nothing.
Liquidation threshold. The threshold is the smaller of a governance cap and a solvency bound.
The cap \mathrm{LT}_{\text{cap}} is a fixed ceiling set at onboarding. The solvency bound sizes the threshold so the full collateral, valued at the worst price the AMM can quote, still covers the debt plus the bonus at oracle terms. The oracle price in the denominator uses the live discount d; the worst price in the numerator uses the discount ceiling.
The worst price is the AMM price at the proportion ceiling with the anchor at its most adverse admissible corner. The AMM rate increases in proportion, and the anchor increases in the stored rate and decreases in the stored proportion, so the lowest price sits at the proportion ceiling, with the anchor set at the lower proportion bound and the rate ceiling. The rate ceiling is fixed to the discount ceiling on the same convention, \exp(r_{\max}\,\tau) = 1/(1 - d_{\max}\,\tau), where d_{\max} = \texttt{MAX\_DISCOUNT\_RATE\_PER\_YEAR}. Using \mathrm{logit}(0.96) = \ln 24 and \mathrm{logit}(0.1) = -\ln 9, the stressed anchor and price are
with \ln 24 + \ln 9 = \ln 216. The domain d_{\max}\,\tau < 1 is exactly the domain on which the oracle price is positive, so the stressed price is defined wherever the oracle is.
Loan-to-value. The loan-to-value ratio is the threshold less a fixed buffer b,
The buffer is held constant across every reserve in scope.
Inputs and outputs
Each evaluation reads the time to maturity \tau, the smoothed proportion \bar p, and the smoothed rate \bar r from the AMM, the live discount d maintained by the discount rate mechanism, and the per market constant \texttt{scalarRoot}. It reads four values fixed per market at onboarding: the discount ceiling d_{\max}, the cap \mathrm{LT}_{\text{cap}}, the floor L_u^{\text{net}}, and the endpoint multiplier k. It outputs the three parameters \mathrm{LB}, \mathrm{LT}, and \mathrm{LTV}.
The split between live inputs and fixed inputs follows the split between the two requirements. The proportion and rate are smoothed so the parameters do not move on trade-by-trade noise, the same reason the discount rate is smoothed. The cap, floor, ceiling, and multiplier are fixed per market, so the defensive posture does not drift once the reserve is onboarded.
| input | source | role |
|---|---|---|
| \tau | market maturity and block time | enters every parameter; the slope vanishes, and the stressed price reaches par as \tau \to 0 |
| \bar p, \bar r | AMM, smoothed | live pool state feeding the slope |
| d | discount rate mechanism | oracle price P_{\text{oracle}} = 1 - d\,\tau |
| \texttt{scalarRoot} | Pendle market | width of the AMM rate range |
| d_{\max} | onboarding | rate ceiling for the stressed price |
| \mathrm{LT}_{\text{cap}} | onboarding | upper bound on the threshold |
| L_u^{\text{net}} | onboarding | slope-free part of the bonus |
| k | onboarding | reference endpoint multiplier |
Tradeoffs
Two choices set how conservative the parameters are: the endpoint multiplier k for the bonus and the stress corner for the threshold.
The multiplier k sets how far a liquidator is assumed to push the pool. A larger k moves the reference endpoint p^\star further above the current proportion, which raises the AMM rate at the endpoint, lowers the execution price, and raises the slope and the bonus. A smaller k keeps the endpoint close to the current proportion and reduces the bonus. Once k\,\bar p reaches the ceiling, the endpoint pins at 0.96 and further increases in k have no effect. The bonus was evaluated across a range of multipliers and against fixed proportion ceiling alternatives, and the prediction is stable across the range.
The stress corner sets the worst price the threshold defends against. A lower proportion bound or a higher rate ceiling raises the stressed anchor, lowers the stressed price, and lowers the threshold, making the approach more conservative. The proportion ceiling 0.96 is the structural Pendle cap, and the lower bound is held at p_{\min} = 0.1. The rate ceiling is not a free choice once the discount ceiling is set: it is pinned to d_{\max} through \exp(r_{\max}\,\tau) = 1/(1 - d_{\max}\,\tau), so the threshold stress and the oracle floor sit on one discount convention.
Case studies
Three series can be read over the life of a position: the deployed bonus \mathrm{LB}_{\text{aave}}, the proposed bonus \mathrm{LB}_{\text{PT}}, and the underlying floor L_u^{\text{net}} it settles onto. The floor is flat, so the slope is the only moving part: the bonus is widest early, where the time to maturity is long, and the AMM execution wedge is widest, and decays onto the floor as maturity approaches.
PT USDe 27NOV2025, low proportion. The smoothed proportion remained low, around 0.14, so the reference endpoint remained well below the ceiling, and the wedge it implied was narrow. The bonus was widest early in life and fell toward the floor through it. A calm, shallow pool keeps the endpoint modest, so the bonus tracks close to the floor.
PT USDe 25SEP2025, high proportion. The smoothed proportion ranged from roughly 0.32 to 0.59, high enough that the reference endpoint remained at its ceiling for most of the position’s life. The wider endpoint widens the wedge, so at a given time to maturity, the slope is steeper and the bonus rides further above the floor, staying there longer before settling at maturity. A deep pool drives the endpoint to the ceiling, so the bonus carries its largest slope.
At maturity, the slope vanishes exactly: the execution rate and the oracle discount both return to par, so the bonus equals its floor at expiry regardless of the pool. The bonus a position carries is widest when it is youngest, where the price can still move, and narrows to the floor as the PT is pulled to par.
Three series can be read the same way for the threshold: the deployed threshold \mathrm{LT}_{\text{aave}}, the proposed threshold \mathrm{LT}_{\text{PT}}, and the algebraic side \mathrm{LT}_{\text{alg}} it tracks until the governance cap takes over. The cap is flat, so the algebraic side is the only moving part, and it moves opposite to the bonus slope: the threshold is lowest early, where the worst case stress price sits deepest below par, and the bonus slope is widest, and rises onto the cap as maturity approaches.
PT USDe 27NOV2025, low proportion. With the proportion near 0.14, the bonus slope in the denominator was small, so the algebraic side sat higher for any given time left. It reached the cap a little further from maturity than the high-proportion PT, and stayed pinned there through expiry.
PT USDe 25SEP2025, high proportion. The larger slope pushed the algebraic side down, so it reached the cap a little closer to maturity than the low-proportion PT did.
At maturity, the stress price and the oracle both return to par, and the bonus collapses to its floor, so the algebraic side rises above the cap and the threshold pins to the cap regardless of the pool. The two sides bind on opposite ends of life: the algebraic side governs early, where the price can still move, and the cap governs late, once the PT is pulled to par.
Onboarding parameters
Three values are set per market at onboarding alongside the discount ceiling from the preceding section: the cap \mathrm{LT}_{\text{cap}}, the floor L_u^{\text{net}}, and the endpoint multiplier k.
The cap \mathrm{LT}_{\text{cap}} is the ceiling in the threshold and is fixed at onboarding. A higher threshold lets a borrower hold more debt against the same collateral, so the cap fixes the maximum leverage the reserve will carry against this debt independent of the live pool: where the solvency bound is slack, the threshold still cannot exceed the ceiling. It operates as a backstop rather than the day-to-day constraint, since the solvency bound is the binding side at every backtested event.
The floor L_u^{\text{net}} is the slope-free part of the bonus, the incentive a liquidator needs when the oracle and the AMM agree, and there is no price wedge for the slope to cover. It collects the flat costs of the unwind: the flash loan premium to source the debt repayment, the SY redemption to the underlying, and the conversion from the underlying to the debt asset. The first two are common across markets, so the floor varies by debt regime and underlying through the conversion, and is set per debt regime and underlying at onboarding.
The endpoint multiplier k is the assumed depth of a liquidator’s push on the pool; its value is fixed at onboarding, and the bonus prediction is stable across the tested range, so the choice is not sensitive. The discount ceiling d_{\max} is set once per market in the adapter as described in the discount rate section and enters here only through the stressed price.
Liquidators
The parameters are calibrated to a single model of how a liquidator unwinds PT collateral, and the methodology assumes the liquidator behaves exactly as described by that model.
A liquidator repays debt and receives PT at the oracle price with the bonus added, then sells that PT into the Pendle AMM. Selling raises the pool proportion and lowers the price received. The bonus is sized to the break-even of this unwind at the reference endpoint p^\star: the floor covers the cost when the oracle and the AMM agree, and the slope covers the wedge between the oracle valuation and the realized AMM price when the oracle is higher.
Three assumptions fix the model. First, the unwind goes through the AMM and not the limit order book. The order book can deepen executable liquidity at a rate, but it cannot be assumed to be present under stress, so the collateral is sized against the AMM curve alone. Second, the liquidator is assumed to push the proportion to p^\star = \min(k\,\bar p, 0.96), a multiple of the smoothed proportion clipped at the ceiling. Third, for the threshold, the worst price is the AMM price at the proportion ceiling with the anchor at the adverse corner (p_{\min}, r_{\max}).
The threshold condition is a wind-down solvency condition. When the live pool satisfies the three conditions
- the proportion stays at or above p_{\min} = 0.1,
- the proportion stays at or below 0.96,
- the market implied rate stays at or below r_{\max}, defined by \exp(r_{\max}\,\tau) = 1/(1 - d_{\max}\,\tau), the chain
holds, with the left relation an equality whenever the solvency bound is the binding side of the threshold, which is the case throughout the backtest. The left side is the oracle value of debt plus bonus per unit of initial collateral, and the right side is the worst price the AMM could quote for liquidating it, so the full initial collateral, valued at the worst feasible price, covers the debt plus the bonus at oracle terms. This guarantees the position can be wound down without bad debt under the stated conditions. It does not guarantee a liquidator will choose to act: that requires the stricter condition P_{\text{oracle}} \le (1 + \mathrm{LB})\,P_{\text{amm}}^{\text{true}} on the live AMM price rather than the worst feasible one.
Next Steps
- Gather feedback from the community.
- If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage.
- If the snapshot outcome is YAE, escalate this proposal to the AIP stage.
Disclaimer
This proposal was prepared by LlamaRisk, a DeFi risk service provider for the Aave Protocol, funded in part by the Aave DAO. It was produced as part of LlamaRisk’s risk-management mandate to the DAO.
The information provided should not be construed as legal, financial, tax, or professional advice.