# \[ARFC\] Activate Aave Risk Stewards on Aave V4 **URL:** \ **Category:** Governance\ **Created:** [August 20, 2026, 5:28pm UTC](https://governance.aave.com/t/arfc-activate-aave-risk-stewards-on-aave-v4/25510 "2026-08-20T17:28:35Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![AaveLabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/aavelabs/32/6388_2.png) [@AaveLabs](https://governance.aave.com/u/AaveLabs)\ **Post date:** [August 20, 2026, 5:28pm UTC](https://governance.aave.com/t/arfc-activate-aave-risk-stewards-on-aave-v4/25510/1 "2026-08-20T17:28:35Z")
![image](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/f/f5599ba300bf4d8c01ad7a54529f5884a0c81cc3.webp) ## 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 1. Gather community feedback during the ARFC stage. 2. If the ARFC response is positive, escalate to Snapshot for off-chain confirmation. 3. 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](https://creativecommons.org/publicdomain/zero/1.0/). ---
**Author:** ![AaveLabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/aavelabs/32/6388_2.png) [@AaveLabs](https://governance.aave.com/u/AaveLabs)\ **Post date:** [September 2, 2026, 3:49pm UTC](https://governance.aave.com/t/arfc-activate-aave-risk-stewards-on-aave-v4/25510/2 "2026-09-02T15:49:43Z")
The ARFC to Activate Aave Risk Stewards on Aave V4 has been raised to snapshot. Voting will begin in less than 24 hours. You may vote [here](https://snapshot.org/#/s:aavedao.eth/proposal/0xf736fa5f6dd1532d0e2825fe528262479949a923427989384e313490ca9d9f18) ---
**Author:** ![MconnectDAO](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/mconnectdao/32/14398_2.png) [@MconnectDAO](https://governance.aave.com/u/MconnectDAO)\ **Post date:** [September 3, 2026, 5:46am UTC](https://governance.aave.com/t/arfc-activate-aave-risk-stewards-on-aave-v4/25510/4 "2026-09-03T05:46:48Z")
I support the need for faster risk management, especially during market stress. However, I have one governance concern. As Risk Stewards can analyse risk, recommend parameter changes, and execute bounded updates, how will Aave ensure that community discussion remains meaningful and not only a formal approval process? Could the DAO require public rationale for every material Risk Steward action, including the data used, expected impact, alternative options considered, and a post action report? It may also help to define periodic community review and mandate renewal, so delegated authority remains accountable to governance. ---
**Author:** ![Abel189](https://avatars.discourse-cdn.com/v4/letter/a/c67d28/32.png) [@Abel189](https://governance.aave.com/u/Abel189)\ **Post date:** [September 4, 2026, 6:00am UTC](https://governance.aave.com/t/arfc-activate-aave-risk-stewards-on-aave-v4/25510/5 "2026-09-04T06:00:42Z")
The bounded approach looks reasonable, particularly with separate risk-management and emergency roles. It would be useful to provide periodic reporting on Risk Steward parameter changes, including the magnitude and frequency of updates relative to the governance-defined bounds, so the DAO can assess how the delegated authority is being used in practice. ---
**Author:** ![Roch33](https://avatars.discourse-cdn.com/v4/letter/r/e68b1a/32.png) [@Roch33](https://governance.aave.com/u/Roch33)\ **Post date:** [September 11, 2026, 2:24am UTC](https://governance.aave.com/t/arfc-activate-aave-risk-stewards-on-aave-v4/25510/6 "2026-09-11T02:24:37Z")
Building on the points raised by @MconnectDAO and @Abel189, it may be useful to translate these transparency requirements into a simple reporting template that Risk Stewards could use consistently. For each material action, the public record could include: Action ID and date Parameter changed Previous value and new value Governance-approved bound Data source used Rationale for the change Alternative options considered Expected impact Observed outcome after a defined review period A periodic summary could then aggregate: Number of actions Magnitude of changes Frequency of changes Proximity to governance-approved bounds Actions requiring follow-up Any action that should be brought back to governance for broader review This would give the DAO a consistent audit trail without adding friction to time-sensitive risk management. It would also make future reviews of the Risk Steward mandate easier, because governance would be assessing a documented operating history rather than isolated parameter changes. ---
**Author:** ![Abel189](https://avatars.discourse-cdn.com/v4/letter/a/c67d28/32.png) [@Abel189](https://governance.aave.com/u/Abel189)\ **Post date:** [September 11, 2026, 6:26am UTC](https://governance.aave.com/t/arfc-activate-aave-risk-stewards-on-aave-v4/25510/7 "2026-09-11T06:26:03Z")
Thanks Roch33. I agree that a consistent reporting template would make the Risk Steward activity much easier for the DAO to monitor and review over time. In particular, tracking changes against the approved bounds and their observed outcomes should provide useful context for future mandate reviews. ---
**Author:** ![AaveLabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/aavelabs/32/6388_2.png) [@AaveLabs](https://governance.aave.com/u/AaveLabs)\ **Post date:** [September 25, 2026, 10:08am UTC](https://governance.aave.com/t/arfc-activate-aave-risk-stewards-on-aave-v4/25510/8 "2026-09-25T10:08:47Z")
The AIP for this proposal was successfully created, [proposal#523](https://app.aave.com/governance/v3/proposal/?proposalId=523), voting will start in less than 24hs. ---
**Author:** ![AaveLabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/aavelabs/32/6388_2.png) [@AaveLabs](https://governance.aave.com/u/AaveLabs)\ **Post date:** [September 30, 2026, 4:26pm UTC](https://governance.aave.com/t/arfc-activate-aave-risk-stewards-on-aave-v4/25510/9 "2026-09-30T16:26:07Z")
The Aave V4 Risk Stewards are now active across Ethereum, Avalanche, and Base after [AIP 523](https://app.aave.com/governance/v3/proposal/?proposalId=523) execution. This activation enables Risk Service Providers to execute bounded risk parameter updates within the limits and cooldowns approved by governance, supporting more responsive risk management while preserving DAO oversight.