Aave v4: Exploring New Features

•

What's new in @Aave v4? Complete breakdown of proposed Aave v4 features. - Unified Liquidity Layer - Fuzzy-controlled interest rates - Liquidity premiums - Non-borrowable collateral - GHO soft Liquidations & redemptions - Opt-in interest in $GHO Expected to launch in 2025. 🧵

Unified Liquidity Layer. With modularity in mind, IMHO the biggest (architectural) change in v4. A single liquidity layer is a more generalized version of a "Portal" feature introduced in v3, as it can be used by different modules (v4 borrow module, RWA, cross-chain borrows..).

The unified liquidity layer allows for easier liquidity migrations from previous protocol versions, i.e. no further liquidity fragmentation, just adding new modules. ULR also brings better support for natively minted assets (e.g. GHO).

Fuzzy-controlled Interest Rates. Rates will not be managed by governance nor PID controllers, but rather with onchain fuzzy logic. Both slopes and kink points (target utilization), will be auto-adjusted.

Liquidity Premiums. TLDR: Different borrow rates depending on the collateral asset risk. Each asset is assigned a risk factor from 0 to 1, resulting in a premium required to be paid as a borrower, on top of a ‘base rate’ (borrow rate for assets considered to be lowest risk).

Liquidity premiums should increase listings since the DAO would have the ability to charge more for riskier collateral assets. The protocol will technically be incentivizing 'stronger' collateral, aligning with the goal of the protocol being backed by liquid, low-risk assets.

Aave v4 Borrow Module. This module would be added on top of the unified liquidity layer, with some new UX, risk management, and safety features. 👇

Smart Accounts. Users will be able to create multiple 'smart accounts' and thus have many (isolated) positions in the Aave protocol *with a single EOA*. PS. This is available even now for Aave v3 with @defisaver which uses @safe as default smart wallet. twitter.com/definikola/status/1785727021127004613

Aave vaults. An option to have a non-borrowable collateral (i.e. no re-use of collateral) by depositing the collateral asset into the smart account, instead of the (unified) liquidity layer. This lowers the risk but implies no yield for collateral supplied.

Governance-related improvements. 1. Dynamic Risk Configuration. 2. Automated Assets Offboarding. 3. Automated Treasury Management.

Dynamic Risk Configuration. Changing the risk parameters like Liquidation Threshold can result in bad UX since it can trigger unexpected liquidations. At the same time, this needs to be adjusted regularly to maintain protocol safety (introducing governance overload). 👇

Dynamic Risk Configuration. In v4, a new config instance can be created, leaving existing borrowers hooked to the previous one. New config doesn’t fragment the liquidity due to the unified liquidity layer design and impacts only new users.

Automated Assets Offboarding. Currently, assets are offboarding by lowering LTV to 0 and LT (progressively, to avoid liquidations), which again requires multiple gov proposals. 👇

New offboarding mechanism utilizes dynamic risk config by creating new config with LT at 0. The LT for existing borrowers will gradually be reduced on every action performed on the asset in question (starting from the highest ones) until all the configs have LT at 0.

Automated Treasury Management. Sell DAO-earned tokens automatically to a preferred asset when a configured threshold is reached. This also reduces gov work.

Actions. Automatically adjust position based on governance/parameter updates. In my opinion, this should be left out of the core protocol and handled on a higher level (e.g. via @defisaver), mainly for simplicity purposes.

Liquidation Engine v4. Variable liquidation factor (% of collateral that can be liquidated in one tx), v3 had up to 50%. Liquidators can batch multiple liquidations with the same collateral/debt asset pair to increase their efficiency.

Liquidation Engine v4. Variable liquidation bonus - factually introducing reverse dutch auctions, linearly increasing the liquidation bonus (and decreasing the protocol fee) as the health factor of the position decreases.

Excess Debt Protection. Since v4 builds on the shared liquidity approach, the liquidity pool is safe as the riskiest asset it contains. To prevent excess debt, Aave v4 will automatically set the LTV to 0 for the specific asset, if/when it reaches the threshold for excess debt.

New Oracle Design. Not much info on this yet, but anticipating additional safety checks for @chainlink feeds with the goal of reducing trust assumptions.

GHO soft liquidations. Aave v4 will utilize a soft liquidation mechanism (aka Lending-Liquiding-AMM-Algorithm) pioneered by @CurveFinance’s $crvUSD. GHO will automatically earn interest if supplied as collateral. This is planned to be an opt-in feature for GHO borrowers.

In case of multi-collateral positions, users can choose which collateral asset to liquidate to GHO during soft liquidations (and which one to buy back). When combined with @defisaver liquidation protection, this can significantly decrease the risk of hard liquidations.

Stablecoin interest paid in GHO. If you supply e.g. USDC, you can choose to earn boosted interest in GHO thanks to the lower reserve factor. Interest is essentially converted to GHO by being collected to protocol controlled value (PCV) which directly backs the issued GHO.

Emergency Redemption Mechanism for GHO. In case of a prolonged and heavy GHO depeg, ERM can be triggered which enables redemption of the least collateralized positions in the system. This is similar to the LUSD redemption mechanism introduced in the Liquity v1 protocol.

Position tokenization & gas optimizations. - No more rebasing tokens, but rather optional tokenization using ERC4626 vaults. - Expected 30-50% reduction in gas fees in v4.

To sum up, I'd say that v4 takes some novel and useful mechanisms from the ecosystem, alongside a couple of new designs related to Aave protocol and GHO stablecoin. A single liquidity layer surely the biggest challenge. Also good to have most of the features optional.