Aave Generalized Risk Stewards (AGRS) activation
01Summary
Activating Aave Generalized Risk Stewards (AGRS) Phase 2 to streamline risk parameter management across 12 networks. Manual AGRS deploys constrained risk admin contracts controlled by a 2-of-2 multisig (Chaos Labs and BGD Labs) to make incremental risk updates without full governance. Automated AGRS pilot will follow later. GHO parameters on Arbitrum and Ethereum remain excluded and managed by GhoStewards. All changes include 3-day minimum delays and specific parameter constraints.
- Type
- governance change
Key changes
- Deploy Manual AGRS contracts with RISK_ADMIN role across 12 networks (Ethereum, Ethereum Lido, Ethereum EtherFi, Arbitrum, Optimism, Polygon, Avalanche, Scroll, Metis, Base, BNB, Gnosis, ZkSync)(high)
- Manual AGRS controlled by 2-of-2 multisig with Chaos Labs and BGD Labs as signers(high)
- Enable constrained risk parameter updates with specific change limits and 3-day minimum delay across all parameters(high)
- Restrict GHO parameter changes on Arbitrum and Ethereum, keeping those managed by GhoStewards instead(medium)
- Plan to remove RISK_ADMIN role from old CapsPlusRiskSteward once migration is complete(medium)
- Automated AGRS pilot version deferred to later activation stage(medium)
Notable concerns
- Risk steward authority allows parameter changes without full governance vote, relying on risk provider expertise and historical voting unanimity
- GHO parameters intentionally excluded from Manual AGRS scope to prevent conflicts with GhoStewards
- Temporary inclusion of BGD Labs in multisig as extra security procedure
- Voter fatigue across expanding network deployments addressed by reducing governance overhead for non-controversial incremental risk updates
Generated by Kvorum
02Description
Simple Summary
Expanding from the scope of CapsPlusRiskSteward, we now introduce the new Aave Generalized Risk Stewards (AGRS), allowing hardly constrained risk parameter updates by risk service providers and reducing governance overhead.
Aave Generalized Risk Stewards (AGRS) include two instances: Manual AGRS and Automated AGRS. Manual AGRS is a continuation of the previous design, with the parameters recommendation risk provider, with constrained capacity to modify all types of risk parameters on Aave. Automated AGRS is a pilot version to automate interest rate updates of assets (starting with WETH on Aave v3 Lido Ethereum), based on the newly released risk infrastructure technology Edge, by Chaos Labs.
This AIP activates the Manual AGRS and the Automated AGRS will be activated at a later stage.
Motivation
Aave's decentralized governance system, while robust, creates significant operational overhead and cost due to its comprehensive proposal process. This process includes pre-AIP procedures, payload creation, multiple reviews, voting, and on-chain verification. While recent improvements have optimized some steps, further efficiency gains are possible, particularly in risk-related proposals.
The rationale for reducing risk-related proposals:
- Two experts, and independent risk teams (ChaosLabs, LlamaRisk) are engaged with the DAO.
- Historical voting unanimity on non-controversial, incremental risk proposals.
- Technical feasibility of constraining updates using Aave v3 roles and specific validations.
The success of the CapsPlusRiskStewards experiment demonstrates the viability of expanding this approach. As Aave expands to new networks, minimizing governance proposals becomes crucial to prevent voter fatigue.
Specification
The new Manual AGRS we propose follows the same design as the CapsPlusRiskSteward, a smart contract to which the Aave Governance gives RISK_ADMIN role over all v3 instances, controlled by a 2-of-2 multisig, and heavily constrained on what can do and how by its own logic.
The 2-of-2 multisig controlling the Manual AGRS will have Chaos and BGD Labs as signers, temporarily including BGD Labs as a matter of extra security procedure.
ACL_MANAGER.addRiskAdmin() is called to add the new Manual AGRS.
Additionally, params for GHO on Arbitrum and Ethereum cannot be changed by this Manual AGRS, as the params will be updated by the GhoStewards instead, this is done by setting the GHO asset as restricted via the following method: RISK_STEWARD.setAddressRestricted();
To give some extra buffer and protection, we will remove the RISK_ADMIN role from the old CapsPlusRiskSteward once risk providers have adapted to use the new Risk Stewards.
Deployed AGRS Contracts:
The new risk stewards have been configured with the following risk params on all Aave instances:
| Parameter | Percent change allowed | minimumDelay |
|---|---|---|
| Supply and Borrow Caps | 100% (relative change) | 3 days |
| Debt Ceiling | 20% (relative change) | 3 days |
| LST Cap adapter params | 5% (relative change) | 3 days |
| Stable price cap | 0.5% (relative change) | 3 days |
| Base Variable Borrow Rate | 0.5% (absolute change) | 3 days |
| Slope 1 | 0.5% (absolute change) | 3 days |
| Slope 2 | 5% (absolute change) | 3 days |
| Optimal Point (Kink) | 3% (absolute change) | 3 days |
| Loan to Value (LTV) | 0.25% (absolute change) | 3 days |
| Liquidation Threshold | 0.25% (absolute change) | 3 days |
| Liquidation Bonus | 0.5% (absolute change) | 3 days |
References
- Implementation: AaveV3Ethereum, AaveV3EthereumLido, AaveV3EthereumEtherFi, AaveV3Polygon, AaveV3Avalanche, AaveV3Optimism, AaveV3Arbitrum, AaveV3Metis, AaveV3Base, AaveV3Gnosis, AaveV3Scroll, AaveV3BNB, AaveV3ZkSync
- Tests: AaveV3Ethereum, AaveV3EthereumLido, AaveV3EthereumEtherFi, AaveV3Polygon, AaveV3Avalanche, AaveV3Optimism, AaveV3Arbitrum, AaveV3Metis, AaveV3Base, AaveV3Gnosis, AaveV3Scroll, AaveV3BNB, AaveV3ZkSync
- Discussion
- Snapshot
- Github Repo: Aave V3 Risk Stewards
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
Couldn’t generate a summary for this proposal. Review the decoded actions →
04Actions
- Target
- 0xd38e…fbef
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0x0e17…0f0d
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0xdd47…2606
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
No forum thread is confidently linked to this proposal.
08Similar proposals
No semantically similar proposals found yet.