ARC: Activation of Aave Protocol Governance V2

ARC rationale

The Aave Protocol v2 is quickly growing in TVL, with already 35M$ in deposits even before the implementation of the V1→ V2 migration tool. Now, the time has come for the community to discuss the next major part of the Aave decentralisation process: governance.

The current process looks like this :

The core of this AIP is to implement an option to bypass Step 4 of the AIP process, allowing any AAVE holder with enough assets to submit an AIP to the decentralised Aave governance.

Moving forward, the Aave Genesis Team will be just one of many innovation forces of the Aave Protocol.

The current model of the V1 governance only allows the Aave Genesis Team to submit AIPs as binding governance proposals. With this proposal, any Aave community actor meeting the requirements will be able to create an AIP for binding votes.

Users who possess a direct stake in the Aave ecosystem should have proportional power to govern it. Consequently, the new governance module aims to bring inclusivity, whilst simultaneously guaranteeing the safety and decentralisation of the Aave ecosystem.

Aave V2 governance is inspired by delegation-based governance models already on the market, while introducing 3 key innovations and a new layer of resilience:

  1. The introduction of a new concept in DeFi governance - the segregation between voting and proposition power to increase control and ownership of voting rights for AAVE holders.
    AAVE holders will have the choice between delegating proposal creation power to specialized actors while holding their voting rights; or even delegating them to another entity.

  2. Voting strategies - The AAVE token exists and is used in the Aave ecosystem in a variety of ways. Through different voting strategies, AAVE in different forms can be used to vote. In the initial implementation both AAVE and stkAAVE holders will have voting rights. Voting strategies can be upgraded at any time through a governance proposal to include other forms of AAVE (i.e. aAAVE, staked AAVE/ETH AMM shares, etc.)

  3. Multiple executor entities - Different components of the ecosystem might have different needs for consensus and security. For example, changing the AAVE token logic itself might have a large impact on the ecosystem and is something that requires higher consensus than adjusting a risk management parameter. The Aave governance V2 splits the control of different entities within the Aave ecosystem between different executors with different execution delays (timelocks) and different consensus parameters. At the beginning there will be two different executors:
    a. Executor 1 (short timelock) will control the whole Aave Protocol v1, the token distributor used in v1, the contract collecting the v1 fees, the AAVE Reserve Ecosystem and any change in this timelock itself. Once the break-in period for Aave V2 is completed, this timelock will also control the current Aave V2 market and all the future markets instantiated by the Aave Genesis Team.

  • admin (the only address that can interact with this executor): Aave Governance v2

  • delay (time between a proposal passing and its actions executing): 1 day

  • grace period (time after the delay during which the proposal can be executed): 5 days

  • proposition threshold: 0.5%

  • voting duration: 3 days

  • vote differential: 0.5%

  • quorum: 2%

b. Executor 2 (long timelock)will control the upgradeability of the AAVE token, stkAAVE, any change in v2 governance parameters and any change in the parameters of this timelock itself.

  • admin: Aave Governance v2

  • delay: 7 days

  • grace period: 5 days

  • proposition threshold: 2%

  • voting duration: 10 days

  • vote differential: 15%

  • quorum: 20%

  1. The Guardian - As long as a large majority of AAVE tokens are in a centralised exchange, it’s impossible to prevent a STEEM-like governance attack where a centralised entity would use its users’ assets to take over a decentralised protocol through governance. As a security measure to avoid such a scenario, a temporary 5/10 multisig is given a power of veto to cancel proposals in case malicious code is introduced through an AIP. Those entities have been chosen within the AAVE community to be globally distributed, and they cover safety skill sets through governance, code, and economic analysis. Guardians can be changed later through election.
    The current multisig signers are : James Vaugh (Fire Eyes/Metacartel), Anthony Sassano (SET protocol/ETHhub/Daily Gwei), Mariano Conti (ex MakerDAO head of smart contracts), Tarun Chitra (Gauntlet), DeFiSaver, Zerion, Parafi Capital, Framework Venture, Arthur0x and the Aave Genesis Team

Some of the expected short-term outcomes of this implementation are new actors creating proposals for token additions, risk parameter upgrades or new liquidity market creation.

ARC in Short

  • Implementation of voting delegation and proposal power delegation
  • Implementation of voting strategies with the inclusion of AAVE and StkAAVE
  • Implementation of Executor entities
  • Implementation of the Guardian

For further understanding of the new mechanisms introduced in this proposal, please refer to the following diagram:

11 Likes

Absolutely for!

Excited to see governance come to light- and the guardian system is an interesting strategy to mitigate centralization risk. We’ve got a strong cast of guardians!

Just to make sure I grasp the structure correctly I’ve got a couple of questions: Is the vote differential the vote difference that must be present in order to implement a proposal? I.e: For a proposal built on the short timelock executor, 49.75% against and 50.25% for would pass, but 49.9% against and 50.1% would not, is that right?

Similarly, for major token or governance upgrades, 42.5% against and 57.5% for would be the minimum ratio to pass, correct?

Lastly, when you state the quorum numbers, is this as is usually implied, where a 2% quorum means that at least 2% of the total supply must vote, regardless of voting direction?

Or is it the more recent definition of quorum, where a 2% quorum implies that at least 2%of the supply must vote for a certain proposal in order for it to pass?

Excited to see this roll out! Maybe I should become a delegate… :thinking:

3 Likes

Hey,

You are right on all the points:

  • The vote differential is like you defined, the mandatory percentual “separation” between against and for votes, more strict in the long executor than in the short.
  • Quorum is understood as for quorum, so % over the total voting supply of for votes needed.
2 Likes

The same questions confusing me too…

1 Like

What about the proposition threshold? Is that the minimum amount of tokens accounting for the total amount for making a proposal? Specifically, a proposer need to hold at least 0.5% of the 16 million AAVE (80,000) to make a short timelock proposal. Is it like this?

2 Likes

Sounds like it- however keep in mind holders will be able to delegate their “proposal creation power” to delegates, so you don’t need to specifically garner 0.5% of the entire supply, but 0.5% of the total proposal creating power.

1 Like

Do we have a portal for delegate now? Or is it still in development process?

1 Like

hello, Yes the short timelock (Token addition) is 0.5% so 80k AAVE.

The delegation module is available in the governance section of the Aave app

2 Likes