RFC. Aave Governance. Adjust Level 2 requirements (long-executor)


Following the approval by the Aave governance with 325k AAVE votes on Snapshot, we have been working on the necessary smart contract implementations and security procedures to apply the update on the Level 2 governance requirements (long executor).

The change is relatively simple in terms of code, but the validations have been really extensive, as it involves the movement of the most critical permissions of Aave from some smart contracts to others.

All the smart contracts involved and procedures around the proposal are described in detail on the public repository https://github.com/bgd-labs/aave-gov-level-2-update, but the following act as a summary of what will happen on this proposal.

Smart contracts

2 new contracts will be deployed:

  • The new Level 2 Executor. With the updated parameters, receiving all the permissions previously held by the current Level 2 Executor.
  • New implementation of the AAVE ecosystem reserve. Including functionality to vote once on a governance proposal, which will be the one replacing the Level 2 Executor. This is the “boost” mentioned in the opening discussion of this thread.


Involving 2 different governance proposals, the order of execution of everything is extremely important, and will be:

  1. Deployment of the new Executor smart contract.
  2. Deployment of the ProposalPayloadNewLongExecutor payload smart contract.
  3. Creation of the Level 2 proposal on the Aave governance. Voting starts.
  4. With the proposal on 3) live and with an assigned proposal id, use that id to deploy the payload of the boosting proposal ProposalPayloadAaveEcosystemReserveWithVoting.
  5. Create the Level 1 proposal to boost Level 2’s. Voting starts.
  6. When/if Level 1’s proposal passes, queue, and execute it, adding the votes on Level 2’s proposal on the YES side.
  7. Wait until/if Level 2’s proposal passes, queue, and execute.

Time diagram (lengths of the different periods are not intended to be exact)

Important considerations

  • To submit the Level 2 proposal, the proposer will require 320k proposition delegation. We will ask the community to receive this delegation, but it is fundamental that only proposition power is delegated, not voting power. This needs to be done by selecting Type of delegationProposition Power on the Delegate pop-up of the Aave UI.

  • The proposition delegation will need to be kept for a duration of 17 days (10 days of voting and 7 days of queueing), as being below the 320k proposition threshold during that period would open for anybody to cancel the proposal.

  • We think the most responsible timeline to initiate this proposal is some days after the Ethereum Merge, as any network disruption or lack of focus on AAVE voters would be harmful to the proposal.

  • This is a really critical proposal for the progress of multiple developments of the Aave ecosystem, so again, we insist that everybody with the possibility and will of doing it should participate; every vote potentially counts. Projects depending on this are:

    • Rescue of tokens locked by mistake on smart contracts of the ecosystem.
    • Migration of AAVE/WETH Safety Module to Balancer v2.
    • Aave Governance v3.

Let us know if there is any doubt about the proposal, and if everything is clear, we will propose a date to initiate the process.