E-Mode

Not yet available. It will be only available on BNB Chain Core Pool.

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 positions without notice.

  • 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.

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.

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.

These enhancements ensure E-Mode operates as a lightweight overlay on the Core Pool, minimizing gas costs and migration efforts.

Implementation Details

1. Markets Mapping

The core data structure for tracking markets has been upgraded to handle multiple pools efficiently.

Previously: Address as index

mapping(address => Market) public markets;

Now: bytes32 as index

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:

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:

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:

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:

// 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.

    • In that case, all users currently in the pool automatically fall back to Core Pool parameters.

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:

Borrow Limit=1000×0.6=600\text{Borrow Limit} = 1000 \times 0.6 = 600
Liquidity=Borrow Limit−Total Borrow=600−500=100\text{Liquidity} = \text{Borrow Limit} - \text{Total Borrow} = 600 - 500 = 100
Shortfall=0(since liquidity ≥ 0)\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:

Borrow Limit=1000×0.9=900\text{Borrow Limit} = 1000 \times 0.9 = 900
Liquidity=900−0=900\text{Liquidity} = 900 - 0 = 900
Shortfall=0(safe)\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:

Borrow Limit=1000×0.9=900\text{Borrow Limit} = 1000 \times 0.9 = 900
Liquidity=900−500=400\text{Liquidity} = 900 - 500 = 400
Shortfall=0(safe)\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:

Borrow Limit=1000×0.6=600\text{Borrow Limit} = 1000 \times 0.6 = 600
Liquidity=600−850=−250\text{Liquidity} = 600 - 850 = -250
Shortfall=250(tx reverts)\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:

    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):

    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):

    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

Last updated