[ARFC] Aave Governance Emergency Guardian: Signer Rotation

Governance
1

Summary

This ARFC proposes updating the signer composition of the Aave Governance Emergency Guardian.

The Governance Emergency Guardian will retain its existing 5-of-9 threshold, permissions, and Safe addresses. Only the underlying signer set will change.

The updated roster consists of active and stakeholders with a strong security posture capable of maintaining the operational readiness required by the role. Signer identities will not be formally attributed in public documentation. Only the signing addresses will be disclosed.

Motivation

The current Governance Emergency Guardian signer set was ratified in 2024. Since then, the Aave DAO’s stakeholder landscape has evolved, making it appropriate to refresh the signer composition and ensure that the Guardian remains operationally resilient.

The Governance Emergency Guardian provides a protective backstop for Aave Governance. Its role is to cancel governance proposals or payloads that are malicious, materially erroneous, or otherwise unsafe to execute.

Aave Governance contracts cannot independently determine the semantic intent or safety of a proposal. If a malicious proposal is submitted, its creator cannot be expected to cancel it voluntarily. The Governance Emergency Guardian therefore remains an essential final safeguard within the governance process.

Although this role is exercised infrequently and carries less time pressure than the Protocol Emergency Guardian, it must still be possible to contact signers and assemble quorum within the applicable governance lifecycle.

This rotation is intended to:

  • Refresh the signer set to reflect the DAO’s current stakeholder landscape.
  • Maintain a reliable and reachable quorum.
  • Improve operational resilience and signer availability.
  • Preserve separation between the responsibility to cancel governance actions and the responsibility for protocol emergencies.
  • Reduce the security risks created by publicly attributing individual signers.

The DAO thanks all current and outgoing signers for their service and support.

Signer privacy and operational security

The public attribution of individual signers can create avoidable security risks, including targeted phishing, social engineering, coercion, and attempts to compromise signing devices or communication channels.

Following the approach adopted for the Protocol Emergency Guardian rotation, the specification below identifies signers only by their signing addresses.

The addresses must necessarily remain public onchain. Some retained addresses may already have historical public attribution. This proposal does not provide or expand the attribution of the proposed signer set.

Before implementation, every signer should confirm compliance with the operational security requirements of the role. Signers remain responsible for maintaining compliance with these requirements for the full duration of their tenure as a signer, including:

  • Use of a hardware wallet or equivalently secure signing setup.
  • Verified out-of-band communication for signing requests.
  • Independent verification of every transaction before signing.
  • Continued availability and access to the designated signing account.

Specification

The Aave Governance Emergency Guardian will retain its existing 5-of-9 configuration and be updated to the following signer set:

Signer Address
Signer 1 0x61C2dAE896f93e5f0f10425914CE7868eE8A0e44
Signer 2 0x2694B8A8490f10f98Da6F83d18267Eae9412CbF1
Signer 3 0x1e3804357eD445251FfECbb6e40107bf03888885
Signer 4 0xb291232F480F41c75802C4a60F1D2AC03404Afef
Signer 5 0xDA5Ae43e179987a66B9831F92223567e1F38BE7D
Signer 6 0x985F3290d7971a840152E46d00b5ceb60A56f235
Signer 7 0x9EF7c9A17c5881d54A4694785637acD93E790403
Signer 8 0x4f96743057482a2E10253AFDacDA3fd9CF2C1DC9
Signer 9 0xA3103D0ED00d24795Faa2d641ACf6A320EeD7396

Scope of changes

This proposal does not expand or otherwise modify the authority of the Governance Emergency Guardian.

The following remain unchanged:

  • The 5-of-9 signature threshold.
  • Existing Governance Emergency Guardian Safe addresses.
  • Governance and PayloadsController permissions assigned to those Safes.
  • The conditions and processes under which cancellation powers should be exercised.

Implementation is expected to consist solely of transactions that rotate ownership on each Governance Emergency Guardian Safe.

A chain-by-chain execution manifest should be published before implementation to ensure every deployed Safe is updated and subsequently verified.

Disclaimer

This proposal was prepared by Aave Labs in its capacity as a contributor to the Aave ecosystem.

Next steps

  1. Gather feedback from the Aave community.
  2. If community sentiment is favorable, proceed to an ARFC Snapshot.
  3. If the Snapshot outcome is YAE, confirm the operational readiness of all proposed signers.
  4. Publish the complete chain-by-chain execution manifest.
  5. Execute the signer rotations while retaining the 5-of-9 threshold.
  6. Verify the resulting owner set on every deployment and update the relevant documentation.

If technical review determines that any Guardian Safe address or assigned permission must change, the necessary changes should be submitted through an AIP. Otherwise, no change to the Governance Emergency Guardian’s onchain permissions is required.

References

Copyright

Copyright and related rights waived under CC0.