BGD. Aave v3.2: Liquid Emodes

v3.2-banner


Summary

Introducing Aave v3.2, a new version of Aave V3 (currently v.3.1) including two important changes:

  • A new feature: Liquid eModes.
  • The removal of all deprecated stable rate logic.


Context

July 27th, Aave governance proposal 132 activated Aave v3.1 across all active networks. This currently active version of the Aave protocol was focused on security improvements (e.g. introducing virtual accounting), changing the architecture of the interest rate strategies, and multiple other updates to improve the operational efficiency of the system.

Additionally, with Aave v3.1 we introduced Aave v3 Origin, a new repository for the Aave protocol (Foundry-based) to serve as the cornerstone to release further post-v3.1 versions faster while keeping maximum security standards.

One and a half months later, as a result of previous groundwork with v3.1 and Origin, we are glad to present to the community this new Aave v3.2 version.



Aave v3.2

The changes included in Aave v3.2 are more isolated than those of v3.1, and of different nature. While removing stable rate-related logic is more on the maintenance/codebase cleanup side, liquid eModes is a total user-facing and powerful feature.



1. Liquid eModes


Aave v3 introduced the concept of eMode (efficiency mode), an abstraction within the pool for configuring groups of assets with more capital-efficient risk configurations (LTV, Liquidation Threshold). This unlocked use cases like native high-leverage or even strategies between stablecoins. eMode could be deemed one of the first experiments in DeFi at scale with the concept of pools of assets within pools of assets.

The eMode feature has seen since then tremendous success, enabling use cases like ETH-correlated eMode, allowing for higher than default risk parameters on ETH LSTs/ETH positions (or MATIC, AVAX with their LSTs). However, the eMode feature always had some room for improvement, that way truly unlocking even more powerful use cases and flexibility on Aave.

A known technical limitation of the initial iteration of eMode is the following: a single eMode is optionally assigned to assets listed on Aave. That means that if let’s say WETH is assigned eMode 1 eligibility (ETH-correlated, with ETH LSTs), WETH can’t be eligible for any other eMode.

In different scenarios, this is an important constraint, as currently is not possible to have on the same Aave pool an eMode with wstETH and WETH, together with a different eMode with weETH and WETH, as WETH can only be in one of them at the same time.




The new Liquid eMode feature of Aave v3.2 removes the previous constraint: an asset listed on Aave can be eligible for different eModes, and then it only depends on the user to choose which eMode he wants to enter to.


liq-emode-diagram
eMode, before and after v3.2


For example, with liquid eModes, a possible configuration not doable before would be:

  • eMode 1, with wstETH, weETH and WETH.
  • eMode 2, with wstETH and WETH.
  • eMode 3, with weETH and WETH.
  • eMode 4, with WETH and GHO.

So then, user A holding the wstETH and weETH collaterals, could borrow WETH at high LTV. User B holding only wstETH could borrow WETH at high (but different) LTV. User C holding only weETH could similarly borrow WETH at a different LTV than the previous two eModes. User D could have a position with WETH collateral and GHO borrowings.

This doesn’t stop there, as more sophisticated configuration strategies could be adopted, like:

  • eMode for only WETH and stablecoins.
  • eMode for onboarding less mature LSTs, without requiring them being together with all major LSTs.

For extra configuration flexibility, liquid eModes also allow now to flag an asset as only borrowable, only collateral, or both, in the context of an eMode. For example, in a hypothetic eMode with only wstETH and WETH, the normal configuration would be wstETH as only collateral and WETH as only borrowable, fully focusing on the wstETH leverage use-case.




In addition to the previous main characteristics of liquid eModes, we have also introduced the following minor changes to the system:

  • Now the protocol doesn’t enforce the LTV/LT of an asset being lower outside its eligible eModes. However, the validation gets stricter on the user side when entering any eMode (or from no-eMode): Health Factor is always validated to never allow the user to get his position below 1HF post-eMode swap.
  • The protocol previously had an eMode-specific price feed, to be used to price with the same feed all assets on an eMode. However, this has never been used, and its utility (in its current form) is quite arguable. Therefore, we have to remove it from the data structure to allow more efficient storage allocation.
  • On a technical note, before 3.2, the eMode of an asset was stored on the asset’s data itself. Now, the eMode data stores all the necessary information for the protocol to understand which assets are eligible on that eMode.
  • Similar as with previous upgrades on Aave v3, we have tried to follow a non-invasive approach when adding the feature, only touching/refactoring those pieces that were clearly necessary, but without doing any big high-level refactoring of the pool.

Security procedures

Similar as with any other Aave upgrade, we have applied multiple security measures that will be finished before the activation stage via governance proposal. Detailed information will be published once they are finalised.



2. Stable rate logic cleanup


Part of the v.3.1 upgrade was the addition of a function swapToVariable() for anybody to permissionless off-board stable borrowings to variable, that way factually deprecating completely stable rate on Aave pools.

With currently no active stable rate position (moved via the Dolce Vita program by the service provider ACI), we have executed a follow-up step on the process: completely removing the stable rate logic from the protocol, which one hand simplifies the codebase, but on the other hand it also slightly optimises gas consumption and logic flows.

Even if fairly extensive change, this cleanup is non-invasive in how the protocol operates given that there are no active stable rate positions. All technical details about it will be included in the upcoming v3.2 release technical changelog.


Security procedures

Similar as with any other Aave upgrade, we have applied multiple security measures that will be finished before the activation stage via governance proposal. Detailed information will be published once they are finalised.



Next steps

  1. Create an ARFC Snapshot for the upgrade of all Aave v3 instances to Aave v3.1.
  2. In parallel, finish the preparations of the AIP payload for the upgrade, security procedures of v3.2 and publishing the results.
  3. On-chain AIP creation, for the Aave governance to upgrade all pool instances across all networks.
15 Likes

Another great upgrade to the protocol. Especially given that eModes have been very successfull for Aave and it’s user. With liquid eModes way more strategies will be possible. Excited to see what will be build on top of this.

1 Like

Following the next steps previously outlined, we have created an ARFC Snapshot for the pre-approval of the Aave v3.2 upgrade.
Participate :ghost: https://snapshot.org/#/aave.eth/proposal/0x68ce69b5e71df1d77c2ad814a5d41162a40be54473576ff590d0b1bb5afde4a7

During this upcoming week, we will also publish the final codebase, together with all the security procedures that have been applied on it.

1 Like

As an update to the community regarding Aave v3.2.


Aave v3.2 codebase and documentation

The Aave v3.2 codebase is publicly available on Aave v3 Origin https://github.com/aave-dao/aave-v3-origin/tree/v3.2.0.
Following good practises, will only be merged to the main branch of the repository if/once the Aave Governance approves the upgrade of the Aave production system.


As additional documentation, we have included the following:

  • A document including a detailed overview of all changes, migration approach and misc considerations HERE.
  • Code diffs between the Aave v3.1 protocol in production for the main components changing (and some peripheral ones): HERE and HERE.
  • Gas consumption diff between the production Aave v3.1 and Aave v3.2, HERE.



Aave v3.2 security

All security procedures have been finished at the moment, including internal and external ones.

Being a protocol upgrade, the selection of external parties for the two components included into v3.2, have taken into account security redundancy, but also expertise and previous knowledge by those parties of Aave and similar systems.

The result is the following:

  • For stable rate removal:

    • Security review by Certora, together with adapting properties whenever required. REPORT.
    • Security review by Enigma Dark (joint report including Liquid eModes too) REPORT
  • For Liquid eModes:

    • Security review by Certora, together with adapting properties whenever required. REPORT.
    • Security review by Enigma Dark (joint report including stable rate removal too). REPORT
    • Security review by Oxorio. REPORT
    • Security review by Pashov Audit Group. REPORT

We are satisfied with the outcome of those reviews, both from current security partners like Certora, and from new ones.




Activation stage

The next and final step for activation of Aave v3.2 will be the creation of an on-chain governance proposal (AIP), for the Aave governance to vote on and execute the upgrade.
Submitted to final changes, the proposal can be found on https://github.com/bgd-labs/aave-proposals-v3/pull/466.
In addition to the upgrade itself, the proposal payload will include a reimbursement of $76’000 denominated in GHO, to cover the cost of extra external security procedures incurred.

Our intention is to create it as soon as we finish all final reviews.

3 Likes

Following the timeline, we have create a governance proposal for the activation of Aave v3.2 across all active networks.

Voting will start in approximately ~24h, participate :ghost:
https://vote.onaave.com/proposal/?proposalId=178

3 Likes

Hey bgdlabs,

Thanks for this upgrade, it seems at first glance the most impactful addition is the inclusion of GHO and WBTC inside an ETH related e-mode.

Could you confirm or correct this statement?

  • All existing ETH e-mode positions will begin in e-mode “1” with their respective collateral and borrow assets enabled.

I noticed the graphic contains different e-modes than what you proceed to state. For example, in the graphic e-mode “3” is shown to hold wstETH and wETH, but then you state e-mode “3” contains weETH and WETH.

What is the starting config for the different e-modes? For example in the e-mode “3” of the graphic, are wETH and wstETH enabled both as borrow and collateral by default?

This illustration is just an example of what is possible. The proposal itself does not alter or add any eMode - it just upgrades the pool to have new functionality.

1 Like