Aave DAO Passes Bounded Risk Steward Plan for Aave V4

THE SHORT VERSION

An Aave governance Snapshot displayed Passed for a proposal to activate Risk Stewards for Aave V4 on Ethereum and Avalanche. The Snapshot page showed 98 votes, 372.5k For, 100% support, and zero Against or Abstain when the vote closed on September 6, 2026. That result records off-chain governance support. It does not prove that an execution payload has been reviewed, submitted, or applied on-chain. [1] [2]

The proposal describes a bounded and revocable authority model for defined Aave V4 Hub, Spoke, and selected Oracle risk parameters. It includes cooldowns, maximum-change limits, and more granular V4 configurator roles. The Aave Risk Stewards ARFC says the next step is Security Council payload review after the positive Snapshot. [1]

WHAT THE SNAPSHOT SHOWED

The Snapshot record was created on September 2, opened on September 3, and ended on September 6, 2026. Its displayed outcome was Passed. The page reported 98 votes and displayed 372.5k For, or 100%, with zero Against and zero Abstain. These are the values shown on the governance page reviewed for this draft. Vote pages and governance records can change as interfaces update, so the page itself remains the reference for the recorded result. [2]

The vote concerned the Aave Risk Stewards ARFC titled “Activate Aave Risk Stewards on Aave V4.” An ARFC is a governance forum proposal and a step in the Aave decision process. A passed Snapshot is not the same event as a successfully executed transaction. The ARFC describes later payload review and execution work, so this article uses “passed” for the vote and does not describe Risk Stewards as active. [1]

WHAT THE PROPOSED AUTHORITY COVERS

The ARFC proposes Risk Steward activation for Aave V4 on Ethereum and Avalanche. The described authority is limited to defined Hub, Spoke, and selected Oracle risk parameters. It is designed to let designated stewards make time-sensitive risk or emergency changes within boundaries approved by governance. The proposal does not give a steward unrestricted control over Aave V4. [1]

The proposal describes cooldowns that generally range from 36 to 72 hours, maximum-change limits, and revocation controls. Those controls are intended to create time for review and to constrain the size and speed of parameter changes. Exact parameters remain tied to the proposal and any final execution payload, rather than to this summary. [1]

The ARFC also describes a more granular split of V4 configurator administrator roles. The role design separates responsibilities across parts of the V4 configuration system, including Hub and Spoke risk settings and selected Oracle parameters. The practical effect depends on the final role assignments and payloads that are reviewed and executed. [1] [3]

WHY THE BOUNDARIES MATTER

Aave V4 documentation describes a system organized around Hubs and Spokes. The governance proposal places the Risk Steward authority inside that configuration model instead of treating it as a general administrative key. That distinction matters because the Snapshot approves a policy and authority design, while the deployed contracts and their role assignments determine what is actually possible. [1] [3]

Cooldowns and maximum changes are governance safeguards described by the ARFC. They should be read as proposed operational constraints until the relevant payloads and contract state can be verified. The proposal also describes defined risk and emergency roles for each Risk Steward. The presence of a role in the proposal does not establish that the role has been granted on-chain. [1]

The ARFC says a Certora audit was nearing finalization at the time of the proposal. That statement belongs to the proposal record. It is not independent confirmation that the audit was complete, that all findings were resolved, or that execution was safe. Those questions require the final audit record and the executed payloads. [1]

CONTEXT AND NEXT GOVERNANCE STEP

The Snapshot was used to measure Aave community support for the Risk Steward activation plan. The forum ARFC then describes the Security Council payload review as the next step after a positive vote. A payload review can confirm what will be executed, which contracts and networks are involved, and whether the implementation matches the approved scope. [1] [2]

Aave V4 documentation provides technical context for Hubs, Spokes, and the V4 architecture, but documentation does not act as an execution record. The sources reviewed for this draft do not establish a completed on-chain transaction for the proposed Risk Steward activation. The careful status is therefore: the Snapshot passed, and the implementation remained subject to the next governance and execution steps. [1] [3]

WHAT REMAINS UNKNOWN

The sources reviewed do not confirm an on-chain execution record, the final payload contents, the final Risk Steward addresses, or the current role assignments on Ethereum and Avalanche. They also do not establish that every described emergency selector is active. A selector described in a governance proposal may remain inert until a reviewed and executed configuration enables it. [1]

The Snapshot outcome does not independently verify the Certora audit status, the state of each V4 Hub or Spoke, or the exact cooldown and maximum-change values that would be live after execution. Those details should be checked against the final payload review, deployed contract state, and current Aave documentation.

This report does not infer that the vote guarantees a security outcome, changes user returns, or changes the risk of any supplied or borrowed asset. A governance approval can authorize a process without establishing its final operational result.

WHAT READERS SHOULD WATCH NEXT

Watch the Aave governance forum for the Security Council payload review and any revised implementation details. Look for transaction hashes or other official execution records on the relevant networks before treating Risk Stewards as active. Compare the final roles, cooldowns, maximum changes, Hub and Spoke parameters, and selected Oracle controls with the approved ARFC. [1]

Watch Aave’s V4 documentation for updates that distinguish an architectural description from a deployed configuration. Also watch for a completed Certora audit record and any published response to findings. Until those records are available, the verified event is a passed Snapshot, not confirmed execution. [3]

SOURCES AND DISCLOSURES

[1] Aave governance forum, “ARFC: Activate Aave Risk Stewards on Aave V4,” including the proposed networks, bounded authority, cooldowns, role design, audit note, and Security Council next step:
https://governance.aave.com/t/arfc-activate-aave-risk-stewards-on-aave-v4/25510

[2] Aave DAO Snapshot proposal, created September 2, opened September 3, and ended September 6, 2026, displaying Passed with 98 votes and 372.5k For:
https://snapshot.org/#/s:aavedao.eth/proposal/0xf736fa5f6dd1532d0e2825fe528262479949a923427989384e313490ca9d9f18

[3] Aave V4 documentation, including the Hubs, Spokes, and V4 system context:
https://aave.com/docs/aave-v4

Disclosure: This is a sourced report on Aave governance materials, not financial advice and not a recommendation to lend, borrow, buy, sell, or hold any asset. A passed Snapshot is not proof of on-chain execution. Audit status, role assignments, payload contents, and deployed parameters require separate verification. No paid placement, sponsorship, or affiliate relationship with Aave, Aave DAO, Certora, or the cited sources was used. The featured illustration was generated for CryptoWorkPro and is not a documentary image of an Aave governance event or a copy of project artwork.