[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:

1. Offchain CRE. Gathers Pendle market state, reads the onchain ParameterRegistry and LlamaguardRiskOracle, runs the methodology rule, and emits one signed report.

2. Router. Validates the report's source tuple, then publishes it and triggers execution in a single atomic step.

3. Oracle and AgentHub. Stores the typed update and re-runs the existing generic safety checks for delay, expiration, replay, and range.

4. Aave-side execution. The typed agent mutates the state on the PendlePriceCapAdapter or the PoolConfigurator.

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_ema as a single number, applies the rule from the Dynamic Discount Rate section below, and publishes the result as PendleDiscountRateUpdate to the existing RiskOracle for the existing AaveDiscountRateAgent to inject into the PendlePriceCapAdapter.

• Risk-parameters workflow. Applies the rule from the Dynamic Risk Parameters section below and publishes (LT, LTV, LB) per (PT, E-Mode category) reserve as EModeCategoryUpdate to the existing RiskOracle for the existing AaveEModeAgent. 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:

• LlamaguardRiskOracle is a variant of the standard RiskOracle that accepts writes only from the router. It stores the Price EMA and Pool Proportion EMA, keyed by (updateType, market), and exposes the IRiskOracle surface, which the two primary CRE workflows use to obtain the smoothed implied rate and proportion. The router writes it from the pendle_ema_oracle workflow's signed report.

• LlamaguardRiskOracleRouter is 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 the RiskOracle, and triggers AgentHub.check / AgentHub.execute in the same transaction. It is designed to route across multiple risk oracles, such as slope2, CAPO, and future workstreams, as they come online.

• ParameterRegistry is 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.

Note: Due to the character count limitations of Snapshot, the remainder of the forum post cannot be shown, and can be found on the governance forum linked below.