Aave seeks Emergency Guardian signer rotation with unchanged 5-of-9 governance setup

Why Aave wants to rotate the signer set

According to the proposal, the current Governance Emergency Guardian signers were ratified in 2024, and Aave DAO’s stakeholder landscape has changed since then. Aave Labs argues that this makes it appropriate to refresh the composition so the Guardian remains operationally resilient and able to assemble quorum when needed.

The document describes the Governance Emergency Guardian as an essential final safeguard in Aave’s governance process. Because the governance contracts cannot independently judge the semantic intent or safety of a proposal, the Guardian is meant to serve as a last line of defense if a harmful proposal reaches the system and its creator does not cancel it voluntarily.

While the role is used infrequently and is under less time pressure than the Protocol Emergency Guardian, the proposal says signers still need to be reachable and available across the governance lifecycle. The stated goals include maintaining a reliable quorum, improving operational resilience, preserving separation from protocol-emergency responsibilities, and reducing risks tied to public attribution of individual signers.

What would and would not change

The ARFC says the Governance Emergency Guardian would keep its current 5-of-9 configuration. It also would retain the existing Governance Emergency Guardian Safe addresses, the governance and PayloadsController permissions assigned to those Safes, and the existing conditions and processes for using cancellation powers.

In practical terms, implementation is expected to be limited to rotating ownership on each Governance Emergency Guardian Safe. Aave Labs said a chain-by-chain execution manifest should be published before implementation so each deployed Safe can be updated and later verified.

The proposal also states that it does not expand or otherwise modify the authority of the Governance Emergency Guardian. If a technical review later finds that any Safe address or assigned permission must change, those changes would need to go through an Aave Improvement Proposal rather than this process.

Signer privacy and security requirements

Aave Labs said it is following the same general approach used in the Protocol Emergency Guardian rotation by identifying signers only through their onchain addresses. The proposal argues that publicly attributing individuals to the role can create avoidable risks, including phishing, social engineering, coercion, and efforts to compromise devices or communication channels.

The addresses themselves must remain public onchain, and the document notes that some retained addresses may already have historical public attribution. Even so, the proposal says it does not provide or expand formal attribution for the proposed signer set.

Before implementation, each signer is expected to confirm compliance with operational security standards for the role. Those standards include using a hardware wallet or an equivalently secure setup, verifying signing requests through out-of-band communication, independently checking every transaction before signing, and maintaining continued access to the designated account throughout the signer’s tenure.

Proposed roster and next steps

The specification lists nine proposed signing addresses for the refreshed Governance Emergency Guardian roster: 0x61C2dAE896f93e5f0f10425914CE7868eE8A0e44, 0x2694B8A8490f10f98Da6F83d18267Eae9412CbF1, 0x1e3804357eD445251FfECbb6e40107bf03888885, 0xb291232F480F41c75802C4a60F1D2AC03404Afef, 0xDA5Ae43e179987a66B9831F92223567e1F38BE7D, 0x985F3290d7971a840152E46d00b5ceb60A56f235, 0x9EF7c9A17c5881d54A4694785637acD93E790403, 0x4f96743057482a2E10253AFDacDA3fd9CF2C1DC9, and 0xA3103D0ED00d24795Faa2d641ACf6A320EeD7396.

The process from here is staged. First, Aave will gather community feedback. If sentiment is favorable, the proposal would move to an ARFC Snapshot vote. If that vote returns a YAE outcome, the next confirmed steps are to verify that all proposed signers are operationally ready, publish the full chain-by-chain execution manifest, carry out the signer rotations, and verify the resulting owner set on every deployment before updating documentation.