AAVE v3 Key Features

Publish on: Classify at:
Words: 918 Read:≈ 5min Views:
Summary
The main features introduced in AAVE v3.

The AAVE v3 codebase had already been audited and was close to release when this post was written. This version focused mainly on several themes:

  • capital efficiency
  • risk-control strategy
  • decentralization
  • cross-chain support

The AAVE v3 contracts are open source:

https://github.com/aave/aave-v3-core

Let’s look at the major improvements this release introduced.

Features

Compared with AAVE V2, the main features of V3 are:

  • Portal
  • eMode
  • Isolation Mode
  • improved risk management
  • L2-focused capabilities
  • community contributions

Technical Progress Driven by Community Feedback

Although the Aave protocol had already worked well and grown significantly over the previous two years, community feedback played a very important role in driving AAVE forward:

  • Capital efficiency: V2 did not let users optimize supplied assets as effectively, whether in terms of yield generation within or across protocols and networks, or in terms of borrowing power. V3 addresses that.

  • Risk-control tuning: The Aave protocol already had risk parameters that governance could adjust, such as borrowing power and safety margins, but additional mechanisms could improve the protocol’s built-in security assumptions. V3 addresses that too.

  • Decentralization: Aave governance was already active and healthy, with community proposals and the creation of sub-DAOs such as GrantsDAO and RiskDAO. But some additional technical features make it possible to decentralize even more functionality through delegation.

  • Cross-chain: Through community effort, Aave had been deployed to many networks, each with its own pool of liquidity. But users could not move their personal liquidity seamlessly from one network to another. V3 addresses that.

V3 was designed to become the next generation of base-layer DeFi infrastructure, significantly improving user experience while also delivering higher capital efficiency, stronger decentralization, and better security.

Portal

Portal diagram:

portal

Portal allows users to move assets seamlessly across multiple networks. For example, a user can burn aTokens on Ethereum and mint them on Polygon. Conceptually this is similar to other cross-chain liquidity mechanisms, though the underlying technical design deserves a deeper look.

eMode

eMode diagram:

emode

A simple example: under eMode, if you supply wBTC and only borrow renBTC, your LTV can go as high as 97%, the liquidation threshold can be 98%, and the liquidation penalty can be 2%. In other words, when users borrow within a tightly correlated asset category, capital efficiency goes up while risk goes down.

The underlying idea is to group assets into categories. There can be up to 255 categories.

For example, one category may contain stablecoins such as USDT, USDC, and DAI. In that mode, a user who supplies USDC and borrows DAI may get an LTV of 97%, whereas the normal mode might only allow 75%. That immediately increases capital efficiency by 22 percentage points.

Of course, users can still supply assets outside the chosen category, but those assets only receive the normal-mode LTV treatment.

New Risk-Management Parameters

Isolation Mode

Isolation Mode

The goal of Isolation Mode is to reduce risk when governance lists new assets on Aave.

When the community submits a governance proposal to list a new asset, that asset can be marked as “isolated collateral”. Users who supply isolated assets as collateral are only allowed to borrow governance-approved stablecoins, and their borrow amount is capped by a protocol-defined debt ceiling.

When a user supplies an isolated asset as collateral, that asset is the only collateral they may use. Even if the user also supplies other assets to the protocol, those additional assets only earn interest and cannot be used as collateral.

Bug Bounty and RiskDAO

RiskDAO: https://governance.aave.com/t/proposal-aave-risk-dao/4729

Other Features

  • Token-transfer-related functions such as supply and repay support EIP-2612 permits, which is especially useful on L2.
  • The protocol supports EIP-712 signatures.
  • Users can repay debt using aTokens instead of only the original borrowed asset.
  • Aave governance can permit-list specific entities for instant liquidity access.
  • Aave governance can reconfigure fees charged for liquidations or instant-liquidity transactions, directing them to the Aave DAO treasury.
  • The new flashloanSimple path can reduce gas usage by up to 20%, while the full-featured standard flash-loan function remains available.
  • Oracle logic can now support more general base-asset calculations and is no longer limited to ETH-denominated assumptions.
  • The new interest-rate strategy optimizes stable-rate calculation and no longer requires a lending-rate oracle.
  • The codebase has been restructured into more modular repositories. Compared with the monolithic V2 repository, V3 is split into v3-core, v3-periphery, and v3-deployments, which helps community contributions and multi-network deployment.
  • Smart contracts were refactored to reduce code size, leaving more room for future upgrades and allowing optimizer settings up to 100K runs.

Even with all of these new features, the overall gas cost still decreased by roughly 10% to 15%.

Code-Level Impressions

Note: this section reflects my quick first impression after browsing V3.

  1. Gas optimization

    Solidity was upgraded to 0.8.10. Several core math components were rewritten, and much more assembly is used to save gas.

  2. New functionality

    • eMode
    • isolation mode

  3. Naming changes

    For example:

    • deposit was renamed to supply
    • LendingPool.sol was renamed to Pool.sol
    • core business logic was moved further into libraries/logic, including the new eMode, isolation, and bridge logic

  4. Peripheral functionality moved into separate repositories

    Similar to Uniswap, there is a dedicated periphery repository. Deployments also appear to live in a separate repository. When installing aave-v3-core, one dependency named @aave/deploy-v3 is pulled in, but at the time of writing it was not easy to locate directly. Related issue: https://github.com/aave/aave-v3-core/issues/625

  5. Protocol licensing changes

    If you are planning to fork AAVE v3, note that its licensing appears more similar to Uniswap v3. See: https://github.com/aave/aave-v3-core/blob/master/LICENSE.md

    In practice, though, most projects still fork Compound far more often than AAVE.

  6. The core architecture has not changed dramatically

References

https://governance.aave.com/t/introducing-aave-v3/6035

https://github.com/aave/aave-v3-core