Aave eMode adjusts collateral parameters and permitted borrowing by category. Legacy Isolation Mode in Aave V3.6 restricts an account to one isolated collateral reserve, approved debt assets and a shared debt ceiling. Aave V3.7 removes that legacy mode and adds a distinct isolated eMode flag, so identify the deployed version before comparing settings.
The practical difference appears when a wallet tries to change something: borrow another token, enable another collateral reserve, or leave a category. A portfolio balance and a high displayed loan-to-value (LTV) do not establish whether that next action is permitted.
Start with the version behind the pool
As checked on 28 October 2026, the official Aave V3.7.0 release removes legacy Isolation Mode. It also introduces an isolated flag for eMode categories. Those are separate changes with different rules. A guide that presents eMode and legacy Isolation Mode as two universally available current settings misses that boundary. Aave V3.7.0 release.
This article uses the EVM V3.6.0 reference release, commit 5a230ec, for the historical comparison and V3.7.0, commit cff15de, for the update. The official V3.6.0 release identifies that older code. A release existing in a repository does not prove a particular pool has adopted it. Check the chain, pool address, deployed implementation and observation block before applying either model.
These are Aave V3 rules. V4 documentation and the Aptos implementation do not establish the behavior of these EVM releases. Every asset, price and parameter in the worked examples below is hypothetical.
Read collateral permission and debt permission separately
In V3.6, an eMode category has separate lists for collateral and borrowing. The collateralBitmap identifies reserves receiving the category's collateral treatment; the borrowableBitmap identifies permitted debt reserves. A reserve can appear on one list without appearing on the other. An asset can also participate in multiple categories. Aave's liquid eMode explanation.
Consequently, “these tokens are in the same category” is an incomplete account description. Record what each token can do in the selected category. A collateral-only asset does not become borrowable because its price follows the same underlying asset.
V3.6 also decouples non-default eMode settings from ordinary reserve settings. An asset may be collateral-only or borrowable-only within a particular eMode even when that use is unavailable outside it. The category's ltvzeroBitmap can make listed collateral's effective LTV zero. Read the actual configuration rather than assuming the ordinary reserve flag always controls eMode. Pinned V3.6 feature specification.
| Question | V3.6 eMode | V3.6 legacy Isolation Mode |
|---|---|---|
| How is the state established? | The user selects a category | One enabled collateral reserve has a nonzero debt ceiling |
| Which collateral matters? | Category collateral has category treatment; other eligible collateral can retain base treatment | Only the isolated reserve can be enabled as collateral |
| What restricts debt assets? | The category's borrowing list | Each debt reserve's isolation borrowing flag |
| What limits the quantity? | Account collateral rules plus applicable pool constraints | Account collateral rules plus a shared collateral-reserve debt ceiling and other constraints |
The legacy state is detected from enabled collateral, not from everything supplied. The V3.6 user-configuration code checks for exactly one collateral reserve and a nonzero ceiling. Supplying an additional asset therefore differs from enabling it as collateral. V3.6 isolation-state detection.
Borrowable reserves need explicit permissions; a stablecoin label alone grants none. A category name also cannot guarantee that two assets will maintain their price relationship.
In the pinned V3.6 code, selecting eMode does not remove an enabled reserve's legacy isolation state. Where configuration permits a combination, borrowing must satisfy both permission paths. The eMode label provides no exemption from the isolation flag or ceiling check. V3.6 borrow execution.
A worked eMode account with asymmetric permissions
Consider an illustrative V3.6 account with two invented collateral assets, A and B, already enabled. Their oracle-valued amounts are $8,000 and $2,000. Assume all reserves are active, needed operations are permitted, liquidity is sufficient, caps do not bind, and there is no legacy isolation configuration. Ignore interest changes and raw-unit rounding during this snapshot.
| Input | Asset A | Asset B |
|---|---|---|
| Collateral value | $8,000 | $2,000 |
| Ordinary maximum LTV | 70% | 50% |
| Ordinary liquidation threshold | 80% | 60% |
| Listed as collateral in category 7? | Yes | No |
| Category 7 maximum LTV / threshold | 90% / 93% | Base parameters remain |
Assume category 7 permits borrowing invented asset D but does not permit borrowing A or B. D is also borrowable in ordinary mode, and D's oracle price is fixed at $1 for this illustration. None of the enabled collateral has effective LTV zero.
Ordinary borrowing capacity is $8,000 × 70% + $2,000 × 50% = $6,600. Its liquidation numerator is $8,000 × 80% + $2,000 × 60% = $7,600.
With category 7 selected, modeled capacity becomes $8,000 × 90% + $2,000 × 50% = $8,200. The liquidation numerator becomes $8,000 × 93% + $2,000 × 60% = $8,640. B has not received the category's higher percentages. This follows the V3.6 account calculation, which applies the category threshold to listed collateral and the reserve threshold otherwise. V3.6 account-calculation logic.
At 6,000 D of debt, health factor is approximately 1.2667 in ordinary mode and 1.4400 in category 7. Those ratios divide the respective liquidation numerators by $6,000. The distinction between borrowing capacity and liquidation support is developed in LTV versus liquidation threshold.
The account can pass a collateral calculation and still fail an attempted borrow of A: category 7's debt list excludes A. Conversely, D being borrowable does not make it category collateral. Direction matters.
Why leaving the category can fail
Now assume the category-7 account has increased its debt to 7,800 D. This fits its illustrative $8,200 capacity. Its health factor is $8,640 ÷ $7,800 = 1.1077.
Switching to ordinary mode would restore the $7,600 liquidation numerator while leaving debt at $7,800. The resulting health factor would be approximately 0.9744. V3.6's mode-change execution validates the resulting health factor, so this attempted exit fails. The transaction does not successfully exit and then leave the modeled account in that invalid target state. V3.6 mode-change execution.
Repayment changes the arithmetic, but it is only one check. Reducing debt to 6,500 D would produce an ordinary-mode health factor of about 1.1692 and debt below the $6,600 borrowing capacity in this constructed account. That does not establish a universally safe debt level: prices, accrued debt and configuration can change.
Existing debt must also be permitted in the target state, and enabled collateral must retain nonzero effective LTV there. A token borrowable only inside an eMode can block an exit even when health factor looks adequate. A check based solely on “HF above 1” misses these target-state validations. V3.6 transition validation.
An additional illustrative check separates exiting from borrowing more. At 7,500 D of debt, ordinary-mode health factor would be $7,600 ÷ $7,500 = 1.0133. Under the same debt and collateral permissions, that exit can pass its health-factor check while ordinary borrowing headroom remains zero: debt still exceeds the $6,600 borrowing capacity. The mode-change path uses health-factor validation; new borrowing also requires its separate LTV test. V3.6 mode-change checks.
Follow a legacy isolated-collateral transition
Use a separate hypothetical V3.6 wallet with no debt and category 0 selected. It supplies invented isolated asset X, which has nonzero collateral LTV and a nonzero debt ceiling. It also holds a supplied balance of B. Before the timeline starts, explicitly disable B's collateral flag while the wallet has no debt, leaving neither asset enabled.
In this release, supplying X does not automatically enable it as collateral. The specific V3.6 isolated-collateral change requires distinguishing a supply balance from collateral activation. V3.6 collateral-enabling changes.
| Illustrative action | Result under the stated V3.6 conditions |
|---|---|
| Explicitly enable X while no collateral is enabled | X can establish the isolated collateral state |
| Then try to enable B | Rejected while X is the isolated collateral |
| Borrow D with its isolation permission enabled | Still subject to account checks, shared ceiling and other constraints |
| Borrow E with its isolation permission disabled | Rejected regardless of spare account capacity |
| Disable X while its debt remains unsupported | Fails the resulting health-factor check |
| Fully repay debt, disable X, then enable eligible B | Can move away from the legacy isolation configuration |
The shared ceiling belongs to the isolated collateral reserve, not to this wallet alone. Other users can consume its remaining room. The V3.6 isolation library checks the borrowed reserve's permission and the updated aggregate counter. Passing a personal LTV calculation cannot override either check. V3.6 isolation borrow validation.
The isolation debt ceiling versus borrow-cap comparison traces those different units and scopes. Do not substitute an oracle-valued portfolio total for the legacy isolation counter.
V3.7 isolated eMode is a different configuration
V3.7's category-level isolated flag makes collateral outside the category's collateral list have effective LTV zero. It does not recreate the legacy reserve debt ceiling or single-collateral rule. Multiple listed collateral reserves can still belong to the category. Borrow permissions remain a separate list. Pinned V3.7 isolated-eMode specification.
Apply that flag to the earlier illustrative category-7 account. A contributes $7,200 of borrowing capacity; B contributes zero. If governance enables the flag while B is already enabled, modeled capacity drops from $8,200 to $7,200. B's base liquidation threshold remains unchanged, so the $8,640 liquidation numerator and 1.1077 health factor at $7,800 debt remain unchanged in this isolated change. The simplified ledger has no new borrowing headroom.
A new attempt to enter that isolated eMode with B enabled would instead fail the effective-LTV check. “Existing collateral becomes LTV zero” and “new entry is rejected” describe different starting states. V3.7 effective-LTV validation.
Build a before-and-after permission worksheet
Start each review with the pool's deployed implementation. V3.7 retains compatibility views: its data provider's getDebtCeiling returns zero. Seeing that field in an API response does not prove legacy Isolation Mode is operational. V3.7 data-provider implementation.
For each proposed action, capture a coherent observation block and complete these fields:
| Worksheet field | Evidence needed |
|---|---|
| Account boundary | Chain, pool, implementation, wallet and block |
| Starting mode | Selected eMode ID; legacy isolation state only where implemented |
| Collateral | Supplied quantities, enabled flags and effective LTV/threshold per reserve |
| Debt permission | Each existing and proposed debt reserve's target-state permission |
| Configuration | Category collateral list, borrowing list, LTV-zero settings and V3.7 isolated flag where supported |
| Target account | Recomputed capacity, debt and health factor after the exact action |
| Other gates | Liquidity, caps, pause/freeze status and version-specific restrictions |
| Confirmed result | Receipt and fresh collateral, debt and mode reads |
Keep the borrowing rate outside the permission decision. A quoted rate cannot grant eligibility, and a permitted borrow does not freeze its future cost. The liquidity-rate versus borrow-rate ledger explains that separate calculation.
Likewise, a combined wallet balance is not eligible collateral everywhere; collateral fragmentation provides the broader account-boundary method. Finish with a specific statement: this implementation permits these collateral reserves to support these debt reserves, and this proposed transition passes these target-state checks at this observation block. That is the reproducible comparison a mode label alone cannot provide.