Partnered With:

Comprehensively sort out the new functions of Aave V3

Read this article in 25 Minutes

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

Original title: "Introducing Aave V3"

Original source: Aave

Original compilation: Mr Unicorn, Block unicorn

In 2019, the first version of the Aave Protocol smart contract (“Aave Protocol”) was deployed to the Ethereum mainnet. V1 of the Aave protocol provides a way for users to provide and obtain liquidity autonomously, and earn income from any liquidity provided to the protocol.

In December 2020, the second version of the Aave protocol was deployed to provide Liquidity provisioning and liquidity access brings new functionality. One of the features of Aave protocol V2 is credit delegation, where users can choose between stable and variable interest rates on any borrow transaction, as well as certain gas optimizations and improvements.

About the same time, Aave Governance acquired management and maintenance of Aave protocol V1 and V2 , and is responsible for the continued development of the ecosystem surrounding the Aave Protocol (“Aave Ecosystem”).

The Aave ecosystem has grown organically over the past two years, supporting the success, security and Risk awareness operates. The community also supports the expansion of the Aave protocol from the Ethereum mainnet to the Polygon and Avalanche networks.

After two years of significant growth, this Aave Request for Comments (ARC) on Aave Governance Seeking community approval for a new iteration of the Aave protocol: introducing Aave V3.

ARC provides an overview of key features and solicits community feedback on potential Deploy to vote. The features associated with Aave V3 represent a major technological advancement for 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 be transferred seamlessly between Aave V3 marketplaces via different networks

Efficient Model : Allows borrowers to withdraw from their collateral Highest borrowing capacity;

Segregated model: by only allowing borrowing up to a specific debt ceiling Limit the exposure and risk of newly listed assets to the agreement;

· Risk Management Improvements : passed Various risk caps and other tools provide additional protection for the protocol;

· L2-Specific Features: Designed for Layer 2 networks to improve user experience and reliability;

·Community Contributions : Facilitate and incentivize community usage through a modular, well-organized codebase.

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

Technical advancement based on community feedback

Although the Aave protocol has been operating efficiently over the past two years and has grown tremendously, but community analysis of protocol functionality provides key areas for technical advancement:

· Capital Efficiency: V2 does not allow users to generate power (deployed on various networks within and/or across protocols) or borrow power Aspects optimize the assets provided to the Aave protocol. V3 solves this problem.

·Risk Mitigation Adjustments

·Risk Mitigation Adjustment: While the Aave Protocol currently has risk mitigation features that can be activated by the community through Aave governance, such as adjusting lending capacity and maintaining margins, additional features can improve the security inherent in the well-known Aave Protocol smart contracts. V3 solves this problem.

Decentralized

·Decentralization: Aave governance is robust and thriving through community members submitting proposals and creating sub-DAOs (GrantsDAO and RiskDAO). But for maximum decentralization, certain technical features will allow Aave Governance to further decentralize its functions by delegating to teams or other individuals. V3 solves this problem.

· Cross-chain promotion

span>: Through community efforts, the Aave protocol has been deployed on many networks, each with its own meaningful level of liquidity. But users cannot seamlessly transfer their own personal liquidity from an Aave protocol deployment on one network to another. V3 solves this problem.

V3 is designed to create a next-generation layer 0 DeFi protocol that can dramatically improve the user experience while delivering greater capital efficiency, a higher degree of Decentralization and further enhanced security.

Overview of Aave V3

V3 preserves the known Core concepts (aTokens, instant liquidity, stable rate lending, credit delegation, etc.), while providing new features that allow users to create new use cases for the Aave protocol, and may trigger a new wave of innovation from the community.

This overview describes the new elements of V3 at a level intended for wider use by the community . A technical white paper for developers will be published separately.

Portal

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

Its core functionality is very simple: user-supplied liquidity can be transferred from one network to another simply by burning it on the original source network (e.g. Ethereum) aToken while minting them on the target network (e.g., Polygon). Network interconnects built around this functionality are called ports.

Portal will be able to bridge Connext, Hop Protocol, Anyswap, xPollinate and other liquidity utilizing Aave protocol A solution to facilitate cross-chain interactions. Aave Governance will be able to grant any cross-chain protocol access to ports upon receipt of a proposal.

Efficiency Mode (eMode)

Efficiency Mode or "eMode" allows borrowers to ensure that they Ability to obtain the highest borrowing capacity with your own collateral.

This code allows Aave Governance to "classify" assets according to the following parameters:

·Lifetime Value

·Liquidation Threshold

· Liquidation Bonus

· Custom Price Oracle (Optional)

These factors set each of the different assets in V3 into a specific category. eMode gives borrowers more access to funds if they limit the assets they borrow by category. In other words, in eMode, borrowers can choose the asset class they want to borrow. A “class” typically refers to a group of assets pegged to the same underlying asset — for example, a USD-pegged Stablecoin, an ETH-pegged asset, etc.

If the user chooses to use the Aave protocol in eMode, when the user provides the same type of assets as the user's collateral, the loan Capacity (LTV) and Maintenance Margin (Liquidation Threshold) will be overridden by eMode class configuration to allow for higher capital efficiency.

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

97% lifetime value

98% liquidation threshold

2% Liquidation Bonus

There is no custom price oracle (oracle machine)

Karen chooses eMode Category 1 (Stablecoin)

Karen offers DAI (typically 75% LTV )

Karen can borrow other Stablecoins in category 1 (including DAI), whose borrowing capacity is defined by the eMode category (97%). As a result, Karen's capital efficiency increased by 22%.

Note: In this example, Karen could provide other non-Class 1 assets as collateral ; however, only assets belonging to the same eMode category selected by the user will have enhanced category-specific risk parameters. V3 eMode supports up to 255 categories.

New Risk Management Parameters

Isolation Mode

The "isolation mode" is designed to allow Aave Governance to develop risk mitigation functions when creating new asset markets on the protocol.

When community members submit a governance proposal to create a new asset market on V3, the proposal can Users seeking to list assets as “segregated collateral” so that users offering these “segregated” assets can only borrow Stablecoins that Aave Governance has “licensed” to borrow in segregated mode, up to a specified debt ceiling.

When a user provides "segregated assets" as collateral, the user can only use the assets as Collateral; even if users provide other assets to the protocol, users can only earn income through these assets and cannot use these assets as collateral.

In the example above, Chad provided $TOKEN2 as collateral. $TOKEN2 is a segregated 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 provided another asset — let’s say ETH — the V3 smart contract would not allow Chad to borrow against those assets, although Chad would still earn on the ETH provided. If Chad wants to use all assets as collateral and exit segregated mode, Chad can simply make a transaction to disable $TOKEN2 as collateral (subject to all the usual restrictions in smart contracts regarding collateral ratios, liquidations, etc.).

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

Risk management function

V3 technology provides Aave Governance with a further enhanced risk management mechanism , to prevent protocol bankruptcy:

· Supply and Borrow Caps: Aave Governance will be able to configure borrow and supply caps. Borrowing caps will allow governance to set limits on the amount of each asset that can be borrowed, while supply caps allow governance to vote to limit how much of a particular asset can be supplied to the Aave protocol. Borrowing caps minimize liquidity pool bankruptcy, while supply caps reduce the protocol’s risk to specific assets and help prevent attacks such as infinite minting or price oracle manipulation.

· Fine Borrowing Power Control: Aave Governance will be able to change the collateral factor of future borrowing transactions without affecting existing borrowing positions or triggering liquidation. If Aave Governance believes that the collateral factor should be lowered (i.e., borrowing transactions require more collateral), Aave Governance can vote on proposals to improve the overall health of the protocol without affecting existing borrowers.

·Risk Manager

·Risk Manager: V3 introduces Aave Governance's ability to register entities on a "permission list", which will enable these entities to change certain risk parameters without requiring a governance vote. These entities can be DAOs (e.g. RiskDAO, Gauntlet) or automated agents that can be built on top of this functionality to automatically react when an invariant is broken. Any entity added to the "approved list" must be added through the typical governance proposal process.

·Price Oracle Sentinel

span>: Sentinel feature designed for Layer 2 protocols to handle eventual downtime of the sequencer (but can be extended to handle other cases, even on L1 in the future). It introduces a liquidation grace period and prohibits lending under certain circumstances, as determined by Aave Governance in response to a community proposal.

Add new assets scattered

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

Other Features

· Functions involving token transfer (e.g. provisioning, redemption) support EIP 2612 permission (important for layer 2 deployment);

· Credit delegation will support EIP 712 signature;

· User ATokens can be used to replace the original borrowed underlying assets to repay the borrowed position;

· Aave Governance can "Allow" entities to obtain instant liquidity;

· Aave Governance can be reconfigured to provide Aave DAO Any fees for clearing or instant liquidity transactions from the Treasury;

new flashloanSimple() Reduced gas consumption by up to 20% (standard, full-featured features still available);

· Price oracle logic can provide generalized calculations of underlying assets (i.e. no longer just ETH);

· New interest rate strategy optimizes stable rate calculations (and eliminates the need for loan rate oracles);

· Code reorganization to be more modular; V3 code will be split into three different repositories - V3 Core, V3 Peripheral, V3 Deployment, compared to the V2 single repository. This facilitates community contributions and deployments on different networks;

Smart contract refactoring to Reduced code size (leaving more headroom for other future changes) → run up to 100K optimizers!

With all these new features, the gas cost for all features is still down about 10- 15%!

V2 / V3 Code Compatibility

The V3 codebase is a separate set of Smart contracts, not compatible with V2 smart contracts. However, once all reviews 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 the V2 contract if they choose to do so.

Once the V3 code is more battle-tested, the V3 code will be open-sourced along with the main V3 repository , for deployment on Ethereum, Avalanche, and Polygon networks.

Community Snapshot Poll

This ARC aims to collect community opinions on whether the community wants to advance Aave V3 feedback of. Snapshot poll created here: Snapshot 71

If the community votes yes, Audits of the Aave Protocol V3 codebase by OpenZeppelin, Trail Of Bits, Peckshield, and ABDK will be completed on or around the end of November. Additionally, some reviewers may request an additional review of the code from the DAO prior to release.

If the community votes in favor of the deployment of Aave Protocol V3, the community will have an additional set of Snapshot voting to determine the following:

· Deployment Network: given that includes L2 Proliferation of efficient networks including , the community can vote on which networks V3 to release initially. V3 can be deployed on up to three networks after release, so the snapshot will be a "ranking" vote.

· V3 Code License

·V3 Code License

span>: Given that the Aave ecosystem is highly decentralized and decentralized, Aave Governance will determine which type of licensing, if any, applies to the Aave Protocol V3 code. As far as we know, this is a first in the DeFi space!

· V3 Bug Bounty Program : The community will decide on the size, duration and scope of the bug bounty program, and who (e.g. RiskDAO - see proposal proposal here: Aave Risk DAO 9) will manage the program.

· Retroactive funding: The community can also decide whether to provide retroactive funding to those who contributed to the creation of V3, and how much money to provide.

If the community votes to deploy V3, another ARC will provide additional details related to each additional vote above.

Once these votes determine the community's decision and the current audit is complete, the community voted Deployment is ready to begin.

The features of V3 make it possible for the first time to perform a fully protected release, which means that the Supply caps are enforced on each asset at launch to ensure a safe and healthy launch for the V3 market.

Conclusion

The ARC focuses on new iterations of the Aave protocol and its main features. As mentioned above, the community will determine all aspects of the release plan, including the network for releasing V3, 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 technology development!