E-Mode and Liquidation Threshold in the BNB Chain Core pool

[Jesus]

We propose the implementation of Efficiency Mode (e-mode) in the Core pool on BNB Chain codebase (where most of Venus liquidity is concentrated). E-mode will create subgroups of markets with specialized collateral factors (CF), liquidation thresholds (LT), and liquidation incentives. Users must opt-in to an e-mode group and can only borrow assets from that specific group, which helps limit risk.

Once this feature is released, Venus Protocol will create specific e-mode groups with increased CF and LT values and reduced liquidation incentives. Potential candidates include:

• BTC e-mode group: including BTCB, SolvBTC and xSolvBTC
• BNB e-mode group: including WBNB and asBNB

Additionally, we propose implementing the Liquidation Threshold concept in the Core pool on BNB Chain. Isolated Pools already incorporate this feature, which helps reduce liquidation risks for users.

Problems to be Solved:

• Lack of competitive Max LTVs compared to other lending protocols.
• Liquidity fragmentation in the current Venus Protocol model, based on Isolated Pools.
• Currently, in the Core pool on BNB Chain, Max LTV (used to calculate user borrowing power) and Liquidation Threshold (used to calculate user health factor and determine liquidation eligibility) share the same value. This increases liquidation risk for users.

Solution Proposed:

• Implement the e-mode feature (originally developed by AAVE) exclusively in the Core pool on BNB Chain, which is the platform’s largest liquidity pool.
• Note on Isolated Pools: these pools currently lack sufficient liquidity to justify e-mode development. Additionally, Isolated Pools use a different codebase than the Core pool, which would require separate development work.
• Implement the Liquidation Threshold feature in the Core pool on BNB Chain. Markets in that pool will have a different value for the Max LTV and Liquidation Threshold.

Benefits for the Protocol/Community:

• Higher Max LTV for specific pairs, increasing capital efficiency for suppliers.
• Enhanced leveraged strategies, leading to increased TVL and protocol income.
• Reduced liquidation incentives to attract more borrowers.
• Lower liquidation risk

Details

How e-mode will work on Venus Protocol

e-mode groups

• Venus Protocol will support the creation of e-mode groups through Governance
• Each e-mode group will define:
  • List of markets in the group
  • For each market:
    • Whether the market can be borrowed
    • e-mode maximum Loan-to-Value (max LTV)
    • e-mode Liquidation Threshold (LT) - which must exceed the max LTV
    • e-mode Liquidation Penalty (LP) - the additional percentage of the collateral that liquidators receive during liquidation
• One market can belong to multiple e-mode groups simultaneously (similar to AAVE’s implementation in their recent AAVE Liquid E-mode)

User Interaction

• Users must opt-in and opt-out of e-mode
• The system always validates that a user’s Health Factor remains above 1 after e-mode transitions (users cannot be liquidated immediately after opting in or out of an e-mode group)
• Each user can belong to either no e-mode group or exactly one e-mode group
• Users cannot opt-in to an e-mode group if they have debt in a market that isn’t borrowable within their desired e-mode group
  • Example 1:
    • User has debt in BNB
    • User wants to enable ETH Correlated e-mode group (which doesn’t include BNB)
    • Result: User cannot opt-in to the “ETH Correlated” e-mode group
  • Example 2:
    • User has debt in wstETH
    • User wants to enable ETH Correlated e-mode group (where wstETH exists but isn’t borrowable)
    • Result: User cannot opt-in to the “ETH Correlated” e-mode group
• Once in e-mode:
  • Only assets in the selected category can be borrowed
  • For supplied assets outside the e-mode category, the system applies the default max LTV and LT values
  • When an e-mode group is enabled, the system uses e-mode parameters for calculating borrowing power and liquidation logic
  • Users can still supply assets outside the e-mode group to earn yield and increase borrowing power (though without any boost)
  • Liquidation Logic: ****When a user in e-mode is liquidated: use the category-specific risk parameters (LT, LP)

Governance Controls

Venus Protocol Governance will be able to:

• Create new e-mode groups
• Add or remove markets from e-mode groups
• Enable or disable markets as collateral/borrowable within e-mode groups
• Set or modify the max LTV, LT, and LP parameters for markets in an e-mode group
• Enable or disable entire e-mode groups

How Liquidation Threshold will work on the BNB Chain Core pool

This will function exactly as it currently does in the Isolated Pools:

• Max LTV (Collateral Factor) determines the user’s borrowing power. Example:
  • Max LTV of USDT: 80%
  • If a user deposits 100 USDT and enables it as collateral, they can borrow up to 80 USD from any borrowable market in the Core pool
• Liquidation Threshold determines the user’s health factor and liquidation eligibility. Example:
  • Liquidation Threshold of USDT: 85%
  • If a user deposits 100 USDT, they can borrow up to 80 USD. Assuming they borrow the maximum amount in USDC (80 USDC)
  • The user’s health factor becomes 1.0625 (100 USDT * 85% / 80 USDC). Their debt would need to increase to 85 USDC before liquidation becomes possible. This 5 USDC “safety buffer” is the key benefit of implementing the Liquidation Threshold concept
• Liquidation Threshold will always be greater than or equal to the Max LTV. It will typically be higher, creating a security buffer for users.

[Danny]

Great proposal

Finally Implementing e-mode and Liquidation Threshold on the BNB Chain Core pool is exactly the type of upgrade Venus needs to stay competitive. By boosting capital efficiency, giving users a safety buffer, and enabling more leveraged strategies, this will directly attract more suppliers and borrowers, ultimately helping to grow Venus TVL and strengthen the protocol.

[Xvs_Believer]

FINALLY HERE

Just go !

Let’s the game start

[Ray]

A new chapter begins—can’t wait to see the implementation in action.

[mopgawka]

I like the idea of increasing opportunities with e-mode. This will improve the efficiency of correlated assets.

[Tomm]

I support this proposal and hope that e-mode will be released soon.

[Jesus]

I’d like to propose the following list of e-mode groups, including some specific markets (both existing and new) that could benefit from being grouped together in the BNB Chain Core Pool:

Stablecoins 1

• USDe
• sUSDe
• USDT
• USDC
• PT-USDe-30Oct2025 (new Pendle market)

Stablecoins 2

• USDe
• sUSDe
• USDT
• USDC
• TUSD
• USD1
• lisUSD
• PT-USDe-30Oct2025 (new Pendle market)

BTC correlated

• BTCB
• SolvBTC
• xSolvBTC
• PT-xSolvBTC-18Dec2025 (new Pendle market)
• PT-SolvBTC.BNB-18Dec2025 (new Pendle market)

BNB correlated

• asBNB
• WBNB
• slisBNB (new market, already reviewed here by Chaos Labs for the Core pool)

ETH correlated (updated 2025/09/22)

• ETH
• WBETH

I believe structuring these e-mode groups this way would help maximize capital efficiency while still keeping risks under control, especially by distinguishing between narrow and broad stablecoin groups, as well as adding Pendle PT assets that have strong correlation with their underlying.

The specific risk parameters (e.g. Collateral Factors, Liquidation Thresholds and Liquidation Incentives) for each group should be provided by Chaos Labs, and this setup should be acceptable for them before implementation.

This setup can also be modified in the future as needed, and new e-mode groups can be added to accommodate further asset integrations.

Would be glad to hear thoughts from the community and risk partners.

[chaoslabs]

Overview

Chaos Labs supports the creation of the stablecoin E-mode, which we believe will enhance capital efficiency for users without introducing additional risk. In particular, we recommend first creating an sUSDe/USDe E-mode as an initial step before expanding it to additional stablecoins. Below, we present our analysis and recommended risk parameters.

Recommendation

sUSDe is the staked, yield-bearing representation of USDe, implemented as an ERC-4626 vault. Users deposit USDe into the staking contract and receive sUSDe in return, while their claim on the underlying USDe continuously increases as staking rewards accrue. The redeemability of sUSDe into USDe at a monotonically increasing exchange rate structurally anchors the two tokens and aims to keep their prices tightly linked. sUSDe’s value is mechanically determined by accrued rewards over USDe principal, and the main material risk is a rare impairment of USDe’s backing under extreme tail events, as illustrated by our recent research paper Stress Testing Ethena: A Quantitative Look at Protocol Stability. In this paper, we show that Ethena’s design, which combines delta-neutral hedging, off-exchange custody with nullification, diversified venues, and stablecoin-heavy collateral, keeps routine volatility and funding swings contained. Stress tests demonstrate that meaningful losses only occur under extremely rare tail events, with probabilities near zero in normal conditions.

However, as USDe and sUSDe bridge between Ethereum and BNB through LayerZero, the minting and redeeming of sUSDe to its USDe underlying is not native to the chain. Hence, to perform arbitrages of both asset rates to their backing, it is necessary to bridge them to Ethereum through the use of LayerZero. The system uses two contracts: an adapter on Ethereum that escrows the canonical tokens and an OFT on BNB that mints and burns. For Ethereum to BNB transfers, users approve the adapter and call send; the adapter locks the tokens, the LayerZero endpoint sends the message, and the BNB OFT mints the same amount to the recipient after removing decimal dust so the amount sent matches the amount received. Thanks to this design, bridging is completed within minutes. Therefore, in extreme market conditions where liquidations create sudden sell pressure for the assets on BNB and local liquidity is insufficient, collateral can be bridged back to Ethereum to access its deeper liquidity, allowing liquidations to proceed smoothly and reducing systemic risk.

Finally, as sUSDe accrues yield, its design naturally supports looping strategies where users borrow stablecoins against sUSDe and redeploy recursively to increase exposure. While a similar strategy presents itself with USDe collateral and stable debt in order to leverage the exposure to the Ethena point system. Therefore, based on the above, we believe including sUSDe and USDe within the stablecoin E-Mode is justified, and the structural linkage between the two ensures minimal basis risk while more permissive risk parameters enable higher user capital efficiency.

Specification

Based on the above, we present our recommended risk parameters for the E-mode below.

Parameter	Value	Value
Asset	sUSDe	USDe
Collateral	Yes	Yes
Borrowable	No	Yes
Collateral Factor	89%	90%
Liquidation Threshold	91%	92%
Liquidation Incentive	8%	6%

Disclaimer

Chaos Labs has not been compensated by any third party for publishing this recommendation.

[Omar.bnb]

the liquidation incentives is crazy high for an E-mode…

[chaoslabs]

Overview

Following the recommendation for the sUSDe/USDe Stablecoin Pool on the Venus BNB instance, Chaos Labs proposes expanding the pool to include USDT, USDC, and PT-USDe-30OCT2025. We believe this will further enhance capital efficiency without adding risk. In this post, we outline our analysis of the E-mode and the listing of PT-USDe-30OCT2025.

USDT & USDC E-Mode

We recommend adding USDT and USDC into the stablecoin E-Mode as debt assets. This inclusion does not introduce additional risk. Both USDT and USDC have long-established track records, dominant market share, and deep liquidity across centralized and decentralized venues on BNB. Their pegs to the U.S. dollar are reinforced by reserve backing and active arbitrage, which also ensures strong alignment with USDe. As a result, repayment exposure remains in the same dollar-pegged risk category, preserving the integrity of the E-Mode design.

At the same time, this addition enhances capital efficiency. Currently, USDT is the largest debt asset against sUSDe in the Venus BNB Core Pool, accounting for 72% of total outstanding debt. Furthermore, PT-USDe is expected to be used primarily as collateral to borrow USDe, USDT, and USDC in looping strategies. Allowing USDT and USDC as borrowable assets within E-Mode significantly improves efficiency for users and can drive growth of the instance. Because of the alignment between USDT, USDC, and USDe, along with USDe’s structural linkage to PT-USDe and sUSDe, systemic risk remains controlled.

PT-USDe-30OCT2025

In parallel, we recommend adding PT-USDe-30OCT2025 to the newly established Stablecoin E-Mode. PT-USDe represents the principal token of USDe, expiring on October 30, 2025. Like other Pendle PTs, its price is discovered through market trading but converges to 1 at maturity, reflecting its guaranteed redemption value. This pricing path is shaped by the discounting effect of implied yield and the remaining time to maturity, with the Pendle AMM concentrating liquidity closer to parity as expiry approaches. As illustrated below, the current minimum price for PT-USDe-30OCT2025 is approximately 0.975 USDe.

Supply Cap

The chart below illustrates the slippage within Pendle’s native AMM when swapping PT-USDe-25OCT2025 into the underlying. At the time of writing, liquidity only supports swaps of roughly 120K before incurring 3% slippage, underscoring the limited depth of the pool. This reflects the first step of the redemption path, where PT is exchanged for SY, and SY is then unwrapped atomically into the underlying asset.

The second step under normal conditions is that the underlying asset can be traded directly into more liquid tokens. However, in the case of PT-USDe, the underlying, USDe, is not native to the BNB chain. While bridging via LayerZero’s OFT standard enables USDe transfers in just a few minutes, it still introduces additional settlement latency and operational complexity compared to native liquidity. Given these constraints, we recommend setting the supply cap conservatively at 1M.

Collateral Factor, LT, and LI

Given the expected looping use, we propose making PT-USDe-30OCT2025 non-collateralizable and non-borrowable in the core market, and only usable as collateral in the stablecoin E-Mode.

Although PT-USDe’s expected similar price trajectory with the debt asset might support more permissive parameters, conservative settings are warranted for PT-USDe-30OCT2025 due to several concerns. First, the token carries a minor to moderate level of duration risk, as yield shifts can still influence PT pricing while time remains to maturity. In addition, the underlying asset, USDe, is not native to BNB, meaning redemptions into more liquid assets may require bridging via LayerZero, which introduces settlement latency.

Furthermore, Pendle’s AMM is structurally bounded by a maximum implied yield range, and if this range is breached the PT price falls outside the AMM’s effective curve. Because liquidity in the pool is relatively shallow, even moderate-sized trades can push the pool toward its imbalance threshold, effectively forcing the AMM oracle to pin at its minimum PT price. At that point, on-chain price discovery freezes while trading may continue at lower levels on the order book. As a result, two additional risks emerge: protocols relying on the AMM oracle may overstate PT collateral value, and liquidations become more difficult as AMM liquidity dries up, leaving only fragmented order book liquidity.

Taken together, these factors highlight the importance of a slightly conservative collateral settings. Specifically, we recommend setting CF at 90%, LT at 92%, and LI at 8%.

Pricing

If we reference the previous methodology for pricing PT-USDe, our recommendation was to use a combined oracle that incorporates Pendle’s 30-minute TWAP for the PT-USDe/USDe market rate together with the Chainlink’s USDe/USD feed.

However, in this post we also propose a new pricing mechanism for USDe, as we believe it offers a more efficient approach while remaining well-contained from a risk perspective. Specifically, we recommend using Venus’s Resilient Oracle framework, configured with the USDT/USD Chainlink price feed as the main oracle, and the USDe/USD Chainlink feed as both pivot and fallback. In line with this, we suggest setting the validation bounds between the main and pivot/fallback oracles at 0.94–1.06. This design effectively insulates pricing from USDe’s short-term volatility by relying on the USDT/USD oracle under normal conditions. At the same time, we believe this configuration strikes the right balance: preventing unnecessary liquidation cascades during temporary depegs while still ensuring protection if a genuine structural failure occurs, as the 6% tolerance reflects approximately twice the largest temporary depeg observed for USDe (around 0.97) across multiple chains over the past 18 months.

If Venus adopts the resilient oracle approach for pricing USDe, based on the reasoning outlined above, we believe it would be prudent to slightly increase the risk parameters for PT-USDe, sUSDe, and USDe within the stablecoin E-Mode. Accordingly, in the specification section we provide two sets of E-Mode risk parameters, reflecting the outcomes under both pricing methodologies.

Specification

BNB Core

Parameter	Value
Asset	PT-USDe-30OCT2025
Collateral	No
Borrowable	No
Supply Cap	1,000,000
Borrow Cap	-
Collateral Factor	-
Liquidation Threshold	-
Liquidation Incentive	-
Kink	-
Base	-
Multiplier	-
JumpMultiplier	-

Stablecoin E-Mode Parameters (USDe priced via USDe/USD Chainlink Oracle)

Parameter	Value	Value	Value	Value	Value
Asset	sUSDe	USDe	PT-USDe-30OCT2025	USDT	USDC
Collateral	Yes	Yes	Yes	No	No
Borrowable	No	Yes	No	Yes	Yes
Collateral Factor	89%	90%	90%	-	-
Liquidation Threshold	91%	92%	92%	-	-
Liquidation Incentive	8%	6%	8%	-	-

Stablecoin E-Mode Parameters (USDe priced via Resilient Oracle with USDT/USD Chainlink Oracle as core and USDe/USD Chainlink Oracle as pivot/fallback)

Parameter	Value	Value	Value	Value	Value
Asset	sUSDe	USDe	PT-USDe-30OCT2025	USDT	USDC
Collateral	Yes	Yes	Yes	No	No
Borrowable	No	Yes	No	Yes	Yes
Collateral Factor	89.5%	90%	90.5%	-	-
Liquidation Threshold	91.5%	92.5%	92.5%	-	-
Liquidation Incentive	8%	6%	8%	-	-

PT-USDe-30OCT2025 CAPO Parameter

Parameter	Value
Annual Growth Rate	0.00%
Snapshot Interval	30d
Snapshot Gap	4%

Disclaimer

Chaos Labs has not been compensated by any third party for publishing this recommendation.

[Omar.bnb]

I have never seen more bullish recommendations from chaos, kudos for stepping up your game and actually providing the kind of parameters that the protocol needs.

[Xvs_Believer]

A huge clap

Good job

[chaoslabs]

Overview

Chaos Labs supports the creation of a BTC E-Mode with the inclusion of BTCB, SolvBTC, and xSolvBTC. Given the structural linkages between these assets, we believe this will significantly enhance capital efficiency for users while not introducing additional risks. Below, we present our analysis and initial risk parameter recommendations.

At this stage, we do not support the inclusion of PT-SolvBTC.BNB-18DEC2025 and PT-xSolvBTC-18DEC2025 in the newly established BTC E-Mode. Our rationale is outlined in the second half of this post.

BTCB & SolvBTC & xSolvBTC

Given the structural linkage between SolvBTC, xSolvBTC, and BTCB, we expect their valuations to remain highly correlated, and therefore consider more permissive risk parameters between them unlikely to introduce additional systemic risk.

SolvBTC

SolvBTC is a non-yield-bearing reserve token issued by Solv Protocol to represent BTC across EVM-compatible chains. Unlike LRT, SolvBTC is not deployed into external protocols and would therefore insulated from smart contract exploits, slashing penalties, or validator failures. Its primary role is to serve as the foundational BTC wrapper within Solv Protocol’s infrastructure and as the base asset for minting xSolvBTC. As of this writing, SolvBTC is backed 1:1 by reserves composed of approximately 99% native BTC held in verifiable custody. Solv Protocol utilizes the Staking Abstraction Layer (SAL) to standardize and secure the cross-chain minting process: SAL monitors Bitcoin mainnet for valid deposits, generates cryptographic deposit proofs, and relays them to EVM chains where the minting contracts validate the proof and issue SolvBTC.

SolvBTC Transparency Dashboard

Because SolvBTC is designed to mirror the value of native BTC and is secured through verifiable custody and SAL’s cross-chain infrastructure, it behaves similarly to other major BTC wrappers like BTCB, which is issued by Binance and backed by BTC under its own custody model. Given that both SolvBTC and BTCB are pegged 1:1 to native BTC and rely on custodial reserves for integrity, their market values are expected to remain tightly aligned.

xSolvBTC

As we previously analyzed in this post, xSolvBTC is a yield-bearing LRT issued by Solv Protocol, representing BTC staked to the Babylon network and secured through the SAL. Unlike our earlier analysis, following recent contract upgrades, xSolvBTC now supports atomic minting and redemption via the XSolvBTCPool contract, where SolvBTC is burned to mint xSolvBTC, and vice versa, in a single transaction. SolvBTC and xSolvBTC are therefore tightly coupled through this mechanism, as SolvBTC is the sole asset used for both entry and exit.

Although xSolvBTC maintains close price tracking to SolvBTC under normal conditions, it introduces additional risk through its exposure to Babylon’s validator slashing. xSolvBTC derives yield from BTC staked via Babylon, and validator misbehavior, specifically double-signing (equivocation), can trigger a slashing event that permanently reduces the underlying collateral, thereby lowering xSolvBTC’s NAV. However, Babylon’s slashing framework is deliberately narrow and capped: penalties are currently limited to 0.1% of the BTC delegated to the offending Finality Provider and do not apply to downtime or missed votes. The current fixed slashing scope ensures that price deviation between xSolvBTC and SolvBTC remains small and contained, preserving their tight price alignment under most conditions. However, as Babylon’s implementation of restaking remains in its infancy, the future staking penalty could change.

Reccomendation

Given the high correlation between the three assets and the strong demand shown on the Venus market for SolvBTC and xSolvBTC looping with BTC.b we recommend the creation of a BTC E-Mode, including the three previously mentioned assets. However, given the uncertainty regarding future changes to the Babylon protocol’s slashing rules and the presence of atomic conversions between SolvBTC and xSolvBTC, which presents the risk that the backing of the two assets may be partially intertwined during the unstaking process, we recommend initially adopting slightly conservative parameters for the E-Mode.

PT-SolvBTC.BNB-18DEC2025

SolvBTC.BNB

SolvBTC.BNB is a Solv Vault strategy on BNB Chain that uses SolvBTC as collateral to borrow BNB and deploy it into Aster’s asBNB module, which aggregates Launchpool, Megadrop, and HODL-er rewards. The vault combines these returns by periodically converting earned BNB-based rewards back into SolvBTC to increase the vault’s NAV while distributing protocol incentive tokens as airdrops when applicable. This structure exposes depositors to SolvBTC’s base collateral plus the added yield and smart contract risks from leveraged BNB deployment and Aster’s reward mechanisms.

To mint SolvBTC.BNB, users deposit BTCB or SolvBTC via the Solv Protocol frontend. Behind the scenes, this triggers a subscription to an OpenFundMarket pool, which mints an ERC-3525 Semi-Fungible Token (SFT), specifically, an OpenFundShare, representing ownership in a yield-bearing BNB strategy. This SFT includes both a tokenId and a slot, where the slot identifies the strategy type, and the token’s balance reflects the user’s share. The SFT is then deposited into the SolvBTCMultiAssetPool via the SolvBTCRouter. This router validates that the SFT belongs to a whitelisted slot and meets minimum balance criteria before allowing minting. Once validated, SolvBTC.BNB is minted 1:1 to the user’s wallet. This entire process is atomic, meaning the subscription, SFT creation, deposit, and token minting all happen in a single transaction.

To redeem SolvBTC.BNB, users initiate a redemption request through the Solv Protocol interface. The token is burned upon submission, and the corresponding yield-bearing OpenFundShare (ERC-3525 SFT) is transferred back to the user, representing their claim on the underlying BNB strategy. However, redemptions are not atomic: instead of immediate settlement, redemptions are queued and processed in batch cycles three times per month. The redemption windows are based on the date the request is submitted, and fulfillment occurs on the 10th, 20th, or end of each month (or the next business day). Behind the scenes, the SFT is redeemed through the OpenFundMarket and OpenFundRedemption contracts, where its NAV is calculated and settled based on the most recent valuation of the strategy.

Importantly, at the time of writing, there is no on-chain liquidity for SolvBTC.BNB. And since protocol redemptions are non-atomic and follow a fixed processing schedule, there is currently no way to exit the position immediately.

PT-SolvBTC.BNB

Like other Pendle PTs, PT-SolvBTC.BNB represents the discounted principal value of its underlying, converging to 1 at maturity on December 18, 2025. This convergence reflects the guaranteed redemption path of the underlying SolvBTC.BNB, with the pricing shaped by the implied yield and the time remaining to maturity. As with all PT tokens, the Pendle AMM progressively concentrates liquidity closer to parity as expiry approaches, ensuring more efficient pricing and reduced slippage near maturity.

As shown in the figure, the minimum PT price is approximately 0.975, with a remaining 0.23 years to maturity. This indicates the presence of a moderate level of duration risk, meaning that yield movements over the remaining time still have a material impact on PT pricing.

Recommendation

Based on the analysis above, we do not recommend listing PT-SolvBTC.BNB-18DEC2025 or including it in BTC E-Mode at this time. As the underlying asset of this PT, SolvBTC.BNB presents several concerns—primarily due to its complex yield strategy that involves interacting with multiple protocols, each carrying its own distinct risk profile. More importantly, the asset currently lacks the liquidity required to function safely as collateral.

As of this writing, Pendle AMM shows strong on-chain liquidity for the PT itself, allowing trades of nearly 1,000 PT-SolvBTC.BNB with low slippage. However, in stressed market conditions, the correct exit path for PT holders is: PT → underlying asset → base asset (e.g., BTC). As detailed in our previous analysis, SolvBTC.BNB, the underlying asset, has no native on-chain liquidity, and its redemption process back to SolvBTC is non-atomic and subject to a fixed redemption schedule. In practice, this means there is no immediate exit route for the collateral under volatile conditions, which may prevent timely liquidations and increase the risk of bad debt.

Given these factors, we recommend withholding the listing of PT-SolvBTC.BNB for now. Should the underlying asset’s liquidity improve, we will re-evaluate its eligibility based on market conditions and protocol safety.

PT-xSolvBTC-18DEC2025

Recommendation

We do not recommend listing PT-xSolvBTC-18DEC2025 or including it in BTC E-Mode at this time. As of this writing, the PT-xSolvBTC market is extremely small, with an outstanding supply of only two PT tokens. Additionally the liquidity on the market is limited, with around $1M in total liquidity, approximately 81% of which sits in SY tokens. Thie combination of limited liquidity and low outstanding PT supply indicates a lack of demand for the market. As such we recommend holding off on listing PT-xSolvBTC as of now.

Specification

BTC E-mode

Parameter	Value	Value	Value
Asset	xSolvBTC	SolvBTC	BTCB
Collateral	Yes	Yes	No
Borrowable	No	No	Yes
Collateral Factor	81%	83%	-
Liquidation Threshold	83%	85%	-
Liquidation Incentive	4%	4%	-

Disclaimer

Chaos Labs has not been compensated by any third party for publishing this recommendation.

[Omar.bnb]

Yet another awful recommendations by chaoslabs that will cost us almost a billion in TVL and active loans, you really have no clue what yield farmers are looking for.

83% LTV in E-mode? what a joke, you should be fired immediately. There is really no nicer way to say this, enough is enough.

[Xvs_Believer]

Lol I patiently read through all this and Chaolabs come out with this parameters?

83% cf on e-mode lololololol

E-mode or Normal actually?

Seriously I’m doubting fairness of Chaolabs now. What the point of using e-mode if parameters is so safe ?

Don’t waste our time , it’s frustrating

What if we failed to create momentums because of these poor recommandations, is Chaolabs responsible?

They should be accountable of KPI result

[Omar.bnb]

its just super funny how chaos recommends listing usde and susde when theres 0 on chain liquidity on bnb chain, PT-usde on chain liquidity is terribly low with almost 0 demands on bnb chain, but I guess solv finance is not paying their bills to chaos so they decide to be harsher on them, not listing PT-solvBTC.BNB will cost venus hundreds of millions in TVL and active loans, its literally the highest yield generating BTC asset out there.

[C0sty]

@chaoslabs what’s the real reason behind not listing PT-solvBTC.BNB?

[Frayst]

It is starting to be a joke Chaolabs. Each time you push a recommandation, Venus cannot be competitive regarding the markets versus other lendings platform where you also manage the risk…

No one will use e-mode and loop with these parameters. It is time to be less conservative.

[Tomm]

I strongly disagree with Chaos Labs’ overly conservative BTC E-mode proposal. Setting the Collateral Factor at only ~80% for xSolvBTC and SolvBTC completely defeats the purpose of E-mode — there’s no real looping potential. It should be at least 90% to meet market expectations and attract meaningful usage.

Moreover, excluding PT assets is a major mistake. These assets are the key source of yield and user engagement. Without them, this proposal won’t drive adoption or TVL growth.

Let’s not repeat the same mistake as before with wstETH/weETH on BNB Chain, where Chaos Labs’ rejection caused Venus to lose significant supply volume. We shouldn’t limit Venus’ growth again with another restrictive approach.

[Tomm]

You guys take high service fees from Venus protocl, but provide such services. It is time to consider letting Venus terminate its contract with you! Because Chaos Labs does not consider Venus users or TVL at all.