KVORUM
aaveSource: Aave governance v3 · #288

Risk Steward Parameter Updates Phase 3

executedApr 8, 2025, 05:37 PM UTCby570x57ab…2922

01Summary

AISummary by Kvorumclaude-haiku-4-5

This proposal updates Risk Steward parameters across multiple Aave V3 deployments to increase operational efficiency by allowing more responsive risk parameter management. Key changes include doubling the allowable adjustments for Base Variable Borrow Rate, Slope 1, and LTV/Liquidation Threshold parameters, while quadrupling the allowable adjustment for Slope 2. This reduces governance overhead by enabling the Risk Steward to handle more parameter updates without requiring full governance proposals.

Type
parameter change

Key changes

  • Base Variable Borrow Rate maximum adjustment increased from 0.5% to 1% absolute(high)
  • Slope 1 maximum adjustment increased from 0.5% to 1% absolute(high)
  • Slope 2 maximum adjustment increased from 5% to 20% absolute(high)
  • Loan to Value (LTV) maximum adjustment increased from 0.25% to 0.5% absolute(high)
  • Liquidation Threshold maximum adjustment increased from 0.25% to 0.5% absolute(high)
  • Supply & Borrow Caps, Debt Ceiling, LST Cap adapter params, Stable price cap, Optimal Point (Kink), and Liquidation Bonus remain unchanged(medium)

Notable concerns

  • The proposal significantly expands the Risk Steward's adjustment authority across multiple parameters, which could allow more rapid market-responsive changes but may reduce direct governance oversight of risk parameter modifications
ContractsAaveV3EthereumAaveV3EthereumLidoAaveV3EthereumEtherFiAaveV3PolygonAaveV3AvalancheAaveV3OptimismAaveV3ArbitrumAaveV3MetisAaveV3GnosisAaveV3BaseAaveV3ScrollAaveV3BNBAaveV3ZkSyncAaveV3LineaAaveV3CeloAaveV3Sonic
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

306 words

Simple Summary

This proposal aims to update the Risk Steward parameters to enhance the efficiency of risk parameter management and reduce governance overhead.

Motivation

The Risk Steward mechanism has proven to be an effective tool for managing risk parameters without requiring full governance proposals. After several months of successful operation, we propose updating the parameters to allow for more responsive risk management while maintaining appropriate safety constraints.

Technical service providers spend significant time reviewing risk parameter update AIPs, which could be more efficiently handled through the Risk Steward mechanism. With well-defined processes in place and months of successful operation, we can safely expand the scope of parameter adjustments allowed through this system.

Specification

ParameterCurrentProposed
Supply & Borrow Caps100% relative(no change)
Debt Ceiling20% relative(no change)
LST Cap adapter params5% relative(no change)
Stable price cap0.5% relative(no change)
Base Variable Borrow Rate0.5% absolute1% absolute
Slope 10.5% absolute1% absolute
Slope 25% absolute20% absolute
Optimal Point (Kink)3% absolute(no change)
Loan to Value (LTV)0.25% absolute0.5% absolute
Liquidation Threshold0.25% absolute0.5% absolute
Liquidation Bonus0.5% absolute(no change)

(no change to minimum delay)

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorumlow confidenceclaude-sonnet-5
Consistent

The proposal description lists specific relative/absolute risk-parameter changes (Base Variable Borrow Rate, Slope 1, Slope 2, LTV, Liquidation Threshold) across many Aave V3 markets on 16 different chains, referencing distinct payload contracts per network. However, the decoded calldata only exposes three generic execute() fallback calls, all on chain 0x1 (Ethereum), targeting what are very likely the AaveV3Ethereum, AaveV3EthereumLido, and AaveV3EthereumEtherFi payload contracts named first in the description's reference list. Because these are fallback/execute() calls with no decoded internal arguments, the actual parameter values being set (e.g., new borrow rate slopes, LTV, liquidation threshold) cannot be verified directly from the calldata provided — the real changes are encoded inside the payload contracts' bytecode, which is outside the scope of this decoded action set. This is a structural limitation of the decoding, not necessarily evidence of a mismatch: it is standard for Aave governance proposals to execute a small number of on-chain payload contracts on the primary governance chain, with cross-chain markets handled via separate bridged execution flows not necessarily captured in this three-action list. Given the opacity of the calldata (no decoded parameters to compare against the prose's numeric claims), confidence in this comparison is low. No concrete value, target, or omission discrepancy can be confirmed, so the assessment defaults to consistent, but this should not be read as a strong endorsement — it reflects insufficient decoded detail rather than confirmed alignment. A reviewer wanting certainty should inspect the actual payload contract source code linked in the proposal to confirm the numeric changes match the specification table exactly.

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

04Actions

3 total
#0fallback()chain 0x1
Target
0xc4c3…33d1
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#1fallback()chain 0x1
Target
0xb609…e410
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#2fallback()chain 0x1
Target
0x6a7b…b3df
Value
0 wei
Function
fallback()
Arguments
{}
Calldata

05Tally

Summed from votes

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

0 total
Filter:
VoterChoice% of totalRationale
570x57ab…2922For256K0.00%—2y ago
2E0x2e21…f21aFor124.3K0.00%—2y ago
EC0xecc2…6ac9For46.6K0.00%—2y ago
B90xb933…8dd1For39.7K0.00%—2y ago
3D0x3ddc…05b0For30.1K0.00%—2y ago
870x8787…ea52For24.7K0.00%—2y ago
EZezr3al.eth0x8659…7d0eFor12.4K0.00%—2y ago
8B0x8b37…2a22For10.9K0.00%—2y ago
2C0x2cc1…4df1For4.8K0.00%—2y ago
080x0865…24ceFor2K0.00%—2y ago
B30xb356…c826For4800.00%—2y ago
F10xf13c…6dd3For174.20.00%—2y ago
0B0x0ba4…2b9dFor99.90.00%—2y ago
EC0xec35…939dFor7.50.00%—2y ago
430x43dd…40e0For6.90.00%—2y ago
960x96d3…9fb1For3.50.00%—2y ago
050x0579…4048For3.10.00%—2y ago
2F0x2f2f…f78aFor20.00%—2y ago
620x6276…b4e8For10.00%—2y ago
010x019e…2ee3For0.30.00%—2y ago
090x0901…2306Against0.10.00%—2y ago
580x58f2…94ccFor00.00%—2y ago
7F0x7f21…31e0For00.00%—2y ago
200x200d…49e4For00.00%—2y ago
C40xc4cd…47bcFor00.00%—2y ago
380x38dc…472dFor00.00%—2y ago
150x1523…080fFor00.00%—2y ago
4D0x4d12…7d7cFor00.00%—2y ago
BE0xbef8…9999For00.00%—2y ago
D70xd712…1366For00.00%—2y ago
7A0x7a04…17a8For00.00%—2y ago
140x1475…6e15For00.00%—2y ago
A00xa0d0…604aFor00.00%—2y ago
A60xa6ac…2bf3For00.00%—2y ago
E60xe6b8…452dFor00.00%—2y ago
210x21ff…c5a8For00.00%—2y ago
EE0xee2a…58a7For00.00%—2y ago
D20xd248…32aeFor00.00%—2y ago
930x93e0…f6eeFor00.00%—2y ago
AC0xacc9…0b28For00.00%—2y ago
950x95d2…88f9For00.00%—2y ago
E80xe8ee…0877For00.00%—2y ago
ED0xed4c…9508For00.00%—2y ago
Showing 43

07Forum

No forum thread is confidently linked to this proposal.