Onboard PT-srUSDe-22OCT2026 to the LlamaRisk PT Risk Oracle
01Summary
Registers two predeployed risk agents on Aave's AgentHub to automatically maintain discount rate and eMode risk parameters for PT-srUSDe-22OCT2026 token on Aave V3 Ethereum, with bounds on parameter changes (100 bps for discount rate, 50 bps for eMode parameters) and timelocks (2-3 days) enforced by the agents.
- Type
- protocol addition
Key changes
- Register AaveDiscountRateAgent to automatically update discount rate for PT-srUSDe-22OCT2026 with maximum 100 bps move per injection, 2 day minimum delay and 2 day expiration period(high)
- Register AaveEModeAgent to automatically update eMode LTV, liquidation threshold, and liquidation bonus for categories 47 and 48 with maximum 50 bps move per parameter per injection, 3 day minimum delay and 3 day expiration period(high)
- Grant RISK_ADMIN role to both predeployed agents on ACL manager to enable parameter updates(high)
- Set absolute range validation bounds on RangeValidationModule for all parameters each agent can modify(high)
- Set Protocol Guardian as admin for both agents, allowing emergency disabling without governance cycle(medium)
Notable concerns
- Agents depend on LlamaRisk's offchain pipeline and Chainlink CRE infrastructure; if oracle feed fails, parameters cannot be updated automatically
- Discount rate agent has independent 100 bps step cap enforced by LlamaRisk router in addition to the 100 bps bound in this proposal
- First injection by a freshly assigned agent has no relative bounds since no prior value exists; absolute bounds in payload prevent unbounded first updates
- Agents write to separate systems: discount rate agent calls PendlePriceCapAdapter through Aave oracle, eMode agent delegatecalls config engine, requiring RISK_ADMIN role in both contexts
Generated by Kvorum
02Description
Simple Summary
Registers two predeployed risk agents on the Aave-owned AgentHub so that discount rate and eMode risk parameters for PT-srUSDe-22OCT2026 on Aave V3 Ethereum Core can be maintained automatically from the LlamaRisk PT Risk Oracle, within bounds this proposal sets.
Motivation
PT-srUSDe-22OCT2026 is a Pendle principal token listed on Ethereum Core as reserve 66 and collateral in eMode categories 47 and 48. Its fair value depends on an implied discount rate that decays to zero at maturity, so a static discount rate is wrong almost everywhere: too high early, and increasingly too low as maturity approaches. The same drift affects the liquidation threshold and bonus that should apply to it.
LlamaRisk operates an offchain pipeline on Chainlink CRE that tracks the Pendle market, maintains an EMA of the implied rate, and derives both the discount rate and the eMode parameters from it. This proposal is the last link in that chain: it grants the two agent contracts permission to apply those values, and bounds how far each application may move a parameter.
The pipeline publishes to a RiskOracle that only LlamaRisk's router can write to, and the router only accepts reports from the Chainlink CRE forwarder for a workflow owned by the Aave CRE organisation multisig. Governance retains the ability to disable either agent at any time.
Specification
The payload performs three groups of actions.
1. Register the discount rate agent. The payload registers the predeployed AaveDiscountRateAgent from MiscEthereum.LLAMARISK_PT_DISCOUNT_RATE_AGENT on MiscEthereum.AGENT_HUB, consuming PendleDiscountRateUpdate records from the LlamaRisk RiskOracle and allowed to act only on PT-srUSDe-22OCT2026. Minimum delay 2 days, expiration period 2 days.
2. Register the eMode agent. The predeployed AaveEModeAgent from MiscEthereum.LLAMARISK_PT_EMODE_AGENT is registered for the same oracle, consuming EModeCategoryUpdate and allowed to act only on eMode categories 47 and 48. Minimum delay 3 days, expiration period 3 days. Its agent context encodes AaveV3Ethereum.CONFIG_ENGINE, which it delegatecalls to apply category updates.
Both are registered with admin set to MiscEthereum.PROTOCOL_GUARDIAN, so a misbehaving agent can be disabled without a governance cycle. Registration stays governance-only: registerAgent and setAgentAdmin are onlyOwner, and the AgentHub is owned by GovernanceV3Ethereum.EXECUTOR_LVL_1. Both isAgentPermissioned and isMarketsFromAgentEnabled are left at their defaults.
Both agent addresses and the RiskOracle are imported from MiscEthereum. Neither agent is registered with a suffixed update type: the LlamaRisk RiskOracle serves this stack alone, so the base types are unambiguous.
3. Grant RISK_ADMIN and bound the ranges. addRiskAdmin on AaveV3Ethereum.ACL_MANAGER for both predeployed agents, then setDefaultRangeConfig on MiscEthereum.RANGE_VALIDATION_MODULE for each parameter each agent can move.
The role is required because of how the agents write. The discount rate agent resolves the PT price source through the Aave oracle and calls setDiscountRatePerYear on the PendlePriceCapAdapter, which gates that call on isRiskAdmin || isPoolAdmin. The eMode agent delegatecalls the config engine, and because delegatecall preserves the caller, the PoolConfigurator sees the agent rather than the engine, so the role has to sit on the agent there as well.
Bounds and timelocks
Every bound is absolute rather than relative. A relative cap is measured against the last value the agent injected, which does not exist on a freshly assigned agent id, so a relative configuration would leave the first injection unbounded. The minimum delay is the timelock the hub enforces between injections per agent and market, and the expiration period is how long a published update remains applicable.
| Agent | Parameter | Maximum move per injection | Minimum delay | Expiration period |
|---|---|---|---|---|
| Discount rate | PendleDiscountRateUpdate | 100 bps (1e16) | 2 days | 2 days |
| eMode | EModeLTV | 50 bps | 3 days | 3 days |
| eMode | EModeLiquidationThreshold | 50 bps | 3 days | 3 days |
| eMode | EModeLiquidationBonus | 50 bps | 3 days | 3 days |
These configurations are not optional. A fresh agent id inherits no default range config, and the module reads a missing config as a zero bound, which rejects every injection. Omitting them would produce a registered but permanently inert agent.
Two further limits apply outside this payload. The minimum delays above are enforced by the hub per agent and market. And the LlamaRisk router applies its own 48 hour minimum delay and 100 bps step cap to the discount rate route, so that value is bounded twice, independently.
Affected eMode categories
| Id | Label |
|---|---|
| 47 | PT-srUSDe Stablecoins |
| 48 | PT-srUSDe USDe |
No reserve configuration is changed by this payload. The snapshot diff is empty by design.
Deployed Contracts
MiscEthereum.LLAMARISK_RISK_ORACLE: 0x683d1A91599F971252Ef171eF1F987172be8369AMiscEthereum.LLAMARISK_RISK_ORACLE_ROUTER: 0x1D85000D54ea1185C43E4f2b32833524d3cF3507MiscEthereum.LLAMARISK_PT_DISCOUNT_RATE_AGENT: 0x529e2374afB38AC465D71979E7540ad93C05F6c5MiscEthereum.LLAMARISK_PT_EMODE_AGENT: 0xbe2840440d4f77CD98CEC2de09913e6851907744CHAINLINK_CRE_FORWARDER: 0x0b93082D9b3C7C97fAcd250082899BAcf3af3885
The payload references the RiskOracle and both agents directly. The Router and CRE Forwarder are included above to make the complete write path easier to review.
Existing Aave contracts referenced, all from the address book:
- AgentHub:
MiscEthereum.AGENT_HUB - RangeValidationModule:
MiscEthereum.RANGE_VALIDATION_MODULE - ACL manager:
AaveV3Ethereum.ACL_MANAGER - Config engine:
AaveV3Ethereum.CONFIG_ENGINE - Agent admin:
MiscEthereum.PROTOCOL_GUARDIAN - AgentHub owner:
GovernanceV3Ethereum.EXECUTOR_LVL_1
Agent source
Both predeployed agents are verified deployments of the stock BGD implementations from aave-dao/aave-risk-agents. The tests verify their bytecode is present and their immutable AgentHub, RangeValidationModule, pool, oracle and update-type wiring matches the configuration registered by this payload.
References
- Implementation: AaveV3Ethereum
- Tests: AaveV3Ethereum
- Agent implementations: aave-dao/aave-risk-agents
- Snapshot: Direct-to-AIP
- Discussion
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The proposal follows the standard Aave governance pattern where a single payload contract is deployed and the governance action simply calls execute() on it with no arguments; all the substantive logic (registering agents, granting RISK_ADMIN, setting range configs) is embedded in that contract's bytecode rather than passed as calldata arguments. The decoded on-chain action set contains exactly one entry — a bare execute() call — which is consistent with this pattern and does not contradict anything in the description. However, because the calldata gives no visibness into the specific parameters (agent addresses, bounds, delays, role grants) that the description claims will be executed, I cannot independently verify those details from the calldata alone. There is no evidence of a mismatch (no target_mismatch, value_mismatch, or omitted/extra action can be identified), but the ability to confirm the description's claims is limited by the single opaque execute() call. I am marking this consistent because nothing in the calldata contradicts the description, but confidence is low since verification of specific numeric bounds and addresses is not possible from the decoded action alone.'
Generated by Kvorum
04Actions
- Target
- 0x2eb2…41ba
- Value
- 0 wei
- Function
- execute()
- Arguments
{}- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
- [ARFC] Upgrade PT Risk Oracle to Protocol-Owned Infrastructure on CRE ↗discourse · high confidence
Arguments for
- The proposal transitions PT risk management from opaque offchain processes to transparent, protocol-owned infrastructure where all methodology parameters, inputs, and changes are recorded onchain and independently verifiable.— LlamaRisk, Abel189
- The implementation preserves the proven linear discount-rate model and existing Risk Agents middleware while only replacing the offchain sender, reducing implementation risk and making evaluation straightforward.— LlamaRisk, Abel189
- Aave Governance retains full ownership and control over every contract in the stack, with the risk manager only proposing changes while every parameter update and safety check flows through existing governance-owned infrastructure.— LlamaRisk
- The three new contracts (router, oracle, parameter registry) have either been previously audited as part of LlamaGuard NAV or will undergo Certora audits covering both onchain and offchain computation surfaces.— LlamaRisk
- The atomic architecture eliminates manual overhead and key-person risk by automating PT parameter updates through deterministic CRE workflows with rate limits, cooldowns, and signed reports validated onchain.— LlamaRisk
Arguments against
None surfaced.
Notable participants
- LlamaRiskProposal originator providing comprehensive technical specification, methodology documentation, and implementation details for the PT risk oracle upgrade.
- Abel189Early supporter who endorsed the proposal's transparency improvements and emphasized the importance of documentation and security reviews for future expansions.
Generated by Kvorum
08Similar proposals
- aaveexecutedDiscount Rate Risk Oracle Activation and update manual AGRS80%
- aaveexecutedAGRS (Risk Stewards) migration to Risk Agents78%
- aaveexecutedActivate Capo Risk Agent and expand Rates Agent on more networks78%
- aaveexecutedCaps Risk Oracle Activation on Arbitrum73%
- aaveexecutedAutomated (Edge) AGRS Activation73%
- aaveexecutedAave Generalized Risk Stewards (AGRS) activation73%
- aaveexecutedSlope2 Risk Oracle Activation On Core Ethereum, Linea72%
- aaveexecutedRisk Stewards Cooldown Reduction & Umbrella Pauser Role Reassignment72%
- aaveexecutedCaps Risk Oracle Activation on Base, Avalanche71%
- aaveexecutedCaps Risk Oracle Activation on Optimism, BNB, Gnosis, Polygon70%