Aave V3 – Portals, High Efficiency and Isolation Modes
Aave version 3 is aiming to expand DeFi’s growth with its increased capital efficiency, enhanced decentralization and security, plus generate more yield.
Aave has set the bar for innovation in the DeFi ecosystem since its launch in 2020. It is not immune from the challenges posed by multi-chain environments, as the protocol has been affected by the congestion and high latency Ethereum has long suffered from.
Thankfully, all of this has changed with the release of Aave’s latest version, which began to address not just the technical limitations of the protocol but also the problems users were experiencing.
Aave’s V3 set out to improve four key areas: capital efficiency, protocol safety, decentralization, and user experience. Aave’s development team saw these areas as ripe for improvement and has devoted months to overhauling the protocol.
1/ Aave V3 is here! 👻
The most powerful version of the Aave Protocol to date, V3 brings groundbreaking new features than span from increased capital efficiency to enhanced decentralization. Read what’s new in V3 in the thread below👇or visit https://t.co/H3jTyKRqNs to dive in! pic.twitter.com/LXzn7660nA
— Aave (@AaveAave) March 16, 2022
More Yield and Security
The primary goal for V3 was to enable the protocol to generate more yield for liquidity providers. This is a rather ambitious task, given that the total liquidity of Aave across multiple networks is close to $20 billion.
The largest percentage of that liquidity currently sits idle in Aave’s smart contracts, generating yield to liquidity providers from the borrowing activity on the protocol. And while this is a financial jackpot as the yield is constant and secure, there is room to improve.
Aave’s V3 set out to increase this yield by implementing new user-facing functionalities that reuse the idle capital. This is done without increasing the solvency contingencies and doesn’t require reallocating the assets to other protocols, drastically reducing the smart contract risk.
Called Isolation Mode, the feature was inspired by the MakerDAO approach for exposure management, and it enables Aave governance to vote on assets to be listed as “isolated.” Borrowers supplying an isolated asset as collateral can’t add other assets to their collateral, can only borrow a set basket of stablecoins and is subject to a debt ceiling.
When it comes to risk management, V3 brings much more sophisticated parameters and features than the previous version of Aave. Most notably, Aave governance can now configure borrow and supply caps, allowing the protocol to modulate how much of each asset can be borrowed and supplied. Aave governance can also lower the borrowing power control of any asset to as low as 0% without impacting existing borrowers.
However, not all changes to the risk management structure of V3 will be handled through governance. V3 introduces risk admins to the protocols, which are entities the Aave governance permitted to change risk parameters without needing a governance vote.
These entities can either be DAOs or automated agents that can react automatically when certain parameters are triggered in the protocol.
Decentralization through Admins and Oracles
Risk admins aren’t the only new entities with power added to Aave’s V3. The protocol’s latest version also introduced asset listing admins, which can introduce asset listing strategies that weren’t chosen through an on-chain vote as was the case in V2. Aave believes that this will allow developers and builders to create custom asset listing strategies, a move that will bring about true permissionless asset listing to the protocol.
To further improve the yield users can get from the assets on Aave, V3 introduced a feature called the high-efficiency mode. It was designed to maximize capital efficiency when both the collateral and the borrowed assets are correlated in price, particularly when both are derivatives of the same underlying asset.
In the original protocol design, the collateral value and the borrowed assets are usually normalized to a base currency, which is usually ETH or USD. However, there is no way of knowing on-chain which collateral is backing what borrowed asset, which makes it hard to improve collateral efficiency.
The high-efficiency mode solves this by introducing an asset classification that places all assets on Aave in a specific category, bundling assets of the same category together as they’re usually highly correlated in price. But, as the correct categorization can’t be enforced on-chain, it needs to be done by an entity managing the protocol—either the Aave governance or another set of admins voted in by said governance.
Aave’s V3 also puts a heavy emphasis on cross-chain interoperability. The addition of the portal feature enables supplied assets to flow between Aave instances on different networks. Design-wise, the portal feature required very little changes at the protocol level—it leverages the unique designs of Aave’s interest-bearing tokens (aTokens) to burn them on the source network while instantaneously minting them on the destination network.
“The underlying asset can then be supplied to Aave on the destination network in a deferred manner, by passing it to a pool after it has been moved through a bridge,” Aave explained in its V3 whitepaper.
The high throughput, scalability, and low cost of L2 networks mean that most of the assets from Aave on Ethereum will be transferred to L2s. To mitigate some of the issues that may arise in L2 networks, V3 introduced an advanced price oracle sentinel. The sentinel feature was designed specifically to handle any eventual downtime centralized block producers on L2s may experience.
L2 networks use these block producers, called sequencers, alongside distributed validation to increase throughput and support two queues for pending transactions—one on-chain requiring L1 transactions and another off-chain operated by the sequencer. The sequencers often experience downtime, which is usually short in length and has little impact on L2 users. However, if the downtime lasts longer, the network fails to produce new blocks and off-chain transactions may be rejected or dropped.
Aave relies on L2s as it uses oracle price feeds. When the sequencers experience downtime, the protocol’s price feeds aren’t updated. This creates the possibility of slow flash crashes when the sequencer comes up.
To solve this, V3 introduces a grace period for liquidations and disables borrowing when it detects a sequencer is down.