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

Governance
1

TL;DR

Currently one of the components of the Aave governance has what we consider too strict requirements, potentially blocking progress and community contribution.
We provide some rationale and suggestions on how to adjust these requirements.


Context on the current Aave Governance V2

As it is well known in the community, currently all the Aave systems are controlled in a decentralized manner by AAVE holders, mainly via using the Aave Governance V2 smart contracts, living on Ethereum mainnet.

From a high-level perspective, the current governance divides the systems it controls into 2 groups:

  • Systems affecting governance processes: this includes control over changes that could directly affect the dynamics of the voting/proposition power or the logic of the voting itself. In this group is included the upgradeability of the AAVE/stkAAVE tokens, the permissions on the Governance v2 smart contract itself, or the upgradeability of the AAVE/ETH Balancer ABPT and stkABPT (which was planned to introduce as a voting asset, even if it is not the case yet).
    From now on, we will refer to this group as Level 2, also known as governance long-executor.
  • Systems NOT affecting governance processes: everything else not included in the previous group, mainly all permissions related to the Aave liquidity protocol. These systems have also high criticality, but they don’t affect directly the governance dynamics themselves.
    From now on, we will refer to this group as Level 1, also known as governance short-executor.



permissions-diagram-gov
permissions-diagram-gov1920Ă—1287 96 KB



As can be expected, the requirements of Level 1 and Level 2 are substantially different, with Level 2 being way higher than Level 1:

Level 1

  • Proposition power needed to submit a proposal: 0.5% of the AAVE total supply, equal to 80’000 AAVE voting power.
  • Amount of YES needed to pass a proposal (also known as quorum): 2% of the AAVE total supply, equal to 320’000 AAVE voting power.
  • Amount of YES votes over NO votes to pass a proposal (also known as voting differential): 0.5% of the AAVE total supply, equal to 80’000 AAVE voting power.
  • Voting duration: 3 days.
  • Timelock after a proposal passes, before getting executed (also known as queueing time): 1 day.
  • Expiration time for a proposal to be executed after timelock ends (also known as grace period): 5 days

Level 2

  • Proposition power needed to submit a proposal: 2% of the AAVE total supply, equal to 320’000 AAVE voting power.
  • Amount of YES needed to pass a proposal: 20% of the AAVE total supply, equal to 3’200’000 AAVE voting power.
  • Amount of YES votes over NO votes to pass a proposal: 15% of the AAVE total supply, equal to 2’400’000 AAVE voting power.
  • Voting duration: 10 days.
  • Timelock after a proposal passes, before getting executed: 7 days.
  • Expiration time for a proposal to be executed after timelock ends: 5 days

There is a quite big difference between the requirements of Level 1 and Level 2, and this was approved this way in the past by the community mainly because of these reasons:

  • Level 2 contracts should only be updated very rarely, so having high requirements could be acceptable.
  • Any update on Level 2 is critical, both from a technical point of view and possible implications for all dynamics of Aave.
  • Requirements should be high enough to not allow 1-2 single parties to pass a proposal single-handed if there is opposition.
  • Level 1 requirements are high enough to be meaningful and protect the system, but not too high as to paralyze the governance procedures.

Rationale for relaxing the requirements for Level 2 proposals

As expected, for more than 1 year and a half, out of 80 Aave governance proposals, only 1 was targeting a change on Level 2. So the assumption of low frequency was correct.

But it is important to go to the specifics of that sole proposal that was targeting Level 2.

Proposal 41 was trying to improve the configuration of the Aave governance smart contract, by changing the delay from proposal creation to the start of voting, from 0 (no delay) to 2 days. The support on the forum was vastly positive, and this is natural because apart from making a bit longer the proposal process, there are not so many disadvantages to this delay.

Proposal 41 gathered 1’030’000 YES votes and 0 NO, but still, it was 2’170’000 YES away from passing, even with full support. First-sight, this doesn’t really seem “natural”.

As the community knows, since 1.5 months ago, BGD has engaged with Aave for technical developments on the Aave ecosystem.

Of the list of tasks to tackle, there is a good part of them that require proposals targeting Level 2: “rescue mission” of locked tokens, migration of ABPT/stkABPT from Balancer v1 to Balancer v2, the Governance V3 itself.

As each one of these projects has its own complexity and completely different scope, it is simply not realistic to even group them into 1 big proposal targeting Level 2, as the voters’ overhead would be so big that it would be difficult to do a clearly rational vote.

This means in practice that, after implementation, for the community to actually approve those projects on-chain, it will be necessary to pass multiple proposals on Level 2, of which the only precedent was really far away to pass because of the requirements.

In addition to that, there are other factors that indicate that those Level 2 requirements are too strict:

  • The voting supply on which the parameters are defined is the fixed supply of AAVE tokens, 16’000’000 AAVE. But actually, this is not really accurate at the moment, because not all that supply is able to vote:

    • AAVE deposited on Aave v2 Ethereum (aAAVE) is not able to vote, accounting for 16.7% of the supply or ~2’673’000 AAVE.
    • The AAVE ecosystem reserve is not able to vote* (will re-visit this later), accounting for 10.7% of the supply or ~1’700’000 AAVE.
    • AAVE/ETH Balancer v1 is not able to vote, accounting for 5.2% of the supply or ~840’000 AAVE.
    • LendToAaveMigrator (contract keeping the AAVE for pending that didn’t migrate yet from LEND) is not able to vote* , accounting for ~2.4% of the supply or ~380’000 AAVE.
    • AAVE tokens bridge to Polygon and Avalanche are not able to vote, accounting for ~1.5% of the supply or 240’000 AAVE.

    Without going really deep in the analysis, and not taking into account the custody holdings of exchanges like Binance/Coinbase/FTX/Gemini/etc (coming next), the previous already shows a minimum of 36% of the supply (5’840’000 AAVE) technically unable to participate on voting.

  • In what concerns AAVE deposited on exchanges’ wallets like Binance or Coinbase the distribution at the moment (considering top 50 holders of AAVE) is the following:

    • Deposits on Binance account for ~11.64% of the AAVE supply.
    • OKEx for ~1%.
    • FTX for ~0.7%.
    • Gemini for 0.7%.
    • Coinbase for ~0.45%.

    Assuming there are other exchanges’ wallets holding small amounts, approximately the aggregation of all of them is ~15%. A collusion of all of these entities is most probably impossible, and even if we would consider adversarially a subset of them including the biggest on the group (Binance), 12-13% is really far from 20% and even not fulfilling the requirements of difference between YES/NO (15%).

    In practice there are 2 aspects to consider:

    • Even if there is some history of participation of these parties in governance votes, in practice it is way less probable having them do any type of adversarial action than all the rest of the holders, as in the big majority of the cases, they are highly regulated.
    • As a consequence of the previous, we consider that is more accurate to consider the aggregated 15% of holdings as not-able to vote.

To summarise, we think it is possible to interpret that with the current requirements on Level 2, passing a proposal would require at least 40% of the effective voting supply (entities able to vote) to vote for YES, assuming less than 5% of the effective voting supply voting against.
That is in our opinion a too strict requirement, only targetable on an almost perfect system in terms of voters’ turnout (we are definitely not there yet), and that in practice will only act as an obstacle to proceeding with contributions (of technical nature usually) like the ones on the Aave <> BGD scope.


Our proposal

Considering the previous data and the type of proposals to probably appear in the short/medium term, our proposal of changes is the following:

  • No change on the parameters of Level 1. Proposals are passing/not passing at a normal pace and lowering more than the current level could create problems with centralization of influence, that is why we suggest keeping it as it is.
  • Lower YES voting requirements on Level 2 to 6.5% of the supply or 1’040’000 AAVE. The rationale for this is that it was possible to gather 1’030’000 AAVE on a fully-supported proposal, and considering only 49% of the total supply able to participate, this 6.5% means in practice a minimum of 13.2% voter turnout supporting YES.
  • Lower YES/NO differential requirements on Level 2 to 6.5% or 1’040’000 AAVE. Voting differential is the majority protection of YES against NO, factually overvaluing NO in order to protect the system. We think that any adversarial entity trying to harm the Aave community should not be able to gather even 12% of the voting supply. Even if that would be the case, NO opposition of 5.5% of the voting supply would not allow the proposal to pass.
    In addition, the community Guardian is able to intervene still on clearly malicious proposals, factually removing any incentive to even try.
  • Lower proposing power requirements on Level 2 to 1.25% or 200’000 AAVE. In order to do a proposal on Level 2, we think it is important to have good initial support in terms of proposition power, but the current 2% (320’000 AAVE) seems too strict.
  • Set a voting delay system-wide of 1 day. We think that 2 days can still be a bit excessive for a lot of proposals on Level 1, but certain preparation time probably makes sense and was voted like that by the community on proposal 41.

How to pass this proposal?

If the community decides to go forward with this change, it is still necessary to pass a proposal on Level 2 with the current requirements, which can be a quite challenging endeavor, but possible.

Going back to something mentioned before, one of the entities holding AAVE voting power at the moment but incapable to vote is the AAVE ecosystem reserve, which has 10.7% of the supply or 1’700’000 AAVE. This contract is conceptually designed to only hold AAVE funds to be allocated by the community for distribution of governance power to other entities, for example, participants on the Aave V2 Ethereum, or participants of the Safety Module.

But the AAVE ecosystem reserve is an upgradeable contract and controlled by the governance on Level 1. What this allows to do is the following:

  1. Create the Level 2 proposal to change Level 2 parameters.
  2. Create a Level 1 proposal to upgrade the AAVE ecosystem reserve, allowing for a one-time vote on the previous Level 2 proposal with the ~1’700’000 AAVE. We will refer to this proposal as a voting-boost.
  3. If the community votes YES on the voting-boost proposal, the 1’700’000 AAVE votes will apply to the Level 2 proposal, so at that point only ~9.7% of the supply (or ~1’500’000 AAVE) on YES will be needed to pass the change on Level 2.

It is fundamental to highlight that this should be done only as a one-time action, as the AAVE ecosystem reserve is not supposed to act as a proxy to vote from Level 1. In our opinion, this is a legit action this time because of the high difficulty of reaching otherwise the 20% supply on YES, combined with a clear data-driven overestimation of the current requirements.
In addition, the voting-boost proposal is still a regular Level 1, so the community can simply decide to not apply boost, factually not allowing to pass the Level 2 proposal.

P.S. The LendToAaveMigrator could be used exactly the same way as the AAVE ecosystem reserve, but we don’t really consider it a legitimate action, as those should be technically voting power of the people who didn’t migrate yet from LEND.


Links


Next steps

  1. Really important that the community discusses about everything exposed here, potentially suggesting modifications if adequate.
  2. If there is positive feedback after some days, BGD will create a Snapshot. Given the importance of this proposal, we think 250k YES votes on Snapshot are the minimum required to proceed.
  3. Preparation of everything for the on-chain governance proposal and creation of it.
17 Likes
2

As explained, Level 2 proposals are the most critical kind of proposals that change the Aave protocol.

Very high thresholds have been defined to make an attack on Aave a costly and difficult attack to execute.

The cost & faisability of a potential attack are defined by the market value of the Aave asset + the “availability” of threshold aave assets on the secondary market.

Lowering the threshold by definition makes this kind of attack more doable but I think the proposed threshold is still hard to reach and to my current knowledge little to no entities can reach the proposed threshold currently.

Also voting with the ER is smart but sets a precedence that can become dangerous long term if it’s not crystal clear it’s a “one-time” thing, current proposal makes this clear and I welcome that…

that is why even though some conservative concerns I wanted to express, I’m supportive of this RFC.

6 Likes
3

The long-executor has brought certainty to ensure that where applicable the changes to the infrastructure would have a higher acceptance rate from the community given the fundamental nature of what Level 2 is governing. Originally, many of these functions that Level 2 is governing might be found in other protocols as immutable. The Aave community approach was to keep upgradability (but in significantly higher requirements) in case of new innovation or updates to the infrastructure would be required in the future (which was a good call). The current limits as explained are creating a bottleneck for some of the proposals that are beneficial for the community.

Lowering the Level 2 parameters to proposed would help to pass proposals from the community that while still keeping the Level 2 requirements at a level that requires significant threshold to change fundamental parts of the architecture. Hence supporting the proposal with the proposed parameters. Given the importance of passing the proposal - the voting-boost might be required to achieve the effective votes during these market conditions and for specifically ad hoc basis.

The Guardian was designed to protect the system from malicious proposals and mainly to avoid collusion. It seems that the amount of assets in centralized exchanges have been decreasing over time, and the risk for collusion. Hence for long-tern plan or during gov v3 upgrade, the community should consider whether to mitigate or abandon the guardian function related to the Level 2 proposals to increase decentralization.

3 Likes
4

Adjusting Level 2 requirements is a long overdue change to the Aave governance process.

It’s clear why the barrier to such changes has been so high in the past. These are incredibly important and serious changes to the protocol and therefore require extra thought, care and time.

However, as mentioned, few proposals so far have actually fit into the category, and the key example of one that has - AIP 41 - failed despite receiving huge support.

It’s clear that now more attention is being paid to the process for these more critical changes the requirements for them have shown themselves to be too much of a barrier - especially given the number of wallets unable to vote on proposals as is outlined in this proposal.

Therefore, it makes total sense to lower the thresholds for these more critical changes.

1 Like
5

After a good period of time to gather feedback from the community, we have created a Snapshot proposal, with voting starting tomorrow and lasting for 7 days.
https://snapshot.org/#/aave.eth/proposal/0x296983800a2f7bd6227dda45a106e40e759a75e1c908456af4c2f6d6f668c540

Given the importance of the proposal, and as described in the opening post, we think a minimum of 250k For votes on Snapshot are required to proceed to the on-chain step.

3 Likes
6

UPDATE


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.

Step-by-step

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.


Untitled-2022-09-09-1334
Untitled-2022-09-09-13341920Ă—1977 110 KB

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 delegation → Proposition 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.

8 Likes
7

good night! Is there any progress with the token rescue proposal?

8

Following the timeline proposed in the previous message, we can communicate now to the community that all the implementation and security procedures have been finished and the deployments required for the Aave governance to vote on have been done.
All deployment information can be found on https://github.com/bgd-labs/aave-gov-level-2-update/releases/tag/mainnet-deployment


The proposal creation for both governance proposals will be done in a completely decentralized way, via a so-called Autonomous Proposal procedure. An Autonomous proposal is a smart contract with the necessary mechanism to:

  1. Receive proposition power from anybody delegating.
  2. Expose a function to create the programmed proposals on the smart contract, once the necessary proposition power is enough (and after a certain date, programmed on the Autonomous proposal itself).

The programmed date when the proposal can be created (if it accumulated the necessary 320k AAVE proposition power) is timestamp 1664892000 or Tuesday, 4 October 2022 14:00:00, in approx. 7 days from now.

We ask the Aave community to delegate ONLY AAVE/stkAAVE PROPOSITION POWER to the address of the Autonomous Proposal smart contract 0x6E1A6728829BC0FcA82C1A39834c6212C250F1c1

Again, 320k AAVE/stkAAVE proposition power delegation is necessary on it before 4th October, for the contract to be able to create the governance proposals.

You can delegate via app.aave.com/governance and you can find a guide about delegation on https://github.com/bgd-labs/how-to-delegate-aave

DON’T SEND AAVE TOKENS TO THE CONTRACT, ONLY GIVE PROPOSITION DELEGATION. THE FUNDS WILL BE LOST IF SENT THERE
An additional and important aspect is that the proposition delegation given will need to remain on the Autonomous Proposal smart contract for the whole vote duration, that is 17 days. If during that time the proposal doesn’t have more than 320k proposition power, anybody will be able to cancel it.

Additionally, we encourage the broad Aave community to prepare the AAVE tokens or gather voting delegation to have it ready to vote on 4th. If the AAVE voting power is not in the appropriate wallet to vote on 4th, it will not be possible to vote with it.



To summarize:

Before 4th October

  • Give ONLY PROPOSITION POWER to 0x6E1A6728829BC0FcA82C1A39834c6212C250F1c1 , the address of the Autonomous Proposal. You can do it via app.aave.com/governance and you can find a guide about delegation on https://github.com/bgd-labs/how-to-delegate-aave.
  • Prepare on a wallet able to vote your AAVE voting power (don’t give voting power to the proposal).

4th October

  • Both Level 2 and “boost” proposals will be created by the Autonomous Proposal, and open to voting.

After 4th October

  • Voting on both proposals opens, with “boost” lasting 3 days, and Level 2 lasting 10 days. Vote on both if you can!
    320k AAVE are required to pass the “boost” proposal, and approx. 900k to pass the “Level 2” one.

  • If you delegated proposition power to the Autonomous Proposal, don’t remove it until it passes and gets executed, in 17 days.

5 Likes
9

proposition power delegated.

Godspeed!

3 Likes
10

I don’t have much AAVE to delegate but I wanted to show support. My proposal power has been delegated.

Good luck.

2 Likes
11

We revoked and diverted 48k from our delegation and will be delegating Gauntlet’s holdings as well. We do want to keep the 80k prop power threshold while we are actively proposing but if required we can look to sequence proposals to delegate our remaining 92k

1 Like
12

Gauntlet has delegated our holdings. Total prop power for 0x6E1A6728829BC0FcA82C1A39834c6212C250F1c1 is now at 63,230.

4 Likes
13

Exemplary guidance by the BGD team here. Kudos for this important proposal, presentation and guidance.

Long-term do you think that ossifying some parts of the smart contracts seems necessary? Being able to change core aspects of the protocol is good for progress but incurs the risk of losing track of the defined goal. Maybe a third level of truly “untouchable” contracts is needed at some point, where core aspects of the protocol live that should only be touched in a life or death situation.

14

During the past few days, the Autonomous Proposal on https://etherscan.io/address/0x6E1A6728829BC0FcA82C1A39834c6212C250F1c1 has been accumulating AAVE proposition power from all the members of the community delegating there.
Finally, the threshold of 320k proposition power has been surpassed, and the Autonomous Proposal has been executed.
What does that mean?

The Autonomous Proposal has initiated 2 votes on the Aave governance:

What to do now?

If you hold AAVE voting power, VOTE ON BOTH 106 AND 107!

If after the 3 first voting days 107 passes, the AAVE of the Ecosystem reserve will automatically vote YES on 106. If 107 would not pass, it will be almost impossible for 106 to reach quorum.

If you delegated proposition power to the Autonomous Proposal, don’t remove it from there during the following 17 days (voting + timelock duration of 106). If the proposition goes below 320k AAVE, the proposal could be cancelled, and the whole process should be re-initiated.

Time to vote ghosts!

7 Likes
15

Are there any whales left, which haven’t voted yet ;) My position is too small!

But overall: Great work from bgdlabs!

Let’s pass this thing

1 Like
16

After 10 days of voting, ~3.21m of AAVE Yes votes (approx. 40% of the total AAVE/stkAAVE able to vote), and a lot of community effort, we can confirm that Aave proposal 106 has passed and it is queued!
:partying_face: :partying_face: :partying_face: :ghost: :ghost:

106-queued
106-queued1638Ă—256 56 KB

After 7 days of timelock, the proposal will be open for execution.
Huge props to the wide Aave community on passing one of the biggest decentralized governance proposals ever!

11 Likes
17

Reminder that proposition power must not be removed from the Autonomous Proposal contract on 0x6E1A6728829BC0FcA82C1A39834c6212C250F1c1 until the proposal gets executed in ~6 days.

7 Likes
18

As a final update on this project, proposal 106 to update the Level 2 requirements has been executed and the new Level 2 Executor is active on the Aave governance on Executor | Address 0x79426A1c24B2978D90d7A5070a46C65B07bC4299 | Etherscan

It is possible now to remove the proposition delegation from the Autonomous Proposal

6 Likes