Aave proposal would activate Risk Stewards on V4 Ethereum and Avalanche

Why Aave wants the change

According to the proposal, any adjustment to Hub, Spoke or Oracle settings on Aave V4 currently has to go through the full governance process via the domain admin role on each instance’s configurator. That applies even when the change is small and falls within a range the DAO has already debated.

The authors present the Risk Steward model as a way to reduce that operational burden. On Aave V3, the same general approach is already used through Aave Generalized Risk Stewards, allowing risk service providers to make bounded updates inside limits and cooldowns set by governance instead of returning for a vote each time.

How the permissions would be narrowed

To keep the delegation limited, the proposal first calls for splitting each V4 instance’s two configurator domain admin roles into five narrower roles. The new structure would separate functions tied to risk management, emergency action and other permissions, rather than leaving them bundled under broader admin authority.

The proposal says role names would follow the flags they control instead of using pause or freeze terminology, matching the Hub design where asset-level state controls specific actions. After that split, each Risk Steward would be assigned four of the new roles on the instance’s AccessManager, with no execution delay: the Hub and Spoke risk-management roles and the Hub and Spoke emergency roles. In addition, each steward would receive RISK_ADMIN on the relevant Aave V3 ACLManager for CAPO adapters so bounds can be enforced.

Parameter limits for Ethereum and Avalanche

The activation would cover the Aave V4 Ethereum and Aave V4 Avalanche instances with the same parameter framework described in the proposal. For Hub settings, the proposed limits include 36-hour cooldowns for changes to optimalUsageRatio, baseDrawnRate and rateGrowthBeforeOptimal, each capped at 3% on an absolute basis, while rateGrowthAfterOptimal would be capped at 20% absolute. The addCap and drawCap parameters would also use 36-hour cooldowns, with a maximum 100% relative change per update.

For Spoke parameters, the proposal sets a 36-hour cooldown and 300% absolute maximum change for collateralRisk. Several other Spoke adjustments would use 72-hour cooldowns, including collateralFactor updates capped at 0.5% absolute, maxLiquidationBonus updates capped at 0.5% absolute, collateralFactor additions capped at 5% absolute, and maxLiquidationBonus additions capped at 0.5% absolute. The targetHealthFactor and healthFactorForMaxBonus limits would be 5% on a relative basis, while liquidationBonusFactor would be capped at 5% absolute.

Oracle parameter changes would also be bounded. The proposal lists a 72-hour cooldown with a 5% relative maximum change for priceCapLst, a 72-hour cooldown with a 0.5% relative cap for priceCapStable, and a 48-hour cooldown with a 0.025 absolute cap for discountRatePendle.

Audit status and what comes next

The steward contracts proposed for activation are being audited by Certora, with the proposal describing that engagement as reaching finalization. The current discussion is at the ARFC stage, where community feedback is being gathered before any escalation.

If the response is positive, the next step would be a Snapshot vote for off-chain confirmation. A positive Snapshot outcome would then be followed by execution through the V4 Security Council to activate the Risk Steward on both Aave V4 instances.