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.
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:
- 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
- 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.
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.
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.
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:
- Create the Level 2 proposal to change Level 2 parameters.
- 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.
- 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.
- Aave Governance V2 codebase: https://github.com/aave/governance-v2
- Aave Governance V2 Ethereum mainnet: https://etherscan.io/address/0xEC568fffba86c094cf06b22134B23074DFE2252c
- Level 2 smart contract (long-executor): https://etherscan.io/address/0x61910ecd7e8e942136ce7fe7943f956cea1cc2f7
- Level 1 smart contract (short-executor): https://etherscan.io/address/0xee56e2b3d491590b5b31738cc34d5232f378a8d5
- AAVE top holders: https://etherscan.io/token/0x7fc66500c84a76ad7e9c93437bfc5ac33e2ddae9#balances
- stkAAVE top holders: https://etherscan.io/token/0x4da27a545c0c5b758a6ba100e3a049001de870f5#balances
- Really important that the community discusses about everything exposed here, potentially suggesting modifications if adequate.
- 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.
- Preparation of everything for the on-chain governance proposal and creation of it.