Overview

The Pendle PT implementation is an automated risk oracle for Pendle Principal Tokens used as collateral on Aave. It continuously evaluates the documented PT methodology and publishes price-discount and collateral-risk recommendations through Chainlink CRE.

It is one oracle system implemented through three coordinated Chainlink CRE workflows—not three separate oracle products.

Complete Pendle PT risk-oracle system from finalized Pendle and Aave state and PTParameterRegistry configuration, through three Chainlink CRE workflows, the Forwarder and router, LlamaGuardOracle and RiskOracle storage, and constrained execution through AgentHub, RangeValidationModule, typed Aave agents, and permitted Aave targets. — The EMA record feeds the two recommendation workflows. Only records stored in RiskOracle enter the optional AgentHub execution path.

Closing the parameter-update gap

Pendle markets can reprice in minutes, while a manual risk-parameter update can take days of analysis, proposal preparation, review, signatures, voting, and execution. That delay can leave Aave operating with parameters derived from an earlier market state.

LlamaGuard PT automates the repeatable calculation and publication steps. It does not remove Aave's guardrails: workflow identity, registry parameters, route controls, AgentHub delays, validation ranges, typed agents, and contract ownership remain enforced on-chain.

Why PT collateral needs a dynamic model

A Pendle Principal Token represents the principal portion of a yield-bearing position. Before maturity it normally trades below its redemption value; at maturity it becomes redeemable for the accounting asset and its price converges toward that value.

This makes a PT economically similar to a zero-coupon bond. Its price depends on the yield implied by the market and the remaining time to maturity. Its collateral risk also depends on the depth and shape of the Pendle AMM available to liquidators.

A static price discount can drift away from the market. Static liquidation settings can also become unnecessarily conservative or insufficiently protective as liquidity, time to maturity, and implied rates change.

This is not a PT price feed

The system does not replace Aave's asset-price oracle. It answers a different set of questions:

what discount-rate setting keeps Aave's bounded PT price aligned with the smoothed Pendle market signal;
how much borrowing power is appropriate for the PT's eMode categories; and
at what threshold and incentive a stressed PT position can be liquidated without violating the model's solvency constraints.

Market prices are inputs to these decisions, not the complete answer.

What the implementation recommends

Recommendation	Purpose	Intended Aave agent
PT discount rate	Aligns Aave's bounded PT price with the smoothed Pendle market signal	`AaveDiscountRateAgent`
Loan-to-value	Sets maximum borrowing power for the relevant eMode category	`AaveEModeAgent`
Liquidation threshold	Sets the point at which PT-backed positions become liquidatable	`AaveEModeAgent`
Liquidation bonus	Compensates liquidators for stressed PT execution	`AaveEModeAgent`

The system also publishes a smoothed market-state record containing implied rate and pool proportion. This record is shared input for the recommendation workflows and is not itself an Aave parameter recommendation.

Why Chainlink CRE

The three models compile to deterministic WASM workflows executed by a Chainlink DON. Nodes must agree on the capability results and workflow output before a quorum-signed report is produced. The on-chain Forwarder verifies that report, and the router accepts it only when its Forwarder, author, name, and workflow ID match the registered route.

The proposed production design makes this infrastructure protocol-owned: Aave Governance controls the contracts and authorized workflow identities, while LlamaRisk authors the methodology and may hold only explicitly delegated updater permissions. LlamaRisk cannot silently replace the registered workflow or call arbitrary Aave functions.

See the Aave governance proposal for the proposed production integration and ownership model.

How the documentation is organized

Methodology explains the economic model and calculations.
System design explains the implementation architecture, CRE workflows, configuration, and update schemas.
Smart Contracts documents the on-chain interfaces, inputs, selectors, access controls, and usage examples.
Deployments lists governance-authorized production addresses, workflows, permissions, and operational references.

The reusable calculation, publication, and execution boundaries are documented separately under Architecture and safety.

User impact

Once deployed with enabled Aave agents:

changing discountRatePerYear changes the PT price reported through Aave's oracle path;
changing LTV changes maximum borrowing power in the relevant eMode;
changing liquidation threshold changes when a position becomes liquidatable; and
changing liquidation bonus changes the compensation offered to liquidators.

The system changes category-level Aave parameters, not an individual user's position. Existing users can therefore see their health factor change when a recommendation is executed.

For underlying protocol concepts, see Pendle's official documentation for Principal Tokens, the V2 AMM, and implied APY.