Get a sneak peek, what new features will Aave's upcoming V3 version have?

Author: Emilio, Aave Developer
Translation: Block unicorn

In 2019, the first version of the Aave protocol smart contracts ("Aave Protocol") was deployed on the Ethereum mainnet. Aave Protocol V1 provided users with a way to autonomously supply and acquire liquidity, earning yields from any liquidity provided to the protocol.

In December 2020, the second version of the Aave Protocol was deployed, bringing new features for liquidity provision and access within the DeFi ecosystem. One of the key features of Aave Protocol V2 is credit delegation, allowing users to choose between stable and variable interest rates for any borrowing transaction, along with certain gas optimizations and improvements.

Around the same time, Aave Governance gained management and maintenance over Aave Protocol V1 and V2, responsible for the ongoing development of the ecosystem surrounding the Aave Protocol ("Aave Ecosystem").

The Aave Ecosystem has organically developed over the past two years, supporting the successful, secure, and risk-aware operation of the Aave Protocol. The community has also supported the expansion of the Aave Protocol from the Ethereum mainnet to the Polygon and Avalanche networks.

After significant growth over these two years, this Aave Governance Proposal (ARC) seeks community approval for a new iteration of the Aave Protocol: the introduction of Aave V3.

The ARC provides an overview of the main features and requests community voting on potential deployment through Snapshot. As we know today, the features associated with Aave V3 represent a significant technological advancement for DeFi liquidity protocols.

As discussed more comprehensively below, Aave V3 introduces the following features (among others):

• Portal: Allows assets to flow seamlessly between Aave V3 markets across different networks;

• Efficient Mode: Enables borrowers to extract the highest borrowing capacity from their collateral;

• Isolation Mode: Limits exposure and risk to the protocol by only allowing borrowing up to a specific debt ceiling for newly listed assets;

• Risk Management Improvements: Provides additional protection to the protocol through various risk ceilings and other tools;

• L2-Specific Features: Designed specifically for layer two networks to enhance user experience and reliability;

• Community Contributions: Facilitates and incentivizes community usage through a modular, well-organized codebase.

These features make V3 the most powerful and efficient DeFi liquidity protocol ever designed.

Technical Advancements Based on Community Feedback

Although the Aave Protocol has operated efficiently and achieved significant growth over the past two years, community analysis of the protocol's features has identified key areas for technical advancement:

• Capital Efficiency: V2 did not allow users to optimize the assets provided to the Aave Protocol in terms of yield generation (within the protocol and/or across various networks). V3 addresses this issue.

• Risk Mitigation Adjustments: While the Aave Protocol currently has risk mitigation features that can be activated by the community through Aave Governance, such as adjusting borrowing capacities and maintaining collateralization, additional features can enhance the inherent security of the well-known Aave Protocol smart contracts. V3 addresses this issue.

• Decentralization: Aave Governance is robust and thriving through community members submitting proposals and creating sub-DAOs (GrantsDAO and RiskDAO). However, to maximize decentralization, certain technical features will allow Aave Governance to further decentralize its functions by delegating to teams or other individuals. V3 addresses this issue.

• Cross-Chain Facilitation: Through community efforts, the Aave Protocol has been deployed on many networks, each with its own meaningful levels of liquidity. However, users cannot seamlessly transfer their personal liquidity from one network's Aave Protocol deployment to another. V3 addresses this issue.

The design of V3 is prepared to create the next generation of zero-layer DeFi protocols that can significantly improve user experience while providing higher capital efficiency, greater decentralization, and further enhanced security.

Aave V3 Overview

V3 retains the core concepts known in the Aave Protocol (aTokens, instant liquidity, stable rate borrowing, credit delegation, etc.) while providing new features that allow users to create new use cases for the Aave Protocol and potentially spark a new wave of community innovation.

This overview describes the new elements of V3 at a level intended for broader community use. A technical whitepaper for developers will be released separately.

Portal

The Portal allows users to seamlessly move their assets from V3 deployments across different networks.

Its core functionality is quite simple: liquidity provided by users can be transferred from one network to another by burning aTokens on the original source network (e.g., Ethereum) while minting them on the target network (e.g., Polygon). The network interconnection built around this functionality is called the Portal.

The Portal will be able to bridge Connext, Hop Protocol, Anyswap, xPollinate, and other solutions that leverage Aave Protocol liquidity to facilitate cross-chain interactions. Aave Governance will be able to grant access to any cross-chain protocol to the Portal upon receiving a proposal.

Efficient Mode (eMode)

Efficient Mode or "eMode" allows borrowers to ensure they can obtain the highest borrowing capacity using their collateral.

The code allows Aave Governance to "classify" assets based on the following parameters:

• Lifecycle Value

• Liquidation Threshold

• Liquidation Bonus

• Custom Price Oracle (optional)

These factors will set each different asset in V3 to a specific category. If borrowers restrict the assets they borrow by category, eMode provides borrowers with more avenues for capital acquisition. In other words, in eMode, borrowers can choose the category of assets they want to borrow. "Category" typically refers to a set of assets pegged to the same underlying asset— for example, stablecoins pegged to the US dollar, assets pegged to ETH, etc.

If users choose to use the Aave Protocol in eMode, when that user provides assets of the same category as their collateral, the borrowing capacity (LTV) and maintenance margin (liquidation threshold) will be overridden by the eMode category configuration to allow for greater capital efficiency.

The protocol defines eMode category 1 (stablecoins) as follows:

 97% Lifecycle Value

 98% Liquidation Threshold

 2% Liquidation Bonus

 No custom price oracle

Karen chooses eMode category 1 (stablecoins)

Karen provides DAI (typically has 75% LTV)

Karen can borrow other stablecoins in category 1 (including DAI), with borrowing capacity defined by the eMode category (97%).

Thus, Karen's capital efficiency increases by 22%.

Note: In this example, Karen can provide other non-category 1 assets 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 designed to allow Aave Governance to establish risk mitigation features when creating new asset markets on the protocol.

When community members submit governance proposals to create new asset markets on V3, the proposal may seek to list the asset as "isolated collateral," so that users providing these "isolated" assets can only borrow stablecoins that Aave Governance has "approved" for borrowing in isolation mode, up to a specified debt ceiling.

When users provide "isolated assets" as collateral, they can only use that asset as collateral; even if users provide other assets to the protocol, they can only earn yields from those assets and cannot use them as collateral.

In the example above, Chad provides $TOKEN2 as collateral. $TOKEN2 is an isolated asset with a maximum debt ceiling of $10 million, with USDT, DAI, and USDC as "borrowable" assets. After providing $TOKEN2 as collateral, Chad will be able to borrow up to $10 million in USDT, DAI, and USDC. Even if Chad provides another asset—say ETH—the V3 smart contract will not allow Chad to borrow against those assets as collateral, although Chad will still earn yields from the provided ETH. If Chad wishes to use all assets as collateral and exit isolation mode, Chad simply needs to perform a transaction to disable $TOKEN2 as collateral (subject to all usual restrictions regarding collateral ratios, liquidations, etc. in the smart contract).

When Aave Governance votes on a proposal to remove the debt ceiling associated with that asset, $TOKEN2 can also exit isolation mode.

Risk Management Features

The V3 technology provides Aave Governance with further enhanced risk management mechanisms to prevent protocol insolvency:

• Supply and Borrowing Ceilings: Aave Governance will be able to configure borrowing and supply ceilings. The borrowing ceiling will allow governance to set limits on the amount of each asset that can be borrowed, while the supply ceiling allows governance to vote to limit how much of a specific asset can be supplied to the Aave Protocol. Borrowing ceilings can minimize the risk of insolvency in liquidity pools, while supply ceilings can reduce the protocol's risk on specific assets and help prevent attacks such as infinite minting or price oracle manipulation.

• Fine-Grained Borrowing Power Control: Aave Governance will be able to change collateral factors for future borrowing transactions without affecting existing borrowing positions or triggering liquidations. If Aave Governance believes that collateral factors should be lowered (i.e., borrowing transactions require more collateral), Aave Governance can vote on a proposal to improve the overall health of the protocol without affecting existing borrowers.

• Risk Administrator: V3 introduces the ability for Aave Governance to register entities on a "whitelist," allowing these entities to change certain risk parameters without requiring governance votes. These entities can be DAOs (e.g., RiskDAO, Gauntlet) or automated agents that can build upon this functionality to automatically respond when a certain invariant is broken. Any entity added to the "whitelist" must be added through the typical governance proposal process.

• Price Oracle Sentinel: The Sentinel feature is designed for layer 2 protocols to handle final downtime of sorters (but can be extended to handle other situations, even on future L1s). It introduces liquidation grace periods and prohibits borrowing in specific situations, as determined by Aave Governance in response to community proposals.

Decentralized Addition of New Assets

V3 introduces the new concept of "Asset List Administrators." With this feature, Aave Governance can create and grant rights to any entity (even smart contracts) to implement new strategies for adding assets to the Aave Protocol, rather than through on-chain voting. This will allow builders to create custom asset listing strategies designed to achieve truly permissionless asset listings.

Other Features

• Functionality involving token transfers (e.g., supplying, repaying) supports EIP 2612 permits (important for layer 2 deployments);

• Credit delegation will support EIP 712 signatures;

• Users can repay borrowed positions using aTokens instead of the underlying assets originally borrowed;

• Aave Governance can "permit" entities to obtain instant liquidity;

• Aave Governance can reconfigure any fees for liquidation or instant liquidity transactions provided to the Aave DAO treasury;

• New flashloanSimple() reduces gas consumption by up to 20% (standard, fully functional features remain available);

• Price oracle logic can provide generalized calculations for underlying assets (i.e., no longer just ETH);

• New interest rate strategies optimize stable rate calculations (and eliminate the need for loan rate oracles);

• Code restructuring for greater modularity; compared to the single repository of V2, V3 code will be divided into three different repositories—V3 Core, V3 Peripheral, V3 Deployment. This facilitates community contributions and deployments across different networks;

• Smart contract refactoring to reduce code size (leaving more room for future changes) → up to 100K optimizers can run!

With all these new features, the gas costs for all functionalities have still decreased overall by about 10-15%!

V2 / V3 Code Compatibility

The V3 codebase is a set of independent smart contracts that are not compatible with V2 smart contracts. However, once all audits are complete, the V3 code will be open-sourced, and a specific repository containing a retro-compatible version of V3 will also be released. This compatibility will allow the community to update V2 contracts if they choose to do so.

Once the V3 code undergoes further real-world testing, it will be open-sourced alongside the main V3 repository for deployment on Ethereum, Avalanche, and Polygon networks.

Community Snapshot Voting

This ARC aims to gather community feedback on whether the community wishes to advance Aave V3. A snapshot vote has been created here: Snapshot 71

If the community votes in favor, the audit of the Aave Protocol V3 codebase conducted by OpenZeppelin, Trail Of Bits, Peckshield, and ABDK will be completed by the end of November or thereabouts. Additionally, certain auditors may seek additional audits of the code from the DAO before release.

If the community votes in favor of deploying Aave Protocol V3, there will be an additional set of Snapshot votes to determine the following:

• Deployment Networks: Given the surge of efficient networks including L2, the community can vote to decide which networks V3 will initially be released on. V3 can be deployed on up to three networks after release, so the snapshot will be a "ranking" vote.

• V3 Code Licensing: Given that the Aave ecosystem is highly decentralized, Aave Governance will decide what type of license (if any) applies to the Aave Protocol V3 code. To our knowledge, this is the first time in the DeFi space!

• V3 Bug Bounty Program: The community will decide the scale, duration, and scope of the bug bounty program, as well as who (e.g., RiskDAO—see proposal here: Aave Risk DAO 9) will manage the program.

• Retroactive Funding: The community may also 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 related to each of the above additional votes.

Once these votes determine the community's decisions and the current audits are completed, the deployment approved by community vote can commence.

The features of V3 make it possible to execute a fully protected release for the first time, meaning that supply ceilings will be implemented for each asset at launch to ensure a safe and healthy release of the V3 market.

Conclusion

This ARC focuses on the new iteration of the Aave Protocol and its main features. As mentioned above, the community will decide all aspects of the release plan, including the networks for releasing V3, the licensing of Aave V3, and the bug bounty program.

We can't wait to see what the community discusses and decides on this exciting new technological development!