Aave governance is considering an ARFC that would turn on the Risk Steward for the protocol’s V4 deployments on Ethereum and Avalanche. The proposal would give the steward delegated but tightly limited authority to change a defined list of Hub, Spoke and Oracle risk parameters without requiring a full governance vote for every adjustment.
Under the plan, that authority would be bounded by governance-set cooldowns and maximum change limits for each update, and it could be revoked. Before activation, Aave would also narrow the underlying permission model by splitting each instance’s existing configurator domain admin roles into more granular roles so the steward only receives the risk-management and emergency functions it needs.
Why Aave wants the change
The proposal argues that V4 currently requires a full governance process whenever Hub, Spoke or Oracle settings need to be adjusted through a configurator’s domain admin role. That applies to changes ranging from interest-rate curve tuning to collateral risk updates, even when the adjustment would remain inside ranges the DAO has already discussed.
Aave points to its V3 setup as the precedent. There, the generalized Risk Steward model allows Risk Service Providers to update parameters within pre-approved bounds and cooldown periods rather than sending every change back through a fresh governance vote. The new ARFC would extend that operating pattern to Aave V4 on Ethereum and Avalanche.
How the permissions would be narrowed
To keep the delegated authority limited, the proposal first restructures configurator access on each V4 instance. Instead of relying on two broader domain admin roles, each instance would split those responsibilities into five more specific roles.
The stated aim is to isolate risk-management and emergency powers from other administrative actions. In practice, the proposal outlines separate scopes covering hub and spoke actions such as preventing activity, pausing, listing, emergency intervention, risk management and a residual admin function, with the Risk Steward only receiving the subset needed for its mandate.
Parameters and roles covered
According to the specification, the same parameter bounds would apply to both Aave V4 Ethereum and Aave V4 Avalanche. The list spans Hub, Spoke and Oracle settings, including optimalUsageRatio, baseDrawnRate, rateGrowthBeforeOptimal, rateGrowthAfterOptimal, addCap, drawCap, collateralRisk, collateralFactor, maxLiquidationBonus, targetHealthFactor, healthFactorForMaxBonus, liquidationBonusFactor, priceCapLst, priceCapStable and discountRatePendle.
Each parameter would have a defined cooldown, a maximum permitted change per update and an assigned mode. The Risk Steward on each instance would receive four new roles through the AccessManager: HUB_CONFIGURATOR_RISK_MANAGEMENT_ROLE, HUB_CONFIGURATOR_EMERGENCY_ROLE, SPOKE_CONFIGURATOR_RISK_MANAGEMENT_ROLE and SPOKE_CONFIGURATOR_EMERGENCY_ROLE. The proposal also includes RISK_ADMIN on the V3 ACLManager for effects tied to CAPO bounds.
Audit status and what comes next
The contracts proposed for this activation are being audited by Certora, and the governance post says that review is now in its final stage. The proposal does not present the activation as complete; it is still in the request-for-comment phase.
The published next steps are to collect community feedback during the ARFC, move to a Snapshot vote if sentiment is positive, and, after a positive Snapshot result, have the V4 Security Council execute the payloads needed to activate the Risk Steward on both V4 instances.
Source: governance.aave.com