💡Note : eModes were introduced with Aave v3 & not with v2.
Key Takeaways
Comparison of the state of eModes in Aave v3.1 & Aave v3.2. The features & benefits like borrowing power and further upgrades in v3.2 that address the v3.1 limitations.
Use cases of eModes currently, its working, categories (risk parameters) such as LTV & liquidation thresholds, & feature updates in v3.2, including liquid eModes & removal of stable rate logic from v3.1.
eModes in v3.1
The High-Efficiency Mode (eMode), introduced in Aave v3, allows borrowers to maximize their borrowing power out of their collateral when the asset supplied as collateral & the asset they want to borrow have similar /closely related prices or are tied to the same underlying value.
For example: Stablecoins like USDC & DAI are pegged to the US dollar. Using USDC as collateral, users can borrow more DAI in eMode because their prices are correlated.
Here, the price risk is lower as collateral & borrowed assets are closely related in value. So, it’s safer for the protocol to let users borrow more. This advantage is designed to let users borrow more than they normally would, but only when the risks are lower because the prices of both assets are expected to stay closely related.
Why eModes?
- In TradFi, real-world assets like property or stocks are used as collateral. But, in web3 protocols, the collateral & loans are crypto assets like stablecoins, cryptocurrencies, etc. The problem here is high volatility & liquidity concerns, which eModes aims to solve by focusing on correlated assets.
Let’s see a scenario with & without eMode :
- Without eMode:
- If a user supplies ETH as collateral (a volatile asset) & wants to borrow DAI (a stablecoin), Aave might only allow the user to borrow 50% of their ETH’s value to manage risk. So, with $1,000 of ETH, the user can borrow up to $500 in DAI.
2. With eMode:
- With eMode, if a user supplies USDC & borrows DAI since both are stable & closely priced, eMode allows the user to borrow up to 95%. So, with $1,000 in USDC, the user can borrow up to $950 in DAI.
💡Conclusion: Since, The prices of USDC and DAI are closely correlated, meaning they tend to move in sync with each other. As a result, the risk of price fluctuations is much lower compared to more volatile assets like ETH. Aave’s eMode takes advantage of this stability by allowing users to borrow a higher percentage of their collateral when using these assets. Since USDC and DAI are likely to maintain similar values, the system sees a reduced risk of significant losses or liquidation, making borrowing safer in this context.
Use Cases of eModes :
High-Leverage Forex Trading: With eModes maximizing borrowing potential, higher leverage becomes possible, allowing for larger positions & bigger bets.
Highly Efficient Yield Farming: eModes let users use tightly related assets like ETH staking derivates to borrow more ETH at lower risk, enabling maximum returns.
Diversified Risk Management: Borrowers can efficiently diversify their portfolio using closely correlated assets, such as stablecoins while minimizing liquidation risk & maximizing borrowing power due to eModes.
eMode Categories & Risk Management :
The
RISK_ADMINS&POOL_ADMIN, set by Aave Governance are capable of setting up & managing a maximum of 255 eMode categories.Each eMode category has specific risk settings based on how safe it is to borrow against certain assets.
Risk Management Parameters :
LTV (Loan to Value)
Liquidation Threshold
Liquidation Bonus
A custom price oracle (optional)
💡Category 0 is the default mode where no eMode benefits are applied. Assets listed on Aave V3, by default, have category 0 assigned to them with standard risk parameters & no higher efficiency borrowing of eMode. This means if user has supplied liquidity to protocol, the category is set to 0.
The
RISK_ADMINS&POOL_ADMINcan assign any listed asset to one of the pre-configured eMode categories. They control which assets are eligible for higher capital efficiency. The correct categorization is not enforced on-chain & needs to be maintained by theRISK_ADMINS&POOL_ADMINSselected via the Aave Governance vote.eMode also offers the possibility of introducing a specific price oracle for a certain category. Some eMode categories may need a custom price oracle to ensure accurate pricing for that asset group.
Key Features of eMode & its Categories :
If both collateral & borrowing assets are in the same eMode category, the borrower can access a higher collateralization factor, applicable only when the assets have low price volatility relative to each other. This allows users to borrow more.
When eMode is activated, users can only borrow assets within the same category as their collateral, such as stablecoins. This ensures price consistency & reduces risk. While users can still provide collateral that isn’t part of the eMode category (like ETH), only assets from the same eMode category benefit from higher LTV & improved liquidation settings.
eMode allows users to switch borrowing terms, improving loan-to-value (up to 97%) when borrowing assets within the same category as their collateral. However, if a user is already borrowing an asset outside the eMode category (e.g., ETH), they must repay the loan before switching to a new eMode category, such as stablecoins.
eMode organizes assets into categories based on price correlation, like stablecoins in one category & ETH derivatives in another. New assets can join an eMode category if their loan-to-value & liquidation thresholds exceed standard limits. On the other hand, assets can be removed from eMode by authorized entities (risk or pool admins), potentially leading to liquidation if it reduces the user's health factor.
eMode Example :
eMode allows users to benefit from higher Loan-to-Value (LTV) ratios & more favorable risk parameters when they borrow against assets that belong to the same category.
eMode category 1 is stablecoins, which is less volatile. Here, a user X can borrow up to 97% of their collateral’s value (LTV), with a 98% liquidation threshold & 2% liquidation bonus, without a custom price oracle (regular market prices are trusted).
Let's say user X supplies DAI, which has a standard LTV of 75%. However, because X chooses eMode Category 1, X can now use DAI to borrow other stablecoins at higher LTV or 97%. This means X can leverage its DAI more effectively, making its capital 22% more efficient.
X can also supply other assets that aren't in Category 1 as collateral, but only the assets in the same eMode category (like stablecoins) will benefit from the enhanced parameters. This means X could use a mix of assets but would only enjoy the higher LTV & other benefits with the stablecoins.
Derivatives in eMode :
ETH & its derivatives (stETH, sETH, alETH) behave similarly to their underlying (ETH).
For a category where only renBTC & WBTC are defined, it would be possible to use the BTC/USD oracle for both of them whenever the user is in BTC eMode as eMode offers the possibility of introducing a specific price oracle for a certain category.
This would further reduce the risk of unwanted liquidations as it eliminates the oracle asynchronicity (in case of dramatic price drops of BTC, the WBTC/USD & renBTC/USD oracles might update at slightly different times since they are asynchronous, this might cause unwanted liquidations).
Oracles in eMode :
Using a single oracle for an entire category increases the risk if one asset in the category collapses in value due to some hack or issue, it leads to protocol at risk.
The Aave governance must decide whether it’s worth using a category-specific oracle.
How eModes work?
When the user supplies liquidity to the protocol, the account is automatically set to Category 0, where eMode is not active yet. Users can change their eMode category to any of the pre-configured categories set by PoolConfigurator if they meet the following conditions:
1 ) All borrowed assets of the user are in the chosen category. This means users can only switch to a new eMode category if all assets borrowed are part of the same category. This makes sure that there’s no mixing of assets with different risks.
2 ) Changing eMode doesn’t leave the user’s position under-collateralized. When switching to a new eMode category, the protocol checks that the change won’t leave your borrowing position under-collateralized (i.e. your collateral will still cover your loans under the new settings). This protects users from accidentally taking on more risk.
Entering & Exiting eMode :
Enter E-Mode: A user can enter eMode (category ≠ 0) only if all borrowed assets are in the chosen category.
Exit E-Mode: A user can exit eMode (set category to 0) only if leaving eMode does not leave their position undercollateralized (HF ≥ 1).
eModes in v3.2
- This version of Aave brings two important changes :
Introduction of Liquid eModes.
Removal of Stable Rate Logic.
The updates are introduced to address the limitations of eModes in v3.1.
Limitations of eModes in v3 :
In v3, each asset could only be assigned to a single eMode. For example, if WETH (wrapped ETH) was assigned to “eMode 1”, WETH couldn’t be eligible for another eMode at the same time.
This limited users from creating different borrowing configurations using WETH in multiple contexts. So, a user can’t have one eMode for wstETH (staked ETH token) & WETH while having a separate eMode for weETH ( another ETH-based asset) & WETH.
Example: Suppose an Aave pool wanted two different eModes: The v3.1 wouldn’t allow this because WETH could only be assigned to one eMode at a time. This restricted flexibility for users wanting to interact with different types of ETH-based tokens. a ) One where wstETH & WETH are in the same eMode. b ) Another where weETH & WETH are in a different eMode.
1 ) Liquid eModes :
- With Aave 3.2, this limitation is removed. Now, a single asset (like WETH) can be eligible for multiple eModes at the same time. Also, users have the flexibility to choose which eMode they want to enter based on the specific assets they hold & the risk parameters they prefer. This allows multiple configurations involving the same asset.
Possible Configurations with Liquid eModes :
With the new feature, Aave can now support the following eMode configurations, which weren’t possible before :
eMode 1: Grouping of wstETH, weETH, & WETH.
eMode 2: Grouping of wstETH & WETH.
eMode 3: Grouping of weETH & WETH.
eMode 4: Grouping of WETH & GHO (a different asset).
This shows that WETH can now be part of multiple eModes, depending on the configuration chosen by the user.
Features of Liquid eModes :
The features of Liquid eModes can further be configured to make them even more effective for users. Some ways in which it’s possible are :
eMode for WETH & Stablecoins: In this configuration, only WETH (Wrapped ETH) & stablecoins are included in eMode. This allows users to use WETH as collateral to borrow stablecoins at favorable rates or risk parameters.
eMode for Less Mature LSTs: This creates eMode for Less Mature LSTs, meaning newer or less liquid tokens, without bundling them with major LSTs like wstETH. This gives flexibility to treat different types of LSTs differently, based on their maturity & risk profile.
Borrowable, Collateral, or Both: The new Liquid eMode system, allows assets within an eMode as only borrowable, only collateral, or both. In an eMode with wstETH (staked ETH) & WETH, wstETH could be configured as collateral only (i.e. users deposit it but can’t borrow it), while WETH is borrowable only (users borrow WETH but don’t deposit it as collateral).
No LTV/LT Enforcement Outside eMode: In the prior version (v3.1), protocol enforced lower LTV/LT ratios for assets when they weren’t in eMode. Now, the protocol doesn't enforce stricter LTV/LT ratios outside of eMode, meaning users can still access favorable terms even if they’re not in an eMode.
Health Factor Validation (HF): HF is a safety metric for borrowing. The new feature ensures that when users enter an eMode, their HF is validated. So, a user can’t enter the eMode if their HF drops below 1.0 after the swap. This prevents users from becoming too risky when changing from no-eMode to an eMode, ensuring their position remains healthy.
Removal of eMode Specific Price Feeds: v3.1 used a separate price feed mechanism for eMode-specific assets. All the assets in an eMode would use the same pricing feed. As it was never used, Aave removed this feature to allow more efficient storage & save space.
Storage of eMode Data: In versions before v3.2, the eMode data was stored within the asset’s data. Each asset individually stored information about whether it is eligible for eMode. Now, in v3.2, the eMode data is stored separately. It allows the protocol to efficiently determine which assets are eligible for an eMode without having to store that information within each asset’s data. This improves data organization & performance.
2 ) Cleanup of Stable Rate Logic :
As part of the Aave v3.1 upgrade, the protocol introduced a function called
swapToVariable(). This function allows users to permissionlessly convert any stable borrow positions into variable rate borrowings.It was done to off-board stable rate borrowings, allowing users to move their stable loans to variable interest rates without needing permission. This deprecated the use of stable rates in Aave pools.
The Dolce Vita program (run by ACI 4, a service provider) moved all remaining stable rate positions to a variable, ensuring that no stable rate loans were left in the system. This allowed Aave to safely remove the stable rate functionality altogether.
Here you can see the flexibility that v3.2 offers with other sets of configurations.