Introducing Aave V3


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. :ghost: :tada:

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 :cyclone:: allows assets to seamlessly flow between Aave V3 markets over different networks;

  • High Efficiency Mode :arrow_up:: allows borrowers to extract the highest borrowing power out of their collateral;

  • Isolation Mode :link:: limits exposure and risks to the protocol from newly listed assets by only permitting borrowing up to a specific debt ceiling;

  • Risk Management Improvements :closed_lock_with_key:: provides additional protection for the protocol through various risk caps and other tools;

  • L2-Specific Features :motorway:: designs specific to Layer 2 networks to improve user experience and reliability;

  • Community Contribution :man_dancing:: 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.:muscle:

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. :lock:

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 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! :tada:

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.:ghost: 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.:moneybag:

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.:star_struck:


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!:rocket::zap:


Congratulations; this is incredibly exciting news. In particular Portal; as it means liquidity can move more freely.

I want to clarify one thing:

This compatibility will allow the community to update the V2 contracts, if they choose to do so.

Are you saying that the V2 lending pools can be upgraded to become V3 pools? This would be disastrous for us. I hope that isn’t the intention!


Thanks! It was a lot of hard work and research.

Why it would be disastrous to upgrade the V2 pools? The features are completely compatible with the older version.


this is truly a work of art – huge props to the team to get this up. two thoughts:

will v2 staking need to be migrated to v3, and will staking be available on other chains?
what are the costs associated to shifting from v2 → v3 contracts for users?

Oh- would they be compatible? Perhaps I misunderstood:

The V3 codebase is a separate and independent set of smart contracts, which are not compatible with the V2 smart contracts

To me it sounded like V3 is not compatible with V2.

*If they are compatible, then I would be supportive!

a separate repo, with V3 code reworked to be compatible with V2 (some minimal features and gas savings sacrificed) will be released to allow the community to upgrade the V2 contracts to V3 without breaking interoperability and transparently to the users (no need to migrate)


This sounds extremely huge to me. Really great update and upgrade. In favor of voting yes.

1 Like

Is there a writeup on exactly how Portal will work? This seems like a big deal, but also appears to have a lot of trust assumptions when it comes to interop bridge usage.


@Emilio wow! This is truly exciting news.

A bunch of new developments, but most of all - a continuation to build and better Aave.

I was particularly intrigued by the Portal to:

This feature reminds me alot of this ask And is a testimony that Aave is listening to its users.

Aggregating a bridging function is a great way to guide new users to the Aave protocol and retain existing one’s with product stickiness.

This image is a great representation of the scope of this project. It allows for movement in-between popular Layer 1s, exploding Layer 2’s, and even Zk rollups - hats off, Aave.

Second - eMode. This is a great development for a range of users, different sizes and expertises.

For larger users - it is an opportunity to become more capital efficient and employ flash loans. For smaller ones, it encourages more borrowing and use of stable assets.

I enjoyed seeing developments for Governance as well. This is something we as a company,
Flipside are invested and interested in.

Giving Aave Governance more power creates greater participation and shows your commitment to the values and decisions of a DAO. With these new features, I hope to see more participation and proposals.

In terms of your auditors - how do you chose this list? It seems as previous auditors such as CertiK, SigmaPrime, and Consensys Diligence have been omitted from this list. Was the team unhappy with their performance or reputation - or is this decision cost based?

We are excited for the next stage of Aave - and support this wholeheartedly. We remain committed to improving protocols such as Aave one proposal at a time.

1 Like

If Portal will “allow users to move their own assets seamlessly from deployments of V3 over different networks” why not build that capability into the protocol and merge the liquidity across all Aave instances into one liquidity pool? That seems like the biggest scope possible for this tool, and something all protocols should aspire to eventually do. It need not bridge every single deposit, but rather only move coins in batches to equalize ultilisation rates between networks. Since utilisation rates are well below 100%, there should be enough slack in the system to make these transfers infrequent. This should equalise lending and borrow rates across all networks, which would be a massive win for DeFi.


this can be built on top. The feature has been implemented in the most minimalistic way possible for this reason - it opens up to many possibilities for builders to create, rather than locking in a specific implementation.


Super excited for the release of the technical white paper! I would be very interested to see our Portal works on a technical level. The risk mitigation features are also incredibly interesting. For example for a token like stETH, it may make sense to wait and list directly onto V3 and limit its use as a collateral asset to ETH on top of this once one-to-one redemption is enabled for stETH you can have a very high collateral factor because prices should track together. Regardless excited to see this come together!


Regarding the efficiency mode, would it allow borrowing 95% ETH against stETH collateral or only stETH against ETH collateral? It‘s not clear to me from the chart alone.


Nice to have you here @Hasu

As long as both stETH and ETH have been granted borrowing power in normal mode (ie their LTV is not 0) they automatically gain the eMode boost when added to the category. Therefore if both have borrowing power, you will be able to use them both as collateral with 95% ltv

Of course this is just an example - the actual eMode parameters are configurable by the Aave governance, and depending on the underlying network and oracle speed, the ltv in eMode might be higher or lower

For example i feel like 95% ltv would be a bit risky for the protocol on ethereum L1, but likely fine on Arbitrum or zkSync with faster oracles and cheaper transaction costs


So will governance be able to change the fees such that they can accrue to users/token holders? Where/who do the fees go to now?

1 Like

This is generally very exciting. I love Aave and will love even more being able to flow assets between markets on different networks, and curious to see more details about decentralizing the addition of new assets.

fees collected go in the Aave collector contracts, under control of the Aave governance (therefore Aave holders).
Currently holding 31M+ in various tokens (mostly stablecoins)

Here are the addresses

V2 ethereum

V1 ethereum



@Emilio This sounds amazing! A few questions:

  1. Isolation mode - multiple assets: it seems like the user will need to choose for this whole account what mode he’s using. What happens in the case of multiple isolated assets?
  • a. Will the user be able to borrow only against one of these?
  • b. If it is possible to borrow against multiple, and each asset’s borrow is isolated, wouldn’t it be possible to group the usual (less-risky) assets into their own isolation category and allow borrowing against them as well?
  1. Isolation mode - sub-accounts : if the user has to choose only one isolation asset (or no isolation) for this whole account, would a feature like sub-accounts (XORing last bits of address with sub-account ID, and only changing msg.sender validation) be possible to implement to prevent the overhead of manually managing multiple accounts for different “isolated” borrows?

  2. Portal - moving borrows as well: it seems that only the supplied assets can be bridged, are there thoughts about making it possible to move the borrowed assets along with the supplied ones? Perhaps creating an NFT with the whole position to be moved, and bridging that (so that lends and borrows can be minted and burned atomically on each side)?

1 Like

what is the process for making it on the permitlist?

Fantastic, great work and congrats to @Emilio and the whole Aave DAO and team!

In, this cross-chain feature will definitely improve our yield optimization across Ethereum & Polygon within the same integration – this would replace stand-alone strategies and provide a better UX for our end users.

As we did for the migration from v1 to v2, Aave v3 can be smoothly integrated into our protocol, removing any effort for our integrators.

We are thrilled to see it live and start the implementation throughout our DAO governance process, making v3 a solid downstream lender for our Best-Yield product :fire:

1 Like