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

e-mode offers aggressive lending. Chaoslabs needs to provide the analytics and data to match. they’re not doing enough for the fees we’re paying. i am a Venus holder, I want the new Venus team to take this issue seriously.

1 Like

We could proceed now with the parameters recommended by Chaos Labs and continue the discussion here. Any adjustments to the Collateral Factor or Liquidation Threshold, if needed, could be implemented through a Critical VIP in the coming days. Let’s set the flywheel in motion

1 Like

Scope and Objective

While we understand and hear the community concerns regarding the proposed parameters in the BTC E-Mode, Chaos Labs’ mandate on Venus is to minimize the protocol’s probability-weighted loss while enabling sustainable usage. Parameter choices are a direct function of asset design, liquidation path reliability under stress, oracle behavior, and exits/liquidity latency. TVL and “loop potential” are outcomes, not inputs. Where external components introduce additional tail risk or slow liquidation, parameters must incorporate a safety buffer. This approach is consistent across assets and chains.

SolvBTC E-Mode

We support creating a BTC E-Mode comprising BTCB, SolvBTC, and xSolvBTC because these assets are tightly linked to BTC and to each other, and the configuration meaningfully reduces cross-asset basis risk relative to the isolated markets.

Solv has recently introduced atomic mint/redeems between xSolvBTC and SolvBTC. Given the 7-day duration of Babylon unstaking, during a brief period following the redemptions of xSolvBTC to SolvBTC, a portion of the SolvBTC backing remains susceptible to Babylon’s Slashing rules. Although the NAV impact from slashing is capped under the current Babylon rules, Babylon is a quickly developing project, and the current slashing rules are expected to change meaningfully after the launch of Babylon’s Development Phase 3. Taking that into consideration, it is unfeasible and impractical to reduce the risk parameters of an already listed asset, as enforcing the more conservative parameter changes would cause the liquidation of active users in the market. As such, given the atomic conversion coupled with delayed Babylon unbonding briefly intertwines the asset backings. The asset necessitates a buffer so that liquidations remain executable if, following a change of Babylon’s slashing rules, a slashing event occurs.

Chaos Labs is actively collaborating with the Solv team on multiple areas that directly reduce the risk of the Babylon staked asset, and therefore minimize the E-Mode risks; however, this collaboration is still ongoing, and relying on optimistic assumptions about redemption timing or NAV updates remains unfeasible until those have been implemented.

PT-SolvBTC.BNB-18DEC2025

The correct liquidation path for a principal token is PT → underlying vault asset → base asset, executed quickly and at bounded slippage in stress. PT-SolvBTC.BNB fails this criterion today. The underlying, SolvBTC.BNB, has no native on-chain liquidity and relies on non-atomic, scheduled redemptions. In a drawdown, liquidators cannot deterministically traverse PT to BTC within the liquidation window, even if the PT AMM itself shows depth.

In addition, the underlying strategy stacks protocol risk across components such as Lista and Aster. We have flagged aggressive collateral behaviors at Lista that, if transmitted through composite products, could elevate Venus’ tail risk. Our role is to ensure that such risk is not imported via assets whose unwind depends on Lista’s state.

Introducing this duration-plus-redemption latency into Venus collateral would raise the probability of non-executed liquidations and bad debt.

Closing

The correct metric is the protocol’s expected shortfall under adverse but plausible scenarios. Aggressive parameters that assume instant redemptions, ignore structural redemption schedules, or import third-party leverage risk (e.g., from Lista) increase tail loss. Other lending markets may elect to price that tail differently; Venus has historically prioritized solvency and orderly liquidations, and our recommendations are calibrated to that objective.

The BTC E-Mode proposal enhances capital efficiency, supported by liquidation mechanics and oracle reliability, while avoiding configurations that would compromise solvency under stress. The initial thresholds are intentionally conservative, given the state of the asset and its dependencies, but they are not static.

Once the controls and updates covered in this post are live, observable over a non-trivial interval, and integrated into Venus’ risk checks, we will recompute the stress scenarios and publish updated parameter windows. If the data indicate that liquidation certainty increases and effective slashing exposure is immaterial, a higher CF/LT in BTC E-Mode will follow.

1 Like

I have honestly been lazy to explain the real potential of PT-SolvBTC.BNB on the core pool, to some people I might sound like I just have a personal vendetta with CL, but thats really not the case, let me explain it to the community in details so you will see where I’m coming from.

SolvBTC.BNB is a yield bearing token that generates up to 6% APY, there is literally no other asset out there that can give you this much on BTC, so the demand for this asset is insane and it will definitely explode on Venus, if proper parameters are provided upon listing, users can achieve up to 40%-50% APY on their BTC, that means you will get .5 BTC a year for holding 1BTC, so imagine BTC holders realizing this opportunity, the pool will be filled up non stop and it will drive huge borrow demand due to BTC borrow rate being under 1% on Venus.

But thats not the beauty of it, the potential is way beyond the BTC pool for Venus, the reason its called SolvBTC.BNB is because of the strategy that Solv uses to generate such high yield on BTC, they basically borrow more BNBs from Venus for every new SolvBTC.BNB in circulation because the yield strategy is: deposit SolvBTC into SolvBTC.BNB vault —>Solv team then deposit your SolvBTC on Venus and borrow BNBs to earn binance airdrop rewards.

So basically for every new PT-SolvBTC.BNB on Venus, the protocol will benefitting from:

  1. New BTC loan because users want to loop for high APY

  2. SolvBTC deposits because Solv team wants to execute the yield strategy

  3. New BNB loan by solv team to execute the SolvBTC.BNB yield strategy

To sum it up, we will be getting 2 sources of new TVL (SolvBTC + PT-SolvBTC.BNB) and 2 sources of active loans ( BTC + BNB ) which is crazy if you think about it, and not to mention the benefits of enhancing our partnership with pendle which was the main course for AAVE’s stablecoins success for this cycle.

3 Likes

I highly ask Chaolabs and Solv team to work together to solve this and have solvBTC.BNB available in Venus E-mode

We can’t keep missing opportunity like we used to do in the past , our new focus and goal should be growth ! That’s should be paramount of every works

It’s frustrating that we keep being sealed , we need to be released

1 Like

Overview

Chaos Labs supports creating a BNB E-mode including asBNB, slisBNB, and WBNB, as their strong structural linkage ensures highly correlated value behavior. This setup enhances capital efficiency for users without introducing material additional risk. Below, we present our analysis and initial parameter recommendations.

slisBNB

slisBNB is Lista DAO’s liquid staking derivative for BNB, representing tokenized staked positions on the BNB Smart Chain. slisBNB accrues yield from BNB staking rewards. These rewards are auto-compounded and reflected in the increasing slisBNB/BNB exchange rate, allowing holders to earn yield through value appreciation rather than additional token distribution.

slisBNB is minted when users deposit BNB into Lista DAO’s staking contract. The deposited BNB is delegated to Lista’s whitelisted validators on the BNB Smart Chain through the StakeHub contract, participating in PoS consensus to earn native staking rewards. The contract then issues slisBNB to the user at an exchange rate determined by the total pooled BNB and the current slisBNB supply. This exchange rate gradually increases as staking rewards accrue, meaning each slisBNB represents a larger share of the underlying BNB over time. All minting operations are handled by the StakeManager contract, which controls issuance and ensures consistency between the total staked BNB and the circulating slisBNB supply. This minting process is atomic — users receive slisBNB instantly without waiting for validator confirmation or unbonding delays.

Redeeming slisBNB works as the reverse of minting. When a user initiates a redemption, their slisBNB is burned, and an equivalent amount of BNB is queued for withdrawal from Lista DAO’s validator pool. Unlike minting, the redemption process is not atomic: it involves a mandatory unbonding period (currently at 7 days) to allow delegated BNB to be unstaked from validators. Once the unbonding period ends, the user can claim their BNB directly.

For slisBNB holders seeking an immediate exit, they can instead utilize on-chain liquidity: primarily through the slisBNB/WBNB liquidity pool on PancakeSwap, which holds approximately $6.37M TVL, and the slisBNB/WBNB pool on THENA, with around $321.46K TVL. Below, we present the aggregated slisBNB liquidity over time. Over the past six months, liquidity has consistently exceeded $4M and has shown a clear upward trend over the past two months, indicating strong exit capacity under stressed market conditions.

asBNB

As we analyzed in this post, asBNB is a liquid staking derivative of BNB issued by Aster and powered by Lista DAO. It represents staked BNB that continues to earn yield from the BNB ecosystem, including Binance Launchpool rewards that increase its net asset value and Binance Hodler and Megadrop rewards that are converted and distributed as additional asBNB.

asBNB is created when users deposit BNB or slisBNB into Aster’s system. If BNB is used, it’s first converted into slisBNB through Lista DAO’s staking process. That slisBNB is then sent to Lista’s infrastructure, where it becomes clisBNB — an internal accounting token that tracks each user’s staked position and the rewards earned from Binance Launchpools. As Launchpool rewards accumulate, they are converted back into BNB and added to the total pool value, which increases the net asset value of asBNB. If a Launchpool is ongoing, minting requests are queued until it ends to ensure fair value updates.

When a user redeems asBNB, the process works in reverse to minting. The user calls the burnAsBnb() function on Aster’s Minter contract, which transfers their asBNB back to the contract. The Minter then calculates how much slisBNB that amount represents using the current NAV. The asBNB tokens are burned, and an equivalent amount of slisBNB is withdrawn from the YieldProxy contract and sent back to the user’s wallet. If there’s an ongoing Launchpool, withdrawals are temporarily queued until the pool ends and the NAV is updated, ensuring rewards are properly accounted for before redemption. Once processed, the user always receives slisBNB, not BNB, even if they originally deposited BNB to mint asBNB.

Recommendation

Given the yield-bearing nature of slisBNB and asBNB and their expected leverage looping use case, we recommend designating both assets as collateral-only and non-borrowable within the BNB E-Mode, with slisBNB not being permitted either as collateral or as borrowable outside of this mode.
The parameters for slisBNB as collateral asset outside of the BNB E-Mode will be provided at a later time, following additional coverage of the asset.

For slisBNB, its nature as a liquid staking derivative directly backed by staked BNB ensures that its intrinsic value closely tracks BNB’s price, with only gradual appreciation from staking rewards. As a result, its price behavior remains highly correlated to WBNB, justifying the use of more permissive risk parameters within the E-mode framework.

At the same time, the market exchange rate between slisBNB and WBNB has remained highly stable relative to its internal exchange rate over the past year, with a maximum deviation of only 77 bps. This demonstrates that slisBNB’s collateral pricing has closely tracked its actual market value, posing no evidence of overpricing risk. Such consistent alignment further supports the rationale for adopting permissive risk parameters for slisBNB within the BNB E-mode.

It is reasonable, however, to assign asBNB more conservative parameters than slisBNB, given the additional abstraction layer in its staking and redemption flow. That said, since users can withdraw asBNB to slisBNB atomically, the exit path for both assets under stressed market conditions is effectively the same. Although conversions from asBNB to slisBNB are not immediate during ongoing Launchpools, no new Launchpool events have taken place since May 2025, which effectively means that asBNB’s redemption process currently operates without delay. However, given the uncertainty over whether future Launchpools may resume, we recommend maintaining slightly more conservative risk parameters for asBNB relative to slisBNB for now. Should it become clear that no further Launchpool events will occur, we will revisit this decision and consider aligning asBNB’s parameters with those of slisBNB.

Meanwhile, we expect the implementation of the BNB E-Mode to boost leverage-looping behavior. To align with this, we are also preparing a proposal to adjust the WBNB and BNB IRM, aiming to maximize users’ capital efficiency without introducing additional risk.

Specification

slisBNB Core Listing parameters

Parameter Value
Asset slisBNB
Collateral No
Borrowable No
Supply Cap 20,000
Borrow Cap -
Collateral Factor -
Liquidation Threshold -
Liquidation Incentive -
Kink -
Base -
Multiplier -
JumpMultiplier -

BNB E-Mode Parameters

Parameter Value Value Value
Asset asBNB slisBNB WBNB
Collateral Yes Yes No
Borrowable No No Yes
Collateral Factor 89% 90% -
Liquidation Threshold 92% 93% -
Liquidation Incentive 4% 4% -

Disclaimer

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

Again … Those recommandations is poor

Way too conservative

It’s so frustrating!