Introduction
In 2019, the first version of the Aave protocol smart contracts (the “Aave Protocol”) were deployed to the Ethereum mainnet. V1 of the Aave Protocol provided a way for users to provide and obtain liquidity autonomously, and to earn yield on any liquidity provided to the protocol.
In December 2020, a second version of the Aave Protocol was deployed, which brought new features to liquidity provision and liquidity access in the DeFi ecosystem. V2 of the Aave Protocol featured, among other things, credit delegation, the ability for users to choose between stable and variable interest rates on any borrow transaction and certain gas optimizations and improvements.
Around the same time, Aave Governance gained administration and maintenance over V1 and V2 of the Aave Protocol and were tasked with the continued growth of the ecosystem around the Aave Protocol (the “Aave Ecosystem”).
The Aave Ecosystem has grown organically over the past two years, supporting successful, safe and risk conscious operation of the Aave Protocol. The community has supported the Aave Protocol’s expansion from the Ethereum mainnet to the Polygon and Avalanche networks as well.
After these two years of substantial growth, this Aave Request for Comment (ARC) to Aave Governance seeks community approval for a new iteration of the Aave Protocol: Introducing Aave V3. 
The ARC provides an overview of the main features and requests a community vote via Snapshot regarding a potential deployment.
The features associated with Aave V3 represent a significant technological advancement from DeFi liquidity protocols as we know them today.
As discussed more fully below, Aave V3 introduces the following features (among others):
-
Portal
: allows assets to seamlessly flow between Aave V3 markets over different networks; -
High Efficiency Mode
: allows borrowers to extract the highest borrowing power out of their collateral; -
Isolation Mode
: limits exposure and risks to the protocol from newly listed assets by only permitting borrowing up to a specific debt ceiling; -
Risk Management Improvements
: provides additional protection for the protocol through various risk caps and other tools; -
L2-Specific Features
: designs specific to Layer 2 networks to improve user experience and reliability; -
Community Contribution
: facilitates and incentivizes community usage through a modular, well-organized codebase.
These features make V3 the most robust and efficient DeFi liquidity protocol ever designed.
Technological Advancement Based on Community Feedback
Although the Aave Protocol has functioned efficiently and seen tremendous growth over the past two years, community analysis regarding the functioning of the protocol has provided key areas for technological advancement:
-
Capital efficiency: V2 does not allow for users to optimize their assets supplied to the Aave Protocol in terms of either yield generation (within the protocol and/or across protocol deployments on various networks) or borrowing power. V3 solves for this.
-
Risk Mitigation Adjustment: Although the Aave Protocol currently has risk mitigation features that can be activated by the community through Aave Governance such as adjusting borrowing power and maintenance margins, additional features can heighten the well-known security inherent in the Aave Protocol smart contracts. V3 solves for this.
-
Decentralization: Aave Governance is robust and thriving—through community members submitting proposals and creating sub-DAOs (the GrantsDAO and the RiskDAO). But to maximize decentralization, certain technological features will allow Aave Governance to further decentralize its functions by delegating to teams or other individuals. V3 solves for this.
-
Cross-chain facilitation: Through community efforts, the Aave Protocol has been deployed across many networks, each with its own meaningful level of liquidity. But users cannot transfer their own individual liquidity seamlessly from one deployment of the Aave Protocol on one network to another. V3 solves for this.
The design of V3 is poised to create the next generation Layer-0 DeFi protocol that can drastically improve user experience while offering increased capital efficiency, a higher degree of decentralization and further enhanced security. 
Aave V3 Overview
V3 maintains the core concepts for which the Aave Protocol is known (aTokens, instant liquidity, stable rate borrowing, credit delegation, etc.) while providing new features, which allow users to create new use cases for the Aave Protocol and may spark a new wave of innovation from the community. 🙌This overview describes the new elements of V3 at a level intended for wider consumption by the community. A technical whitepaper for developers will be released separately.
Portal
Portal allows users to move their own assets seamlessly from deployments of V3 over different networks.
At its core, the feature is quite straightforward: a user’s supplied liquidity can be transferred from one network to another simply by burning aTokens on the original source network (e.g., Ethereum) while minting them on the destination network (e.g., Polygon). A network interconnection built around this feature is called Port.
Portal can help bridging protocols like Connext, Hop Protocol, Anyswap, xPollinate and novel solutions that can be specifically built to leverage Portal, to tap into Aave Protocol liquidity to facilitate cross-chain interactions. Aave Governance will have the ability to grant any cross-chain protocol access to the Ports upon receiving a proposal to do so.
High Efficiency Mode (eMode)
High Efficiency Mode, or “eMode,” allows borrowers to ensure they are able to achieve the highest borrowing power with their own collateral.
The code allows Aave Governance to “categorize” assets based on the following parameters:
-
LTV
-
Liquidation threshold
-
Liquidation bonus
-
A custom price oracle (optional)
These factors will set each different asset in V3 in a particular category.
eMode provides borrowers greater access to capital in the event they limit which assets they borrow by category. In other words, in eMode, borrowers can choose the category of assets they want to borrow. A “category” typically refers to a set of assets pegged to the same underlying asset—for example, stablecoins pegged to USD, assets pegged to ETH, etc.
If a user self-selects to use the Aave Protocol in eMode, when that user supplies assets of the same category as the user’s collateral, the borrowing power (LTV), and maintenance margin (liquidation threshold) are overridden by the eMode category configuration to allow for higher capital efficiency.
An example:
Protocol defines eMode category 1 (stablecoins) as follows:
97% LTV
98% Liquidation threshold
2% Liquidation bonus
No custom price oracle
Karen chooses eMode Category 1 (stablecoins)
Karen supplies DAI (which normally has 75% LTV)
Karen can borrow other stablecoins in Category 1 (including DAI) with the borrowing power defined by the eMode category (97%). Karen’s capital is therefore 22% more efficient.
Note: In this example, Karen can supply other non-Category 1 assets to use as collateral; however, only assets belonging to the same eMode category chosen by the user will have enhanced category-specific risk parameters.
V3 eMode can support up to 255 categories.
New Risk Management Parameters
~ Isolation Mode
“Isolation Mode” is intended to allow Aave Governance to enact risk mitigation features when a new asset market is created on the protocol.
When a community member submits a governance proposal to create a new asset market on V3, the proposal can seek to list the assets as “isolated collateral” such that users supplying those “isolated” assets can only borrow stablecoins that Aave Governance has “permissioned” to be borrowed in isolation mode, up to a specified debt ceiling.
When a user supplies an “isolated asset” as collateral, that user can only use that asset as collateral; even if the user supplies other assets to the protocol, the user can only earn yield on those assets and cannot use those assets as collateral.
In the example above, Chad is supplying $TOKEN2 as collateral. $TOKEN2 is an isolated asset with a maximum debt ceiling of $10M of value and with USDT, DAI and USDC as “borrowable” assets. After supplying $TOKEN2 as collateral, Chad will be able to borrow up to $10M of USDT, DAI and USDC. Even if Chad supplies another asset—let’s say ETH—the V3 smart contracts will not allow Chad to borrow against those assets, although Chad will still be earning yield on the supplied ETH. If Chad wishes to use all assets as collateral and exit isolation mode, Chad only needs to engage in a transaction to disable $TOKEN2 as collateral (subject to all usual restrictions in the smart contracts relating to collateral ratio, liquidations, etc.).
$TOKEN2 can also exit isolation mode when Aave Governance votes on a proposal to remove the debt ceiling related to that asset.
~ Risk Management Features
The V3 technology provides further enhanced risk management mechanisms for Aave Governance to protect against protocol insolvency:
-
Supply and Borrow Caps: Aave Governance will be able to configure both borrow and supply caps. Borrow caps would allow Governance to set limits on how much of each asset can be borrowed, while supply caps allow Governance to vote to limit how much of a certain asset can be supplied to the Aave Protocol. Borrow caps minimize liquidity pool insolvency while supply caps reduce protocol exposure to a certain asset and help prevent attacks like infinite minting or price oracle manipulation.
-
Granular Borrowing Power Control: Aave Governance will have the ability to change the collateral factor for future borrow transactions without affecting existing borrow positions or triggering liquidations. In the event that Aave Governance believes that a collateral factor should be lowered (i.e., to require more collateral for borrow transactions), then Aave Governance can vote on a proposal to do so in order to increase the overall health of the protocol, without affecting existing borrowers.
-
Risk Admins: V3 introduces the ability for Aave Governance to register entities on a “permitlist,” which will provide such entities the ability to alter certain risk parameters without requiring a governance vote. These entities can be DAOs (e.g., RiskDAO, Gauntlet) or automated agents that can build on top of this feature to react automatically in the event a certain invariant is broken. Any entity added to the “permitlist” must be added through the typical governance proposal process.
-
Price Oracle Sentinel: The Sentinel feature has been specifically designed for Layer 2 protocols to handle eventual downtime of the sequencer (but can be extended to handle other cases, even on L1s, in the future). It introduces a grace period for liquidations and disables borrowing under specific circumstances, as decided upon by Aave Governance in response to a community proposal.
Decentralizing the addition of new assets
V3 introduces a new concept of “Asset Listing Admins.” With this feature, Aave Governance can create and grant rights to any entity, even smart contracts, to implement new strategies to add assets to the Aave protocol other than through an onchain vote. This will allow builders to create custom asset listing strategies which can be designed to bring true permissionless asset listing.
Other Features
-
Features that involve token transfers (e.g., supply, repay) support EIP 2612 permit (important for Layer 2 deployments);
-
EIP 712 signature will be supported for credit delegation;
-
Users can repay borrowed positions using aTokens instead of the originally-borrowed underlying asset;
-
Aave Governance can “permitlist” entities to access instant liquidity;
-
Aave Governance can reconfigure any fees provided to the Aave DAO Treasury on liquidations or instant liquidity transactions;
-
New flashloanSimple() reduces gas consumption up to 20% (the standard, fully featured function is still available);
-
Price oracle logic can provide generalized calculations on the base asset (i.e., no longer ETH only);
-
New interest rate strategy optimizes stable rate calculations (and eliminates the need for lending rate oracles);
-
Code reorganized to be more modular; compared to the V2 mono repository, the V3 code will be split into three different repositories – V3 core, V3 periphery, V3 deployments. This facilitates community contribution and deployments on different networks;
-
Smart contract refactoring to reduced code size (more margin for other changes in the future) → up to 100K optimizer runs!
And with all these new features, gas cost of all the functions still dropped by around 10-15% across the board!
V2 / V3 Code Compatibility
The V3 codebase is a separate and independent set of smart contracts, which are not compatible with the V2 smart contracts. However, the V3 code will be open sourced once all audits are complete, and a specific repository including a retro compatible version of V3 will also be released. This compatibility will allow the community to update the V2 contracts, if they choose to do so.
The V3 code will be open sourced, together with the main V3 repo, for deployment on the Ethereum, Avalanche, and Polygon networks once the V3 code becomes more battle tested.
Community Snapshot Votes
This ARC is intended to gather the community feedback on whether or not the community wants to move forward with Aave V3. A snapshot vote has been created here: Snapshot
In the event that the community votes affirmatively, the Aave Protocol V3 codebase audits being conducted by OpenZeppelin, Trail Of Bits, Peckshield and ABDK will be completed in or around the end of November. In addition, certain auditors may apply to the DAO to conduct additional audits of the code upon release before deployment.
If the community votes positively for deployment of V3 of the Aave Protocol, there will be a set of additional Snapshot votes for the community to determine the following:
-
Deployment Networks: Given the proliferation of efficient networks, including L2s, the community can vote on which networks V3 will be released initially. V3 will be able to be deployed on a maximum of three networks upon release, so the Snapshot will be a “ranking” vote.
-
The V3 code licensing: In light of the fact that the Aave Ecosystem is highly diffuse and decentralized, Aave Governance will decide what type of license will apply to the Aave Protocol V3 code before the code is released to the public. As far as we are aware, this is a first for the DeFi space!
-
The V3 Bug Bounty program: The community will decide on size, duration and scope of the Bug Bounty program, as well as who (e.g., the RiskDAO – see proposal here Proposal: Aave Risk DAO) will administer the program.
-
Retroactive funding: The community will also be able to decide whether to provide retroactive funding to those who contributed to the creation of V3, and how much funding to provide.
If the community votes to deploy V3, another ARC will provide additional details relating to each of the additional votes described above.
Once these votes determine the community decisions and the current audits are finalized, the deployments voted upon by the community can begin.
The features of V3 make it possible to execute—for the first time—a fully guarded launch, meaning that supply caps will be implemented on each asset at launch to ensure for a safe and helathy release of the V3 markets.
Conclusion
This ARC has focused on the new iteration of the Aave protocol and its main features. As described above, the community will decide on all the aspects of the release plan, including networks on which V3 will be released, the licensing of Aave V3 and the bug bounty program.
We cannot wait to see what the community discusses about, and decides on, this exciting new technological development!
