> For the complete documentation index, see [llms.txt](https://docs-v4.venus.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs-v4.venus.io/technical-reference/reference-technical-articles/emode.md). # E-Mode {% hint style="info" %} Only available on BNB Chain Core Pool. {% endhint %} ## Overview The **Venus Protocol Core Pool** on BNB Chain has been enhanced with **E-Mode (Efficiency Mode)**, a feature designed to provide users with greater **capital efficiency** when lending and borrowing. E-Mode introduces specialized **pools of assets**—such as correlated ones—each with its own customized **risk parameters**. When a user activates an **E-Mode pool**, their borrowing is restricted to assets within that pool but with **higher collateral factors (CF)** and **liquidation thresholds (LT)** compared to the default Core Pool. A **lower liquidation incentive (LI)** is also applied, reducing the penalty at liquidation and making borrowing within E-Mode more efficient. This allows users to unlock **more borrowing power** while keeping **risk contained** within the pool. Unlike **isolated pools**, which fully segregate assets into separate environments, E-Mode keeps everything within the Core Pool. Users do not need to transfer assets to benefit from different risk profiles. Instead, they can simply activate an E-Mode pool, gaining higher efficiency while maintaining their existing positions. This design balances capital optimization with contained risk management, making E-Mode a powerful extension of the Core Pool. ### Key Benefits of E-Mode * **Increased Borrowing Power**: Higher CF and LT enable users to leverage more borrowing capacity in E-Mode pools. * **Reduced Liquidation Penalties**: Lower LI minimizes losses during volatile market conditions. * **Seamless Integration**: No asset transfers are required; all operations remain in the Core Pool. * **Risk Isolation**: Borrowing limits prevent cross-pool exposure, reducing systemic risks. * **Governance Flexibility**: Pool parameters can be dynamically adjusted via Venus Governance proposals. ### Potential Risks and Considerations * **Borrow Restrictions**: Users must ensure existing borrows align with the target pool's allowed assets. * **VAI Incompatibility**: Users with VAI debt cannot enter E-Mode, ensuring stablecoin-specific isolation. * **Parameter Changes**: Governance updates (e.g., lowering CF) can impact the user positions. * **Core Pool Fallback Behavior**: Controlled by a per-pool flag `allowCorePoolFallback` (defaults to `false`). * If `true`: Assets not included in the E-Mode pool use Core Pool risk parameters (CF, LT, LI). * If `false`: Assets not included in the E-Mode pool have no risk factors applied (effectively CF = 0 and LI = 0), so users are recommended to exit such markets before switching into that E-Mode pool. ## Comptroller Changes for E-Mode in Core Pool The introduction of **E-Mode** in the Venus Core Pool on BNB Chain required significant enhancements to the `Comptroller` contract. These changes enable fine-grained risk management while preserving the existing Core Pool functionality. Below is a summary of the major updates: | Change | Description | Impact | | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | **Liquidation Threshold (LT) Support in Core Pool** | The Core Pool now supports **Liquidation Thresholds**, similar to isolated pools. LT allows borrowing limits (CF) and liquidation conditions (LT) to be defined separately, improving risk control. | Enables more precise liquidity calculations, separating borrow caps from liquidation triggers for better user safety. | | **Per-Market Liquidation Incentives (LI)** | The global LI has been replaced with **per-market LIs**, enabling Governance to assign asset-specific liquidation rewards based on risk. | Liquidators receive tailored incentives, optimizing protocol security and efficiency for high-risk vs. low-risk assets. | | **Unified Pool-Market Mapping** | The existing `markets` mapping has been replaced with `_poolMarkets`, a flexible structure keyed by a new `PoolMarketId` type (`bytes32`), which uniquely identifies each pool-market pair while maintaining backward compatibility for existing market getters. | Supports multiple pools without storage conflicts, allowing pool-specific overrides while maintaining legacy access. | The implementation extends the **Comptroller contract** to support: * Pool-specific risk configurations. * User-driven pool selection. * Refined, pool-based risk management. All of this is achieved while maintaining **backward compatibility** with the Core Pool’s legacy operations. ## Implementation Details ### 1. Markets Mapping The core data structure for tracking markets has been upgraded to handle multiple pools efficiently. **Previously**: Address as index ```solidity mapping(address => Market) public markets; ``` **Now**: `bytes32` as index ```solidity type PoolMarketId is bytes32; mapping(PoolMarketId => Market) public _poolMarkets; ``` * **Core Pool (poolId = 0)**: The `PoolMarketId` is the vToken address left-padded to 32 bytes, preserving storage layout for compatibility. * **E-Mode Pools (poolId > 0)**: The key is constructed by combining the `poolId` (uint96, shifted left by 160 bits) with the vToken address (uint160). This approach ensures: * **No collisions** between pool-market pairs. * **Pool-specific overrides** (e.g., CF/LT/LI). * **Backward compatibility** is preserved through updated getter functions, which return Core Pool values when called with only a vToken address, while maintaining the same function signatures. ### 2. Market Struct The `Market` struct now includes fields to support LT, per-market LI, and pool-specific borrowing rules: ```solidity struct Market { bool isListed; uint256 collateralFactorMantissa; mapping(address => bool) accountMembership; bool isVenus; uint256 liquidationThresholdMantissa; uint256 liquidationIncentiveMantissa; uint96 poolId; bool isBorrowAllowed; } ``` * `accountMembership`: Stored only in Core Pool entries, since borrows and collateral are tracked globally across all pools. In E-Mode entries, this mapping remains empty for structural consistency, reducing storage overhead. * `isBorrowAllowed`: A pool-level flag that Governance can toggle, overriding global borrow caps for E-Mode restrictions. ### 3. Pool Tracking Pools are defined and managed via a dedicated mapping for metadata and asset lists: ```solidity struct PoolData { string label; // e.g., "Stablecoins" address[] vTokens; // Markets in this pool bool allowCorePoolFallback; // If true, non-pool assets use Core Pool CF/LT/LI; if false, CF/LT/LI treated as 0 } mapping(uint96 => PoolData) public pools; uint96 public lastPoolId; ``` * `lastPoolId` tracks the latest assigned poolId (`0` is reserved for Core). * Pools hold metadata, a list of associated vTokens, and the `allowCorePoolFallback` flag (default: `false`). **Governance Workflow**: New pools are created via `createPool(string calldata label)`, which assigns the next `poolId` and initializes the `PoolData` with `allowCorePoolFallback = false` by default. Governance can update this behavior via `setAllowCorePoolFallback(uint96 poolId, bool allowed)`. This allows for easy expansion to new pools like "ETH Correlated" or "BNB Derivatives" while choosing the desired fallback behavior. ### 4. User Pool Selection Each user is associated with exactly one pool at a time, simplifying state management: ```solidity mapping(address => uint96) public userPoolId; ``` * Defaults to **0 (Core Pool)**. * Switching updates `userPoolId` with proper validations. This ensures all collateral and borrowing operations are evaluated within the context of the user’s active pool. **Edge Case Handling**: If a user's pool is disabled by Governance, their `userPoolId` is automatically reset to 0, triggering a fallback event. ### 5. Pool Markets Configuration Governance configures E-Mode via a suite of administrative functions: * **Add/Remove**: `addPoolMarkets` and `removePoolMarket` manage vTokens in non-Core pools. * **Borrow Control**: `setIsBorrowAllowed` toggles borrowing eligibility. * **Risk Parameters**: Setters for CF, LT, and LI support poolId for E-Mode and address-only for Core. * **Fallback Control**: `setAllowCorePoolFallback(uint96 poolId, bool allowed)` controls whether non-pool assets use Core Pool risk parameters. **Example Setters**: ```solidity // E-Mode setter function setCollateralFactor(uint96 poolId, VToken vToken, uint256 newCollateralFactorMantissa, uint256 newLiquidationThresholdMantissa) external returns (uint256); // Core Pool setter function setCollateralFactor(VToken vToken, uint256 newCollateralFactorMantissa, uint256 newLiquidationThresholdMantissa) external returns (uint256); ``` ## E-Mode: User Journey ### 1. Default State * Every user starts in the **Core Pool (poolId = 0)**. * Core Pool applies **standard parameters** (lower CF/LT, higher LI). * If the user never switches pools, nothing changes—ensuring zero disruption for legacy users. ### 2. Explore Available Pools Users can discover available E-Mode pools using: * **Venus Lens**: By calling the `getAllPoolsData` function to fetch pool data directly from the Comptroller. This returns supported E-Mode pools and their vTokens along with parameters such as CF, LT, LI, and borrow permissions. * **Venus App UI**: A user-friendly interface that displays the same information without requiring direct blockchain queries. ### 3. Validate Compatibility * Before switching, make sure all your borrowed assets are supported as borrowable assets in the E-Mode pool you want to enter. * If any borrowed asset is not allowed in the target pool, the `enterPool` transaction will revert on: **hasValidPoolBorrows()** check. ### 4. Enter the Pool * **Call**: enterPool(uint96 poolId) * **Comptroller checks**: * Pool exists and user isn’t already in it. * Borrow compatibility (`hasValidPoolBorrows`). * **VAI check**: Users with outstanding VAI debt or active minting positions cannot switch into E-Mode. * **Liquidity check**: Runs `_getAccountLiquidity` with new pool’s CF/LT. * ❌ If shortfall > 0 (would become liquidatable), tx reverts. * **On success**: * `userPoolId` updated * `PoolSelected` event emitted ### 5. Post-Entry Impacts * **Borrowing**: Restricted to markets marked `isBorrowAllowed` in chosen pool. * **Collateral**: * Pool assets use **pool CF/LT/LI**. * Non-pool assets behavior depends on `allowCorePoolFallback`: * If `true`: Non-pool assets use **Core parameters** (typically lower CF, higher LI). * If `false` (default): Non-pool assets have no applicable risk factors in the selected E-Mode pool (effectively CF = 0 and LI = 0). * **Liquidation**: * Pool assets → more efficient (lower LI). * Non-pool assets → liquidators prefer them due to higher LI. * **VAI**: Minting and repayment only possible in Core Pool. ## Common Scenarios ### Borrowed Asset Not Allowed * Example: A user has borrowed BTCB and tries to enter the Stablecoins Pool. * BTCB is not part of that pool, so it is not listed as borrowable. * Result: `enterPool` fails with `IncompatibleBorrowedAssets`. * Even if an asset is included in a pool, Governance can set `isBorrowAllowed = false`. In this case, supplying the asset as collateral is fine, but new borrows of that asset are restricted. ### Mixed Collateral * Users can provide collateral outside of the E-Mode pool’s listed assets **if the pool’s `allowCorePoolFallback` flag is set to true**. * If `allowCorePoolFallback = true`: Non-pool assets use **Core Pool parameters** (CF, LT, LI). Since Core Pool LI is typically higher, liquidators may target these assets first during liquidation. * If `allowCorePoolFallback = false` (default): Non-pool collateral **does not contribute to borrowing power**. CF, LT, and LI are treated as **0** in the E-Mode context. Users are strongly recommended to **exit these markets** before or immediately after switching to E-Mode to avoid unnecessary seizure risk for these assets during liquidations. **Example:** In the Stablecoins Pool, a user supplies **USDC + UNI**: * **USDC** → CF/LT/LI from E-Mode (e.g., LI = 5%). * **UNI** → * If `allowCorePoolFallback = true`: CF/LT/LI from Core Pool (e.g., LI = 10%). * If `allowCorePoolFallback = false`: CF/LT/LI = 0 → does not contribute to borrowing power. ### Switching Back to Core * Switching back is allowed only if the account remains healthy under Core Pool’s stricter parameters. * Example: In Stablecoins Pool, a user is safe with CF = 0.90. Switching back to Core Pool with CF = 0.60 may immediately create a shortfall → reverts with `LiquidityCheckFailed`. * **Important scenario**: * If a user is close to liquidation in Core Pool, they may switch into an E-Mode pool (with higher CF/LT) to immediately improve their account health and avoid liquidation. * However, if they attempt to switch back to Core, the stricter parameters would again make them liquidatable, so the transaction reverts. * This ensures users cannot bypass liquidation risk by cycling between pools. ### Governance Changes Governance has significant control over pool configurations, which can directly affect user positions: 1. **Borrow Restrictions:** * Governance can set `isBorrowAllowed = false` for a market. * Existing borrows remain, but new borrows are blocked. * This behaves similarly to setting the borrow cap to 0 in the Core Pool. * When borrow cap set to 0, no additional borrows are possible, but existing borrows are unaffected. 2. **Market Removal from E-Mode:** * If Governance removes a market from an E-Mode pool, the market’s risk factors instantly revert to its Core Pool values. * This is effectively the same as updating CF, LT, or LI parameters via a VIP. * Users need to monitor VIP proposals to anticipate changes. 3. **Disabling Core Pool Fallback:** * Governance can disable **Core Pool fallback** for a pool. * Assets outside the E-Mode pool will no longer use Core Pool parameters, which can affect user health. * Such changes are implemented **only after complete risk analysis** and with **advanced notice to users** so they can adjust their positions safely. 4. **Disabling an E-Mode Pool:** * Governance can disable an entire E-Mode pool by setting the `isActive` flag to `false`. * When this happens, all users in the disabled pool automatically fall back to Core Pool parameters. * Users who remain in a disabled E-Mode pool cannot initiate new borrows and are encouraged to either return to the Core Pool or switch to another active E-Mode pool. **Rule of Risk Factor Selection:** * If a parameter (CF, LT, LI) is defined in the active E-Mode pool, that value is used. * If Governance sets a value to `0` in the pool (e.g., CF = 0), the `0` applies — it does not fall back to Core. * If the asset is not included in the E-Mode pool: * If `allowCorePoolFallback = true`: Use the asset's Core Pool CF/LT/LI. * If `allowCorePoolFallback = false`: Treat CF/LT/LI as 0 for that asset in E-Mode; users are recommended to exit such markets. * If the pool is disabled, users automatically fall back to Core Pool parameters. ## Effect on User on Switching Into E-Mode To see how E-Mode changes borrowing power, liquidation, and borrow restrictions, let’s follow a single user journey. This example uses hypothetical parameters to illustrate key mechanics. ### Pool Setup | Asset | Core Pool CF | Core Pool LT | Core Pool LI | E-Mode CF | E-Mode LT | E-Mode LI | E-Mode Borrow Allowed? | | -------- | ------------ | ------------ | ------------ | ---------------------- | --------- | --------- | ---------------------- | | **USDC** | 60% | 65% | 10% | 90% | 93% | 5% | Yes | | **DAI** | 60% | 65% | 10% | 90% | 93% | 5% | No | | **UNI** | 50% | 55% | 12% | N/A (Fallback to Core) | N/A | N/A | N/A | ### Step 1: Alex in Core Pool * Supplies: **$1,000 USDC** * Borrows: **$500 DAI** **Liquidity Calculation**: $$ \text{Borrow Limit} = 1000 \times 0.6 = 600 $$ $$ \text{Liquidity} = \text{Borrow Limit} - \text{Total Borrow} = 600 - 500 = 100 $$ $$ \text{Shortfall} = 0 \quad (\text{since liquidity ≥ 0}) $$ * **Liquidity = $100, Shortfall = $0 → safe** ### Step 2: Attempting to Enter Stablecoins E-Mode Alex wants to switch to the Stablecoins Pool. * Borrowed DAI is **not allowed** in the target pool (`isBorrowAllowed = false`). * Comptroller checks fail → transaction **reverts** with `IncompatibleBorrowedAssets`. > This demonstrates **borrow restrictions in E-Mode**: existing borrows in disallowed markets prevent entering the pool. ### Step 3: Adjusting Position and Entering * Alex repays $500 DAI → no active borrows. * Calls `enterPool(stablecoinPoolId)` → succeeds. **Liquidity Calculation in E-Mode**: $$ \text{Borrow Limit} = 1000 \times 0.9 = 900 $$ $$ \text{Liquidity} = 900 - 0 = 900 $$ $$ \text{Shortfall} = 0 \quad (\text{safe}) $$ **Effect of E-Mode Activation**: * **Collateral Factor (CF)** for USDC increases from 60% → 90% * **Liquidation Incentive (LI)** for USDC decreases from 10% → 5% * Can borrow USDC (allowed), but **cannot borrow DAI** (isBorrowAllowed = false). ### Step 4: Borrowing in E-Mode * Alex borrows **$500 USDC** * Borrowing **DAI fails** (restricted by pool-level `isBorrowAllowed`) **Liquidity Calculation after borrow**: $$ \text{Borrow Limit} = 1000 \times 0.9 = 900 $$ $$ \text{Liquidity} = 900 - 500 = 400 $$ $$ \text{Shortfall} = 0 \quad (\text{safe}) $$ ### Step 5: Switching Back to Core Suppose Alex borrowed up to **$850 USDC** in E-Mode. **Core Pool Borrow Limit**: $$ \text{Borrow Limit} = 1000 \times 0.6 = 600 $$ $$ \text{Liquidity} = 600 - 850 = -250 $$ $$ \text{Shortfall} = 250 \quad (\text{tx reverts}) $$ To switch safely, Alex can either: 1. **Add collateral** → $500 more USDC → new Core borrow limit = 1500 × 0.6 = 900 → liquidity = 900 - 850 = 50 → switch succeeds. 2. **Repay debt** → reduce borrow ≤ $600 → liquidity ≥ 0 → switch succeeds. ## Liquidator Considerations in E-Mode The introduction of **E-Mode in the Core Pool** on BNB Chain also changes how liquidators must evaluate accounts and select assets for liquidation. To remain effective and profitable, liquidators need to adapt to the updated mechanics and new getter functions. ### 1. Per-Market Liquidation Incentives (LI) * The Core Pool no longer uses a **global LI**. * Each market now has its own **per-market liquidation incentive**, configurable by Governance. * **Impact**: Liquidators must always query the market’s specific LI before deciding which collateral to seize, since incentives may differ significantly between assets. * **Strategy**: Prioritize assets with higher LI when selecting which collateral to liquidate for maximum profit. ### 2. Liquidation Thresholds (LT) in Core Pool * The Core Pool now supports **Liquidation Thresholds (LT)**, just like isolated pools. * Unlike **Collateral Factors (CF)**, which only define borrow limits, **LT determines liquidation conditions**. * **Impact**: Liquidators must check account health against LT rather than CF. * **Recommended Function**: ```solidity function getAccountLiquidity(address account) external view returns (uint256, uint256, uint256); ``` This function has been updated to use LT internally when computing liquidity and shortfall. ### 3. Effective Risk Factor Queries Because E-Mode overrides Core parameters with pool-specific ones, the protocol provides new getters to return the **effective factors** for any user and market. * **Get Effective LTV (Collateral Factor or LT depending on weighting):** ```solidity enum WeightFunction { USE_COLLATERAL_FACTOR, // 0 USE_LIQUIDATION_THRESHOLD // 1 } function getEffectiveLtvFactor( address account, address vToken, WeightFunction weightingStrategy ) external view returns (uint256); ``` * Use `weightingStrategy = 0` to fetch the **effective CF**. * Use `weightingStrategy = 1` to fetch the **effective LT**. * **Get Effective Liquidation Incentive (LI):** ```solidity function getEffectiveLiquidationIncentive( address account, address vToken ) external view returns (uint256); ``` *** ### TL;DR: E-Mode in Venus BNB Chain Core Pool **Efficiency Boost**: E-Mode lets you use **higher Collateral Factors (CF)** and **Liquidation Thresholds (LT)**, plus **lower Liquidation Incentives (LI)**, for some set of assets (e.g., stablecoins). **Borrow Limits**: You can only borrow from pool-approved assets (`isBorrowAllowed = true`). If you have borrows in non-approved assets, you can't enter; new borrows are blocked to keep risks isolated. **How Risk Factors Are Chosen**: * **In E-Mode Pool**: Use the pool's CF/LT/LI values (even if set to 0). * **If the asset isn't in your pool**: * If `allowCorePoolFallback = true`: Use Core Pool values. * If `allowCorePoolFallback = false` (default): Treat CF/LT/LI as 0; exit such markets. * **Pool Disabled**: Falls back to Core Pool parameters. **Liquidator Notes**: * Core Pool now uses **per-market LI** (no global incentive). Liquidators should always fetch the effective liquidation incentive for each user’s market, as markets associated with different E-Mode pools may have different LI values. Additionally, assets outside the E-Mode pool that do not contribute to borrowing power may have **LI = 0**, even if supplied as collateral. * **Liquidation Threshold (LT)** replaces CF as the trigger for liquidations—use `getAccountLiquidity` for checks. * Use new getters to fetch **effective parameters** considering pool overrides: * `getEffectiveLtvFactor(account, vToken, 0)` → effective CF * `getEffectiveLtvFactor(account, vToken, 1)` → effective LT * `getEffectiveLiquidationIncentive(account, vToken)` → effective LI --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs-v4.venus.io/technical-reference/reference-technical-articles/emode.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.