Aave DAO voters are deciding whether to delegate limited V4 risk controls on Ethereum and Avalanche to Risk Stewards, tools that let approved operators make constrained changes without taking every update through a full governance vote. The proposal would also assign no-delay emergency roles that the current steward software cannot use.
The Snapshot vote opened Sept. 3 at 3:46 p.m. UTC and is scheduled to close today, Sept. 6, at the same time. Approval would not activate the system by itself. Aave Labs said the corresponding payloads would still need to be executed through the V4 Security Council.
The code is also not being presented as fully audited. In its governance proposal, Aave Labs said the Risk Steward contracts were undergoing a Certora audit and that the engagement was nearing finalization.
The proposal’s central tension is between authority assigned now and functionality available later. Each Risk Steward would receive Hub and Spoke risk-management roles plus Hub and Spoke emergency roles. Those four roles would have no execution delay after they are granted.
However, the release under consideration calls none of the emergency selectors, and the current steward documentation does not expose those methods. The emergency permissions would remain inert until a future release adds support. Assigning the roles now would allow that later version to respond to an emergency without waiting through another governance cycle for access.
The wider permission redesign would split each V4 instance’s Hub and Spoke configurator controls into five granular categories: two flag-control roles, a listing role, an emergency role and a risk-management role. Selectors outside those categories would remain with residual domain-admin roles. Existing domain admins would receive the new roles so their current reach is preserved.
The proposed role definitions limit the emergency category to one-way safety actions. Hub calls can deactivate or halt assets and Spokes. Spoke calls can pause or freeze individual reserves or all reserves. Those functions cannot reactivate, unhalt, unpause or unfreeze the affected market. The separate flag-control roles, which can change states in both directions, would not be granted to the Risk Stewards.
Routine parameter updates would operate under different controls. The proposal sets minimum cooldowns of 36, 48 or 72 hours, depending on the parameter, and caps how far each update may move it. The same bounds would apply on Ethereum and Avalanche and cover interest-rate settings, collateral factors, liquidation settings and oracle caps. They do not constrain the emergency selectors.
That separation explains why the plan can combine slower bounded maintenance with immediate emergency authority on paper. It also creates an accountability question because the zero-delay roles would be in place before the steward can exercise them. Forum participants asked for public rationales, post-action reports, periodic reviews and reporting on the frequency and size of steward actions. None of those measures is a requirement in the current proposal.
If the Snapshot passes and the Security Council executes the payloads, the immediate change would be no-delay access to bounded parameter controls. The one-way emergency powers would be pre-positioned for a future steward release, but they would not yet be usable.
