KVORUM
aaveSource: Aave governance v3 · #332

Discount Rate Risk Oracle Activation and update manual AGRS

executedJun 30, 2025, 08:33 AM UTCbyF70xf71f…1e02

01Summary

AISummary by Kvorumclaude-haiku-4-5

This proposal activates automated Pendle PT discount rate updates on Ethereum core instance and upgrades the manual Aave Generalised Risk Stewards (AGRS) to its latest version across all instances, enabling automated risk parameter adjustments and constrained eMode category updates while replacing legacy steward contracts.

Type
protocol addition

Key changes

  • Activate automated AGRS for Pendle PT discount rate updates on Ethereum core instance with permissionless propagation from Edge Risk Oracle, operating via Chainlink Automation and consuming LINK from Aave Collector(high)
  • Implement maximum 1% absolute increase/decrease per 2 days constraint on Pendle PT discount rate updates for feeds: PT_sUSDE_31JUL2025, PT_USDe_31JUL2025, PT_eUSDE_14AUG2025(high)
  • Upgrade manual AGRS to latest version across all instances (Ethereum, Ethereum Lido, Polygon, Avalanche, Optimism, Arbitrum, Metis, Base, Gnosis, Scroll, BNB, ZkSync, Linea, Celo, Sonic)(high)
  • Enable constrained eMode category collateral parameter updates (LTV, LiquidationThreshold, LiquidationBonus) with specific change limits and minimum delays on new manual AGRS(high)
  • Revoke RISK_ADMIN role from previous manual AGRS, FREEZING_STEWARD, and CAPS_PLUS_RISK_STEWARD contracts while granting it to new manual AGRS(medium)
  • Set GHO asset as restricted on new manual stewards to be updated via gho stewards only(medium)

Notable concerns

  • Discount rate changes impact Pendle PT asset pricing with practical effects reducing over time to maturity (1% discount rate increase on 1-year maturity reduces price by 1%, but only 0.25% on 3-month maturity)
  • Permissionless propagation from Edge Risk Oracle relies on assumption that risk recommendations will be timed correctly
  • Upgrade affects multiple blockchain instances, increasing complexity of change management
  • GHO asset exclusion from new manual stewards requires coordination with separate gho steward system
ContractsAaveStewardInjectorDiscountRateEdgeRiskStewardDiscountRateEdgeRiskOracleACL_MANAGERRISK_STEWARDFREEZING_STEWARDCAPS_PLUS_RISK_STEWARD
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

731 words

Simple Summary

This proposal activates the automated Aave Generalised Risk Stewards (AGRS) system on the Ethereum core instance to perform automated discount rate updates on Pendle PT feeds. It also updates the manual AGRS to the most up-to-date iteration (already active on Ethereum), which allows for e-Mode category updates across all instances.

Motivation

Automated AGRS for PT discount rate Risk Oracle

Currently, the discount rate on PT feeds requires manual updates through the manual AGRS on the core instance, creating operational inefficiencies, including:

  • Additional delays in risk parameter adjustments
  • Increased workload and suboptimal response times on manual AGRS due to the high volume of risk updates

To optimize this, and following the same approach as with other risk parameters, this proposal extends the automated AGRS system using Edge Risk Oracles to update the discount rate on the Pendle PT feeds.

Manual AGRS

Following the successful activation of the new version of manual AGRS as part of Proposal 299 on the Ethereum core instance, we propose extending this same implementation to all other instances. The new version enables constrained updates to eMode category collateral parameters (LT, LTV, and LB) and allows modification of Pendle PT feed discount rates.

Specification

Automated AGRS for PT discount rate Risk Oracle

This new discount rate AGRS will mirror the same infrastructure as the currently active for other automated AGRS, but a summary of specifications is the following:

  • The AGRS will have only one configurable parameter: discount rate on pt feeds.
  • Recommendation of these parameters will be submitted to a RiskOracle smart contract, from the Edge off-chain infrastructure. Between the risk oracle smart contract and the AGRS contract, there will be a thin middleware AaveStewardInjectorDiscountRate, with the following logic:
    • Takes recommendations from the Edge Risk Oracle side and propagates them to the AGRS contract.
    • Enforce that only the whitelisted Pendle PT feeds can be acted upon.
    • Given the protections (percentage constraints and time delay) on the AGRS side and that it is an assumption that risk recommendations will be timed correctly on the Edge Risk Oracle side, the propagation will be permissionless.
  • The AaveStewardInjectorDiscountRate will be part of the Aave Robot infrastructure, running on Chainlink Automation and consuming LINK from the Aave Collector.
  • The new AGRS contract will be given RISK_ADMIN role.

The following feeds for Pendle PT assets on core instance will be automated: PT_sUSDE_31JUL2025, PT_USDe_31JUL2025, PT_eUSDE_14AUG2025.

Constraints on the discount rate update of the Pendle PT feeds will be as follow: maximum 1% absolute increase/decrease per 2 days.

The price of pendle PT asset is calculated as the following: priceOfAsset * (100% - (timeLeftForMaturity * discountRate) / 100%). What this means in practice is that, for ex. a 1% increase of the discount rate per year, the price of the PT asset would reduce by 1% if the time to reach maturity of the PT asset is 1 year. This is never the case on Aave, as maturities are shorter, so the practical impact of the change is ever lower, 0.5% if 6 months are left, 0.25% if 3 months are left, and so on.

Manual AGRS

The new manual AGRS will be activated on all instances and will be given the RISK_ADMIN role via: ACL_MANAGER.addRiskAdmin(RISK_STEWARD); and the RISK_ADMIN role of the previous manual AGRS along with other legacy contracts like FREEZING_STEWARD and CAPS_PLUS_RISK_STEWARD will be revoked.

Please note: GHO asset will be set as restricted on the new manual stewards as the asset is to be updated via the gho stewards.

The following risk configuration will be set on the new manual AGRS for all instances:

ParameterPercent change allowedminimumDelay
EMode LTV0.5% absolute change3 days
EMode LiquidationThreshold0.1% absolute change3 days
EMode LiquidationBonus0.5% absolute change3 days
Pendle PT Feed Discount Rate2.5% absolute change2 days

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorumlow confidenceclaude-sonnet-5
Consistent

The proposal description is highly detailed, specifying exact contract roles, whitelisted PT feeds, percentage constraints, and a full risk parameter table across many instances. However, the decoded on-chain actions only show two opaque calls to execute() on payload contract addresses (0x7724...332e3 and 0x5b73...8745d3), which is the standard Aave governance pattern where the real logic (role grants, steward activations, parameter configs) is encapsulated inside separate payload contracts rather than being visible in the top-level calldata. Because the decoded actions do not expose the internal instructions of these payload contracts, it is not possible to verify line-by-line whether the specific role grants, revocations, whitelisted feeds, or numeric risk parameters described in the prose exactly match what the payloads execute. No contradiction is evident from what is visible — the two calls are consistent with the proposal deploying/activating payloads for at least two instances (e.g., Ethereum core and Ethereum Lido) as referenced in the implementation links. Given the inherent opacity of the execute() fallback pattern, confidence in this comparison is low, and no specific discrepancy can be confidently flagged. This is a common and expected limitation for Aave 'payload' style proposals, not indicative of any wrongdoing in itself.

Generated by Kvorum
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Review the decoded actions ↗

04Actions

2 total
#0fallback()chain 0x1
Target
0x7724…32e3
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#1fallback()chain 0x1
Target
0x5b73…45d3
Value
0 wei
Function
fallback()
Arguments
{}
Calldata

05Tally

Summed from votes

Voters32
VP participating594.8K
Outcome (current)For
Current support100%

06Voters

32 total

No votes recorded yet.

07Forum

No forum thread is confidently linked to this proposal.