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


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.

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.


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.

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.


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.


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

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.

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.