[ARFC] BGD. Aave v3.7

Development
1

Aave v3.7
Aave v3.71920×892 209 KB

Summary

Introducing Aave v3.7, a new version of Aave v3 (currently v3.6) focused on non-invasive simplification of the protocol. It includes the following changes and features:

  • Simplification of eModes’ configuration, adding an isolated flag.
  • Removal of isolated collaterals and borrowable in isolation, features not useful anymore.
  • Removal of the L2 sequencer oracle.
  • Explicit removal of the flow to drop reserves, making the reserves list append-only.
  • Small improvements on liquidation calculations.
  • Multiple improvements/simplifications (not on-chain) of the codebase peripheral infrastructure.


Context

On previous upgrades (v3.4/5, v3.6), we have commented with the community that, while future upgrades should not be categorically discarded, they will naturally be much smaller than previous ones, focusing on surgical changes and simplification oriented toward maintainability.

v3.7 follows exactly that approach, being a smaller upgrade from code size and invasiveness perspective, and focusing on simplifying the protocol to its current and envisioned usage.

We believe this is an important upgrade to reduce unnecessary maintenance overhead and modelling work. Especially considering that Aave will have three production protocols running in parallel very soon, with the upcoming v4.



Aave v3.7 changes


1. eMode isolated configuration

Adding a new bool isolated flag on eMode categories, that when isolated = true:

  • Only assets explicitly listed in the eMode’s collateralBitmap contribute LTV. All other assets the user has supplied are treated as LTV-zero (they still contribute to the liquidation threshold and health factor, but cannot back new borrows).
  • Users with non-eMode collateral enabled cannot enter the isolated eMode — entry is blocked because those assets would become LTV-zero.
  • Users already inside an isolated eMode cannot enable non-eMode assets as collateral.

→ Motivation for the change

In the current version of Aave (v3.6), eMode categories define a collateralBitmap that determines which assets receive the eMode’s enhanced LTV/LT parameters. However, assets outside the bitmap still contribute their regular (non-eMode) LTV. This means a user in an “ETH-correlated” eMode could still borrow against non-ETH collateral at the asset’s base LTV, defeating the purpose of the eMode’s risk isolation.

The workaround in v3.6 is for governance to manually set ltvzeroBitmap bits for every non-eMode asset. Even if very explicit and functional, this is operationally burdensome: it requires an LTV0 of multiple assets on listing.

The isolated flag solves this by automatically treating all assets outside the collateralBitmap as LTV-zero, removing the need for per-asset manual maintenance (but still allowing granularity via LTV0 on eMode).



2. Removal of isolated collateral/borrowable in isolation configurations

Aave v3.7 removes two configuration features introduced on v3.0:

  1. Isolation Mode - Restricts users to a single collateral asset with a debt ceiling and limited borrowable assets
  2. Siloed Borrowing - Prevents users from borrowing multiple assets if one was marked as siloed

→ Motivation for the change

  • No current need for those modes.
    • Siloed borrowing: never actively used in production.
    • Isolated collateral: very few assets configured with debt ceilings (across all networks, the majority of assets in isolation are LTV0), and no real need to do so by risk teams going forward, versus other mechanisms.
  • v3.6 (and v3.7 isolated eMode) introduces simpler mechanisms to achieve similar control. E.g., siloed borrowing can be achieved reproduced using borrowing enabled/disabled on eModes, while collateral isolation can be achieved in a similar way with eModes.
  • v3 codebase complexity reduction. Simplifies in a very non-invasive way multiple components of the protocol, using the validation logic where the main change resides. This translates into simpler auditability/maintainability and reduces the overall attack surface.
  • Simplifies the reasoning model and configuration levers for risk and growth providers.


3. Removal of L2 sequencer uptime oracle

This feature was used on some of the L2 deployments to check whether the L2 sequencer was online, and enforce a grace period to users after recovery, with the following:

  • Borrowing was blocked while the sequencer was down or the grace period had not elapsed (isBorrowAllowed()).
  • Liquidations were blocked under the same conditions (isLiquidationAllowed()), with a special exception: liquidations were always permitted when a position’s health factor fell below MINIMUM_HEALTH_FACTOR_LIQUIDATION_THRESHOLD (0.95), regardless of sentinel status.

Both checks are removed. Borrows and liquidations now proceed without sequencer uptime gating.


→ Motivation for the change

Historically, sequencer uptime detection on L2s has been very ad-hoc, with each network having different mechanisms and reliability characteristics for reporting sequencer status. This lack of standardisation led to infrastructure differences across deployments/chains, hence to high-maintenance overhead both on the Aave side and middleware like Chainlink, and to false positives. That is very problematic to the system because false positives can, in the worst case:

  • Block liquidations: allowed unhealthy positions to deteriorate further, increasing protocol risk during the exact moments when liquidations were most needed.
  • Block borrows: prevent normal user activity during periods where there was not really any issue on the network.

In summary, our evaluation of risk versus value tells us that the right decision is to remove the mechanism, which, similar to other changes included in this v3.7, improves simplicity and auditability, while reducing the attack surface.



4. Removal of drop reserve flow

This includes the dropReserve() methods from both PoolConfigurator and Pool contracts, and logic directly related to those.

However, we keep untouched some (now redundant) validations across the codebase, as they really have no impact, but reduce the changes surface.


→ Motivation for the change

The functionality to drop reserves has never been used, and there is no plan to do so. Also, we know it should enforce extra validations that are not currently in the code, and that we will not approve a governance proposal to use it without a deep review of the flow and security procedures. So factually, it is a non-active/deprecated part of the code, which we are making more explicit.

This also adds value from the same angle as other features in this v3.7: simplification, as now the list of reserves will be append-only.



5. Small precision improvements on liquidation

Post v3.5 (adding directional rounding to the protocol), we detected some minor part of the protocol logic on liquidation that could be improved even further in terms of rounding, without being too invasive. These are included in this v3.7 proposal, with details to be disclosed once we finish our internal development/security evaluations.


→ Motivation for the change

Improving the precision of the math in the protocol.



6. Misc simplifications

In parallel with (and outside of) numbered releases of Aave (but async to them), we do different maintenance tasks on non-core protocol components in the Aave v3 Origin repository.

Aside from other minor changes, we have been doing the following high-level changes since the v3.6 release.


→ Motivation for the change

General simplification of the Aave v3 Origin repository, to reduce global compilation time or reduce inconsistency on dependencies. Basically, a continuous improvement of maintainability.



Next steps

  1. Create an ARFC Snapshot for the upgrade of all Aave v3 instances to Aave v3.7, after some days of discussion in this forum.
  2. Advance on security procedures for v3.7.
  3. On-chain AIP creation, for the Aave governance to upgrade all pool instances across all networks.
7 Likes