[ARFC] Renewal of Aave Guardian - 2024

Governance General
1

Title: [ARFC] Renewal of Aave Guardian - 2024

Author: @marczeller - Aave Chan Initiative

Date: 2024-04-30

Summary

The Aave Guardians are a community-elected group with soft emergency protection permission on the Aave smart contracts. Periodically, the composition of this group undergoes renewals in which members may join, stay, or leave based on community votes. This process has occurred in the past, with the last renewal taking place in 2022. At present, it’s time for another round of renewals to ensure the Aave Guardians continue to embody the evolving interests and needs of the Aave community.

Motivation

The Aave Guardians play a vital role in protecting the Aave Protocol.

This proposal aims to start a renewal of the aave guardian, allowing for the removal of members who wish to step down & the addition of new members more reflective of the Aave DAO’s current active contributors.

Specification

This proposal introduces 2 different Guardians, with a majority of non-common members on each one, and different roles.

Protocol emergency Guardian

This Guardian is the holder of EMERGENCY_ADMIN role in Aave v3, together with similar role in v2 and surrounding systems.
Given that speed is mandatory in an emergency situation, the members recommended are entities really active within the Aave DAO, for example service providers and delegates.

Its multi-sig configuration will be a 5-of-9.

Members proposed (1 representative of each):

  • Chaos Labs (risk service provider).
  • Llamarisk (risk service provider).
  • Karpatkey (finance service provider).
  • Certora (security service provider).
  • Tokenlogic (finance service provider).
  • BGD Labs (development service provider).
  • ACI (growth and business development service provider).
  • Ezr3al (Aave DAO delegate).
  • Stable Labs (Aave DAO delegate).

Governance emergency Guardian

This other Guardian has an even less frequent role: cancel governance proposal whenever detected as malicious or containing mistakes (detected on the on-chain verification stage by Certora).
The rationale of being composed by different members than the Protocol emergency Guardian is that cancellation permissions whenever possible should be held by a different party than protocol-emergency ones. In addition, speed is not as critical as the Protocol emergency Guardian, given that Aave proposals happen during a period of 5 days, and problems can always be detected with enough time-margin.

Its multi-sig configuration will be a 5-of-9.

Members proposed (1 representative of each):

  • ACI (growth and business development service provider). In both guardians for coordination/reach purposes.
  • Mounir (Paraswap)
  • Gavi Galloway (Standard Crypto)
  • Meltem Demirors (Coinshares)
  • Emilio (Avara)
  • Roger (Chainlink community)
  • Mariano Conti (DeFi OG)
  • Marin (Lido)
  • Certora (security service provider). In this governance given their role reviewing governance proposals.

A detailed view of permissions of the Aave Guardian on all Aave systems can be found HERE.

Next Steps

  1. Solicit/gather feedback from the Aave community.
  2. If community sentiment is favorable, proceed with the ARFC snapshot.
  3. if the ARFC snapshot vote outcome is YAE, Escalate to AIP stage for implementation.

Disclaimer

The ACI is not presenting this ARFC on behalf of any third party and is not compensated for creating this ARFC.

Copyright

Copyright and related rights waived under CC0.

6 Likes
2

I would be happy to assist as a member of the protocol emergency guardian.
Address used will be: 0x8659d0bb123da6d16d9394c7838ba286c2207d0e

3 Likes
3

LlamaRisk is also happy to assist as a member of the protocol emergency guardian. The address used for our signer will be: 0xbA037E4746ff58c55dc8F27a328C428F258DDACb

3 Likes
4

To give some extra visibility on the role of both Guardians on Aave:

  • First and foremost, the Aave Guardian has no management power in the Aave ecosystem. Its role is purely protective in emergency situations, in both the case of the Protocol emergency Guardian and the Governance emergency Guardian.

  • Guardian members are exclusively elected by the Aave governance itself, via the standard procedures.

  • An exhaustive list of permissions held by the Guardian can be found on https://github.com/bgd-labs/aave-permissions-book, an indexing tool we created during our previous professional engagement with the DAO (Phase 2).

  • As disclosed by ACI, actions that can be done by the Protocol emergency Guardian (and the need of this mechanism itself) require by nature speed: if for example a bug is detected on the system, protective actions like halting supplying/borrowing liquidity should be executed as fast as possible, while a governance proposal with the fix gets prepared for the regular Aave governance to approve. Not having that mechanism would potentially put at risk funds on Aave, given that 1) any governance proposal requires 5 days to get enacted 2) proposals are public in nature, which could expose the bug due to the fix.

  • The rationale of the Governance emergency Guardian is slightly different: the Aave governance smart contracts have no “semantical” knowledge of the payloads getting voted and executed. This means that the system doesn’t have any way of understanding what is a malicious proposal or not, same as a proposal containing some type of bug or not.
    The Governance emergency Guardian role is to, also in some type of emergency situation, provide that semantical interpretation of what is really the nature of a proposal. How it will usually work would be that the correspondent security service provider (currently Certora) reviewing proposals would detect that one is malicious or wrong. If wrong, the first step would be for them to notify the creator of the proposal to cancel it, so no intervention of the Guardian would be required. But if malicious, by definition the creator will not cancel it, so the Governance emergency Guardian should.

  • Same as with other blockchain mechanisms, it is possible that the infrastructure will improve in the future allowing for better system for security emergency handling. However, on the current state-of-art, from our point of view the Guardian mechanism is necessary in order to protect Aave’s security.

8 Likes
5

It would be helpful for the community to better understand how the guardian members were chosen from the delegates (Ezr3al, Stable Labs)? What is the precise process in which a delegate gets chosen to be a Guardian?

  • Is it some amount of delegated votes?
  • Some amount of activity on the Aave governance forums?
  • Is it a track record of behavior in public and private channels?
  • accordance with the overarching mission of Aave?

Similarly, how were the governance emergency Guardian chosen? To the average Aave holder, these just seem like a list of random names aside from Emilio, Certora, ACI. Their organizations are well known entities within crypto, but people also change jobs all the time so it would be helpful to see clarity on the criteria and considerations for membership here.

2 Likes
6

I’m thrilled to be proposed as one of Aave Governance emergency Guardians.

In case of a positive community sentiment, attaching the signer address 0x0D2394C027602Dc4c3832Ffd849b5df45DBac0E9

1 Like
7

The current proposal has been escalated to ARFC Snapshot

Vote will start tomorrow, we encourage everyone to participate.

1 Like
8

After Snapshot monitoring, the current ARFC Snapshot has recently ended, reaching both Quorum and YAE as winning option, with 648K votes.

Therefore the current ARFC to Renew Aave Guardian 2024 has passed, and next step will be the publication of an AIP for final confirmation.