Summary
This Temp Check proposed the development of Aave Protocol V4; an ambitious evolution and the next generation of Aave. Building on the success of V3, Aave V4 is proposed to be built together with the community with a new architecture that enhances modularity, reduces governance overhead, optimizes capital efficiency, and integrates innovations such as the Aave-native stablecoin GHO more seamlessly. The proposal also introduces ideas for innovative risk management tools and a more efficient liquidation engine, all designed to enhance user experience and security.
Aave Labs proposes to develop V4 as part of a wider Aave 2030 grant proposal in a transparent manner, involving the community in feedback and testing phases, with a timeline stretching from initial development in Q2 2024 to a full release by mid-2025. Aave Labs acts only as a technical contributor; the Aave DAO remains in charge of all deployments of the code bases that Aave Labs or other contributors produce.
Motivation
Introduction
Currently, Aave is the largest DeFi protocol - excluding (re)staking - and has experienced considerable growth in both its user base and total value locked (TVL). The launch of V3 in 2022 set the stage for growth by providing a variety of essential new features based on the community’s feedback. As the most significant upgrade to the protocol to date, V3 included an improved user experience, reduced gas costs, increased capital efficiency, new risk management tools, and targeted a seamless flow between V3 markets and different networks. At the time of this writing, Aave has a Market Size of $17B and is available on over twelve networks, with Ethereum being the largest market. V3 has operated successfully through multiple downward cycles thanks to its reliable liquidation engine and consistent risk management.
Our experience in designing and developing V3 and previous versions of the protocol gives us substantial insight and deep technological understanding. We are proud of our contributions to the Aave DAO and our successful track record supporting the community and its interests.
The following plan introduces the results of our research for Aave V4 to position the protocol for continued success. We hope the community will consider, discuss and ultimately embrace our ideas in this proposal, which we believe will keep Aave at the forefront of innovation in this space.
Over the past three years, since the inception of V3, Aave Labs has been analyzing on-chain user behavior and market tendencies to innovate around solutions to improve efficiency and security. The research on V4 builds on V3’s successful features such as eMode, Isolation Mode and granular risk management, while further increasing its integration with the Aave-native stablecoin GHO and introducing a number of other key capital efficiency features, substantially lower gas fees, enhanced UX and risk management innovations. Our ideas below propose a new, efficient architecture and modular design that has the goal of minimizing governance overhead, reducing risk, further optimizing capital efficiency and finally, with immutability in mind – creating a true, immutable and permissionless financial layer over the long run.
Proposed Features
V4: New Efficient Architecture
One of the key aspects of previous versions of Aave is the evolutionary nature of the three iterations of the protocol. All three versions stem from the same design principles and can be considered as a progressive evolution of the same architecture. By keeping a consistent architecture across different versions, integrators who build on Aave can continue their work without needing to adapt to major changes, which helps to prevent disruptions in their work. While beneficial, this limits innovation. Aave V4 would be built with a completely new architecture with an efficient and modular design, while minimizing the impact on third-party integrators.
Unified Liquidity Layer
The most important architectural change is the proposed introduction of a Unified Liquidity Layer. The liquidity layer generalizes the concept of Portals introduced by Aave V3 and enables a fully agnostic, independent and abstracted infrastructure for liquidity provisioning. The liquidity layer is proposed to manage supply/draw (borrow) caps, interest rates, assets, and incentives, allowing other modules to draw liquidity from it. In contrast to previous versions, the new liquidity layer abstraction is proposed to allow in the future for the Aave DAO to onboard new borrow modules and offboard old ones without needing to migrate liquidity.
This architecture allows adding or improving borrowing features (such as isolation pools, RWA modules, and CDPs) without changing the entire system or the liquidation module. It also avoids the problem of fragmented liquidity that older versions of the protocol had.
The liquidity layer is capable of natively supporting both supplied and natively minted assets, therefore providing better integration with GHO and other collateralized, Aave native, assets.
Fuzzy-controlled Interest Rates
Based on the same innovative concept currently in development for the interest rate management of GHO, Aave V4 is proposed to feature fully automated interest rates with the ability to adjust both slopes and kink points. Currently this is a governance controlled configuration that introduces governance overhead and sub-optimal capital efficiency.
Fuzzy rules are to be defined to actively control the kink point, moving it according to dynamic market conditions. Base interest rates are to increase or decrease depending on market demand, thus optimizing rates for both suppliers and borrowers.
The biggest advantage of using fuzzy logic to control the IR curves is the ability to extend the controller indefinitely, feeding as much input data as possible to optimize its behavior. We are actively researching with Chainlink to define a clear set of data feeds needed to implement the most capital efficient interest rate models ever designed on-chain.
Liquidity Premiums
Another novel feature of the liquidity layer is the proposed introduction of the Liquidity Premiums.
One glaring aspect that was observed in previous versions of Aave is the inability to price borrowing cost appropriately depending on the collateral composition. Riskier collaterals (either because of centralization dependencies or market risk) should be priced accordingly, while with the current iteration of Aave V3 this is not possible. Once an asset gets collateral status, it accesses a wide array of borrowable assets at the same pricing as all other collaterals. This is the case even when the collateral profile may not reflect its current risk profile.
Liquidity Premiums are proposed to introduce adjusted borrowing costs for borrowers based on their collateral composition. In this model, each asset will be assigned a risk factor that ranges from 0 to 1, and risk factors will be adjusted accordingly depending on dynamic risk conditions and other external risk factors. This will also introduce a Base Rate for borrowers using the strongest, lowest risk collateral (in the case of the Ethereum market, for example, ETH).
With fine-tuned risk management tools, Liquidity Premiums are capable of further increasing the capital efficiency of the protocol, bringing more yield to suppliers and lower fees to borrowers who use the strongest collaterals. With this capability, the protocol can provide borrowers with less risky collateral a better rate, attracting stronger collaterals to the protocol.
Aave V4 Borrow Module
With the new Unified Liquidity Layer, a new Borrow Module is proposed that builds on the strong fundamentals of Aave V3, further improving UX, risk management and safety. The V4 borrow module proposes a set of innovative features that will make the protocol even more safe and easy to use.
Vaults and Smart Accounts
V4 marks the introduction of the concept of Smart Accounts, which seek to solve one major UX problem with Aave V3 - the need to use separate wallets to manage positions in cases where a user is borrowing using eMode or isolated assets. The idea is that users will be able to create as many smart accounts as needed using only one wallet, greatly simplifying interactions with the protocol.
Smart accounts will also enable another major feature that fulfills a need often expressed in the Aave governance forum - Aave Vaults. Vaults are used to allow borrowing without requiring them to supply collateral to the liquidity layer. The collateral is instead deposited in the smart account, non borrowable and locked as long as the borrow position is active, or becomes subject to a liquidation event. This will allow users to further segregate risk, which will consequently reflect on yields for users who instead supply collateral to the liquidity layer. Smart accounts will be built completely on top of Aave V4, further showcasing the composability and flexibility of this new iteration of Aave.
Dynamic Risk Configuration
One of the main challenges with V3 risk management is that risk parameters (mainly what is identified as liquidation threshold) cannot be changed when market conditions change. The reason is that there is only one configuration instance per asset, and every change to the configuration affects both existing and future borrowers. Lowering the liquidation threshold is an action that can cause great discomfort (in the form of unwanted liquidations) and is currently handled very carefully. At the same time, it is a key parameter that should be updated frequently to reduce risk exposure, introducing governance overload.
Aave V4 proposes a dynamic configuration mechanism per asset, where users are “hooked” to the current configuration of an asset when a borrow takes place. If a new asset configuration is required, a new configuration instance is created. Existing users remain hooked to the previous configuration.
If the need arises, governance is designed to retain the ability to change previous risk configurations but with added dynamic configuration coupled with automated asset offboarding (see below), however, in the proposed framework the need for making such changes should be drastically reduced.
The ability to create independent risk configurations is proposed not only to improve risk management and reduce liquidity risk for suppliers, but also to allow offloading risk management functions to external entities without changing the trust assumptions; something that is not possible with the current version of the protocol. We are also researching with Chainlink to explore solutions for full automation of risk management. The idea is to involve utilizing ad-hoc, on-chain feeds to assess asset risk and dynamically adjust risk parameters through control theory or AI.
Automated Assets Offboarding
Together with Dynamic Risk Configuration, V4 proposes a new procedure to automate asset offboarding. Currently, offboarding assets is a long and governance-intensive procedure, where multiple proposals are needed to reduce the asset LTV to 0, progressively reducing the asset liquidation threshold to avoid massive liquidations, ultimately reducing its borrowing power to zero. With Aave V4, when governance triggers an automated offboarding operation, a new configuration is introduced which automatically reduces the liquidation threshold of the asset for new users to zero. Every action on the asset will trigger a progressive reduction of the historical liquidation thresholds, starting from the highest ones, until the liquidation threshold reaches zero for everyone and assets are officially offboarded as collateral. This will offer users a predictable offboarding plan that does not require governance proposals, drastically reducing governance workload.
Automated Treasury Management
Aave V3 currently collects Reserve Factor in a variety of assets, that require governance to reallocate to stablecoins or ETH periodically. Aave V4 will propose a reverse auction mechanism where every token collected through reserve factor can automatically be sold to any pre configured asset once a certain threshold is reached, reducing governance overload.
Actions
Aave V4 lets users set up custom automatic actions (Actions) in response to decisions made by governance.
For instance, if governance lowers the risk limit for borrowing on a certain asset (liquidation threshold), users can set up automatic actions to increase collateral for that asset or repay some of the asset to avoid liquidation. Actions limit the need for users to constantly check the governance forum for updates, as they can set custom actions that automatically adjust their position.
Liquidation Engine V4
While the liquidation engine in the current version of the protocol has proven reliability, a few key improvements are planned for Aave V4:
- A variable Liquidation Factor: enough to bring the position back to safety, to reduce the impact on borrowers compared to V3 where up to 50% of the collateral can be liquidated on liquidation event.
- A 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.
- Liquidation Strategies: different assets can use different liquidation engines to maximize efficiency.
- Multiple Parallel Liquidations: one key aspect that has been identified is that often multiple liquidations happen within the same block. The Aave V4 liquidation engine will allow batch liquidations targeting the same debt/collateral pair together to maximize efficiency for liquidators.
GHO soft liquidations: more on this later below.
Excess Debt Protection
One of the drawbacks of the shared liquidity model is the risk of contagion in case one asset accumulates excess debt. Excess debt can manifest in a variety of ways, mainly due to custody or liquidity risk. While custody risk can be mitigated through monitoring services, for example the Chainlink’s Proof of Reserve, already having been used in V3 on multiple occasions. However, there is currently no method for clearing excess debt resulting from liquidations.
Aave V4 proposes a novel mechanism to track insolvent positions and automatically account for the accumulated excess debt. A threshold for the excess debt can be set so that once the threshold is crossed, the asset automatically loses its borrowing power, preventing it from being used to spread the bad debt to other assets.
New Oracle Design
Together with Chainlink, we are conducting advanced research for an oracle design aimed at further reducing trust assumptions, detecting outliers and reacting accordingly. We will share more details on this research with the community once the design is ready.
Stronger GHO integration
Several new features are proposed to integrate GHO with Aave V4 more natively, improving UX and yield for stablecoin suppliers.
Native GHO minting
As mentioned above, the liquidity layer will be proposed to allow natively mint GHO more efficiently than with the current implementation.
GHO “soft” Liquidations
This mechanism is similar in concept as the liquidation model first pioneered by crvUSD. A Lending-Liquidating AMM (LLAMM) is proposed to ease liquidations. Liquidity is subdivided in ranges that can be chosen to address the conversion to GHO in market downturns and when buying back collateral in upturns. Compared to the crvUSD, Aave V4 design comes with three main advantages:
- Users can choose which collateral to liquidate to GHO within their basket of collaterals.
- Users can choose which collateral to buy back within all the assets available on the Aave Protocol (even assets not initially supplied).
- GHO will automatically earn interest (in markets where it can be supplied).
Stablecoin Interest Paid in GHO
V4 proposes a feature that allows suppliers to opt-in to receive interest payments in GHO, rather than the stablecoin they originally supplied. When suppliers choose this option, the interest payments from borrowers are converted into V4 Protocol Controlled Value (PCV), which directly backs the issued GHO.
The benefit of this feature for the protocol is that, by converting these payments into PCV, the protocol can enhance its capital efficiency. The capital acquired from borrows can be strategically utilized to bolster the stability of GHO, allocated to the GSM, reinvested within Aave itself, or used in other protocols to generate additional yield for the Aave DAO. Users can benefit from receiving GHO interest thanks to reduced reserve factors.
Emergency Redemption Mechanism
V4 proposes an Emergency Redemption Mechanism to handle situations of prolonged and heavy depegging of GHO. When the emergency redemption mechanism is triggered, collaterals of positions with the lowest health factor are gradually redeemed to GHO and their debt is repaid. This, in addition to automated interest rates, soft liquidations and GHO interest repayments, will help scale GHO while ensuring stability and reliability.
Deprecated Features
V4 proposes to streamline some older features from previous versions that were not used and were kept mostly for compatibility reasons. Their depreciation is expected to make the system simpler and more efficient. The affected features would be:
- Credit Delegation: Moved to the V4 Smart Accounts.
- Stable Rate: Deprecated. Borrow modules provide flexibility to define new variable rate strategies, and dynamic parameters enable better user experience and risk mitigation compared to stable rate re-balancing.
- Tokenization: Positions not natively tokenized. Tokenization is to remain optional and built using ERC 4626 vaults. Internal accounting modified to reflect this, with the removal of any exchange rate or scaled balance. This will reduce the risk of rounding errors and further improve the overall reliability of the protocol.
- LTV Configuration: With Dynamic Configuration (as there will be no need for a separate LTV parameter).
Gas Optimizations
Subject to the new proposed architecture and the removal of deprecated features, initial estimates show a reduction between 30 and 50% in gas fees with V4 technical innovations.
Specification
Development Plan and Course of Action
Aave Protocol V4 is currently in an advanced research phase. If community approval on the Aave 2030 proposal is received, the development for Aave V4 is planned as follows:
- Research phase completion: Q2 2024
- Development starts: end of Q2 2024
- First prototype expected: Q4 2024
- Code completion, auditing and release: Q1-Q2 2025
It’s important to highlight a few aspects of this timeline:
- Aave V3 has proven to be a robust protocol that has achieved remarkable growth — for instance, V3 Ethereum’s TVL grew from zero to $7 billion in less than a year. We see that V3 still has capacity to scale, serving as a solid foundation until V4 is ready for production.
- While certain innovations such as fuzzy-controlled interest rates and the new oracle design were researched with Aave V4 in mind, these solutions can be developed independently to be released in advance to function with Aave V3, which is looking to have a new version (3.1) developed by BGD Labs to be released in production soon.
- With V4 and the community required approach to funding, Aave Labs plans to build in public. The idea is to release an initial prototype and finalize its implementation, conduct audits and security assessments with the code accessible to everyone. This will allow community engagement and gathering of feedback, which will result in producing safer and more reliable code.
- While V4 is already in an advanced stage of research, some of the features described above might become subject to changes, be reworked or removed if unexpected development challenges arise.
- Aave Labs maintains an unwavering commitment to security and responsible development. We aim to adhere to the outlined timeline, bearing in mind that prior versions of the Aave Protocol have undergone extensive battle-testing over time. Our plans undergo comprehensive audits, including formal verification, to ensure the highest security standards. While we endeavor to meet the deadlines outlined above, our priority remains the safety and reliability of the protocol, allowing for flexibility to accommodate thorough review, auditing processes and unexpected findings.
Next Steps
This Temp Check is closely tied to the Aave 2030 Vision grant proposal and its purpose is to collect community feedback on the feature improvements of Aave V4. If the Vision proposal is approved, Aave Labs will begin development according to the timeline described above.
Copyright
The text of this TEMP-CHECK is released under the CC0 license. The visuals and the New Visual identity are subject to and governed by the license specified in the approved governance proposal by the DAO (to be included in the ARFC at a later date).
