Aave’s PT Risk Oracle stack has been deployed on Aave V3 Plasma for PT-sUSDe-22OCT2026, extending the same setup that was previously activated on Ethereum Core. The Plasma deployment covers E-Mode categories 25 and 26 and uses source-verified contracts described as byte-equivalent to the Certora-audited Ethereum version.
The rollout is not fully live yet. While the EMA oracle route can begin operating without further governance action, the discount-rate and E-Mode agent paths will remain inactive until a forthcoming Aave Improvement Proposal registers the predeployed agents and grants them the required permissions.
What has been deployed on Plasma
The deployment on chainId 9745 includes the RiskOracle, PTParameterRegistry, LlamaguardRiskOracleRouter, the EMA-based LlamaGuardOracle, and two agent contracts: AaveDiscountRateAgent and AaveEModeAgent. According to the proposal, both agents are ownerless at deployment and cannot act until governance registers them on the AgentHub.
The post says the contracts mirror the Ethereum Core design. Operational control is split so that the LlamaRisk safe handles the active operating surface, while the PTParameterRegistry is owned from construction by the Aave Plasma Executor. The final step that activates the agents, however, is explicitly reserved for governance through an AIP that is expected shortly.
How the Chainlink CRE workflows are structured
The system relies on three Chainlink CRE workflows owned by the Aave CRE organisation multisig. Each workflow is pinned as the only accepted author for its route in the Router. One route publishes an hourly EMA of the Pendle implied rate, while two additional routes publish discount-rate and E-Mode risk-parameter updates every four hours for categories 25 and 26.
Only the EMA workflow can start writing immediately because it feeds its own oracle path. The two workflows tied to the agent contracts stay dormant until the governance payload executes, meaning no discount-rate or E-Mode adjustments can be made before that step is approved onchain.
What the upcoming AIP is expected to change
The proposal says the AIP will register the two already deployed agents on the Aave-owned AgentHub, assign them the RISK_ADMIN role, and define hard bounds on how far each update can move key parameters. For the discount-rate agent, the cap is 100 basis points per injection, with a two-day minimum delay and expiry. For the E-Mode agent, the cap is 50 basis points per injection on loan-to-value, liquidation threshold and liquidation bonus, with three-day delays and expiry.
The Router adds another control on top of that framework. It independently enforces a 48-hour minimum delay on the discount route, meaning that route is rate-limited twice. The proposal also states that the payload does not alter any reserve configuration.
Control model and audit status
The governance post emphasizes that agent registration is owner-gated on the AgentHub and that the owner is the Aave Plasma Executor. In practice, that means no new agent can be added or repointed without a governance vote. The Protocol Guardian is set as admin for each agent and can disable a problematic agent without waiting for a full governance cycle, while re-enabling still requires a vote. The Guardian can also pause the Router, but only the owner can unpause it.
On the publishing side, the path is intentionally one-way. The RiskOracle accepts writes only from the Router, and the Router accepts only reports sent through the Chainlink forwarder for a workflow whose owner and name match a registered route. The Router and RiskOracle are owned by the LlamaRisk operations safe, while the PTParameterRegistry is owned by the Plasma Executor with the safe acting as updater. The post adds that no individual at LlamaRisk holds governance-level permissions.
As for code assurance, the Router, RiskOracle, parameter registry and EMA oracle are described as byte-equivalent deployments of the Certora-audited LlamaGuard periphery already used on Ethereum Core. The two agent contracts come from the DAO-owned aave-risk-agents repository and were audited by Certora. The E-Mode agent is built from the current head, which the proposal says includes the fix that preserves the E-Mode isolation flag introduced with Aave 3.7.
Next confirmed step
The immediate next step is the promised AIP. Until that vote is proposed and executed, the EMA oracle can operate, but the discount-rate and E-Mode routes remain inactive because their agents are not yet registered and do not hold RISK_ADMIN permissions.
The governance post also notes that a permissions-book update reflecting these assignments has been opened for review, signaling that the focus now shifts from deployment to formal governance approval and activation.
Source: governance.aave.com