1. Problem statement

This document presents a technical analysis of BGD Labs regarding the project for the Aave community to upgrade the smart contract implementations of Aave v2 Ethereum, in order for them to become Aave v3 feature complete.

Some degree of familiarity with the Aave v2 and Aave v3 architecture is required to follow this document.

2. Execution plan

All Aave v2 Ethereum smart contracts are controlled by the Aave Governance, a smart contract living on the Ethereum network, controlled by an algorithmic voting process of which AAVE token holders are the core participants.

More specifically, all permissions of upgradeability of the Aave liquidity protocol (from now on Aave v2 Ethereum) are directly or indirectly under the control of the so-called Level 1 Governance Executor or “Short Executor”, deployed HERE.

Therefore, to update all the necessary smart contracts of Aave v2 Ethereum to an Aave v3 version, it is mandatory to go through a voting and timelock period of approximately 4 days, and the upgrade happens exclusively on-chain, by programming the instructions on a so-called “proposal payload”.

Ideally, this upgrade should be fully atomic; happening in one sole transaction, equivalent to one sole governance proposal. In practice, given the high number of smart contracts to upgrade/connect to the liquidity protocol, and security/operational aspects, our initial evaluation tells us that the most optimal update path is in 2 sequential phases:

3. Phase 2

3.1. High-level procedure

It is assumed that Phase 1 is completely executed before proceeding with Phase 2.