Summary
This proposal seeks to activate the Aave Risk Steward on the Aave V4 Ethereum and Aave V4 Avalanche instances. If adopted, it would grant the Risk Steward bounded, revocable delegated authority to adjust a defined set of Hub, Spoke, and Oracle risk parameters within fixed cooldowns and a maximum change allowed per update. To keep that authority narrow, each instance’s two configurator domain admin roles would first be split into five granular roles apiece, so the Risk Steward would receive only the risk management and emergency capabilities it needs. The Risk Steward contracts proposed for this activation are undergoing audit by Certora, with the engagement now reaching finalization.
Motivation
Today, adjusting any Hub, Spoke, or Oracle parameter, from interest rate curve tuning to collateral risk updates, requires a full governance cycle through the domain admin role on each instance’s configurator, even when the change would fall within a range the DAO has already discussed. The Aave Risk Steward pattern already reduces this governance overhead on Aave V3 through the Aave Generalized Risk Stewards, where Risk Service Providers update parameters within bounds and cooldowns set by governance instead of returning to a vote for every adjustment. This proposal would extend the same pattern to Aave V4, activating the Aave Risk Stewards on the Ethereum and Avalanche instances with the bounds proposed below for Hub, Spoke, and Oracle parameters.
Specification
Configurator role split
The proposed scope of each new role is as follows.
| Concern | Hub role | Spoke role | Scope |
|---|---|---|---|
| Prevent all activity | HUB_CONFIGURATOR_SPOKE_ACTIVE_ROLE (201) |
SPOKE_CONFIGURATOR_PAUSE_ROLE (401) |
Flips the flag that prevents all activity, in both directions. updateSpokeActive on the Hub, updatePaused on the Spoke. |
| Prevent new activity | HUB_CONFIGURATOR_SPOKE_HALTED_ROLE (202) |
SPOKE_CONFIGURATOR_FREEZE_ROLE (402) |
Flips the flag that prevents new activity, in both directions. updateSpokeHalted on the Hub, updateFrozen on the Spoke. |
| Listing | HUB_CONFIGURATOR_LISTING_ROLE (203) |
SPOKE_CONFIGURATOR_LISTING_ROLE (403) |
addAsset, addAssetWithDecimals, addSpoke, addSpokeToAssets on the Hub. addReserve, updateBorrowable, updateReceiveSharesEnabled on the Spoke. |
| Emergency | HUB_CONFIGURATOR_EMERGENCY_ROLE (204) |
SPOKE_CONFIGURATOR_EMERGENCY_ROLE (404) |
The batch flag actions that only ever move toward a safer state. deactivateAsset, haltAsset, deactivateSpoke, haltSpoke on the Hub. pauseReserve, pauseAllReserves, freezeReserve, freezeAllReserves on the Spoke. |
| Risk management | HUB_CONFIGURATOR_RISK_MANAGEMENT_ROLE (205) |
SPOKE_CONFIGURATOR_RISK_MANAGEMENT_ROLE (405) |
updateSpokeAddCap, updateSpokeDrawCap, updateSpokeCaps, updateSpokeRiskPremiumThreshold, updateInterestRateData on the Hub. updateCollateralRisk, addCollateralFactor, updateCollateralFactor, addMaxLiquidationBonus, updateMaxLiquidationBonus, addLiquidationFee, updateLiquidationFee, addDynamicReserveConfig, updateDynamicReserveConfig, updateLiquidationTargetHealthFactor, updateHealthFactorForMaxBonus, updateLiquidationBonusFactor, updateLiquidationConfig on the Spoke. |
| Residual domain admin | HUB_CONFIGURATOR_DOMAIN_ADMIN_ROLE (200) |
SPOKE_CONFIGURATOR_DOMAIN_ADMIN_ROLE (400) |
updateLiquidityFee, updateFeeReceiver, updateFeeConfig, updateInterestRateStrategy, updateReinvestmentController, resetAssetCaps, resetSpokeCaps on the Hub. updateReservePriceSource, updatePositionManager on the Spoke. |
The two flag roles would be named after the flag they own rather than after pause and freeze, because the Hub carries no paused or frozen flag of its own. Its equivalent state is the Spoke active flag, tracked per asset, which gates every Hub action, and the halted flag, which gates the actions that instantly update liquidity. The emergency role is proposed as separate from both because every one of its selectors only ever moves a target to a safer state and can never move it back, so it could be delegated to an entity that can act faster than the two flag roles, which move state in either direction. The Hub’s batch cap resets are proposed to stay with the domain admin role: zeroing caps moves in only one direction, the same as a halt, but only risk management could restore them, so restoring capped values would remain a governance action.
Role IDs and selector sets would match Roles.sol in the Aave V4 repository, following the convention of appending new IDs while the domain admin role’s selector set shrinks. Existing IDs would never be repurposed, so the two domain admin roles would retain the selectors that fall outside the five new roles, and every address holding a domain admin role today would be granted the corresponding five new roles, preserving its current reach.
Risk Steward parameter bounds
For each parameter, the cooldown would set the minimum time between successive Risk Steward updates, the maximum change per update would cap how far a single update can move the parameter, and the mode would determine whether that maximum applies as an absolute change or one relative to the parameter’s current value. The same bounds are proposed for both the Aave V4 Ethereum and Aave V4 Avalanche instances.
| Scope | Parameter | Cooldown | Max change per update | Mode |
|---|---|---|---|---|
| Hub | optimalUsageRatio |
36 hours | 3% | absolute |
| Hub | baseDrawnRate |
36 hours | 3% | absolute |
| Hub | rateGrowthBeforeOptimal |
36 hours | 3% | absolute |
| Hub | rateGrowthAfterOptimal |
36 hours | 20% | absolute |
| Hub | addCap |
36 hours | 100% | relative |
| Hub | drawCap |
36 hours | 100% | relative |
| Spoke | collateralRisk |
36 hours | 300% | absolute |
| Spoke | collateralFactor (update) |
72 hours | 0.5% | absolute |
| Spoke | maxLiquidationBonus (update) |
72 hours | 0.5% | absolute |
| Spoke | collateralFactor (addition) |
72 hours | 5% | absolute |
| Spoke | maxLiquidationBonus (addition) |
72 hours | 0.5% | absolute |
| Spoke | targetHealthFactor |
72 hours | 5% | relative |
| Spoke | healthFactorForMaxBonus |
72 hours | 5% | relative |
| Spoke | liquidationBonusFactor |
72 hours | 5% | absolute |
| Oracle | priceCapLst |
72 hours | 5% | relative |
| Oracle | priceCapStable |
72 hours | 0.5% | relative |
| Oracle | discountRatePendle |
48 hours | 0.025 | absolute |
Risk Steward grants
It is proposed that each Risk Steward be granted four of the new roles on its instance’s AccessManager, with no execution delay: HUB_CONFIGURATOR_RISK_MANAGEMENT_ROLE, HUB_CONFIGURATOR_EMERGENCY_ROLE, SPOKE_CONFIGURATOR_RISK_MANAGEMENT_ROLE, and SPOKE_CONFIGURATOR_EMERGENCY_ROLE. The two risk management roles are what the bounds above would require: without them the Risk Steward could not reach either configurator. The two emergency roles are proposed alongside so that a future Risk Steward release could respond to an emergency without a further governance cycle; the release proposed here calls none of their selectors, so they would remain inert until then.
It is further proposed that each Risk Steward be granted RISK_ADMIN on its instance’s Aave V3 ACLManager, needed for the priceCapLst, priceCapStable, and discountRatePendle bounds above to take effect through the shared CAPO adapters.
Disclaimer
Aave Labs is presenting this proposal as a contributor to the Aave ecosystem. Aave Labs is putting forward this proposal as part of its ongoing work on the Aave Protocol’s risk management infrastructure and has no undisclosed financial interest in its outcome.
Next Steps
- Gather community feedback during the ARFC stage.
- If the ARFC response is positive, escalate to Snapshot for off-chain confirmation.
- Following a positive Snapshot outcome, execute the corresponding payloads through the V4 Security Council to activate the Risk Steward on the Aave V4 Ethereum and Aave V4 Avalanche instances.
Copyright
Copyright and related rights waived via CC0.