Overview
Chaos Labs supports the listing of PT-slisBNBx-24JUN2026 on Venus’ BNB Core Market. Below, we present our analysis and recommended risk parameters.
slisBNBx
slisBNBx is a non-transferable, ERC20-compatible receipt token whose standard transfer and approval functions are explicitly disabled, ensuring it can only be minted and burned by authorized system contracts. Minting and burning are strictly gated by the onlyMinter modifier, reflecting slisBNBx’s role as protocol-internal accounting rather than a user-circulating asset. It is minted when users supply BNB or slisBNB through supported collateral pathways—including CDPs, Lista Lending, or LP mechanisms—and is automatically burned when the corresponding underlying collateral is withdrawn. In other words, the primary purpose of slisBNBx is to serve as on-chain proof of collateral recognition within Lista DAO, enabling user collateral to remain eligible for Binance Launchpool participation while simultaneously being used for lisUSD borrowing, Lista lending, or other core protocol functions.
Given that slisBNBx is inherently non-transferable, it is unsuitable for direct market trading. To address this constraint, Pendle and Lista implemented a dedicated integration layer. Users interacting through Pendle do not directly receive or hold the non-transferable slisBNBx certificate. Instead, assets supplied via Pendle are routed into a Lista provider contract(SlisBNBProvider), which deposits the slisBNB-equivalent collateral into Lista DAO and maintains the associated slisBNBx accounting position internally, while Pendle issues transferable market-facing representations on top of that locked position.
For clarity, clisBNB and slisBNBx refer to the same receipt token at the protocol level; the difference in naming is purely the result of a historical rebranding, so readers should treat the two terms as interchangeable throughout the remainder of this article.
PT-slisBNBx-24JUN2026
Mint
When a user enters the PT-slisBNBx market on Pendle, they are not minting or receiving clisBNB directly. Instead, the Pendle SY-clisBNB contract acts as an execution and accounting wrapper that bridges user-supplied assets into Lista DAO’s internal clisBNB system. The user supplies either BNB or slisBNB to the SY contract. If BNB is supplied, it is either staked through Lista’s StakeManager or swapped on secondary markets, thereby converting it into slisBNB. Once the SY contract holds slisBNB, it routes that slisBNB into Lista by calling the SlisBNBProvider via provide(amount, delegatee). This call makes the provider pull slisBNB from the SY contract.
Before processing the new deposit, the provider first aligns the caller’s existing position with what is already recorded in Lista DAO, ensuring that the internal receipt balances correctly reflect the collateral currently deposited. Once synced, the provider executes the actual “lock + receipt-mint” step. Inside SlisBNBProvider._provideCollateral, the provider routes the slisBNB into Lista’s CDP system by calling dao.deposit(_account, token, _amount). After the deposit, it computes how much receipt LP to mint using the provider’s configured rates: it converts the deposited slisBNB amount into a total LP amount via lpAmount = _amount * exchangeRate / 1e18. This LP amount is then split according to userLpRate:
- The delegate portion,
holderLpAmount = lpAmount * userLpRate / 1e18, is minted to the delegatee address via lpToken.mint(_holder, holderLpAmount).
- The remaining portion,
reservedLpAmount = lpAmount - holderLpAmount, is minted to the protocol’s reserve address using lpToken.mint(lpReserveAddress, reservedLpAmount).
In another word, the receipt token, slisBNBx, created by this step does not go back to the SY contract, it is minted to the designated delegatee address.
The deposit() function on the Interaction contract serves as the canonical entry point for crediting collateral into Lista’s CDP system. In practice, the Interaction contract executes the call, records the deposited slisBNB under the SY contract’s address as the participant, and updates CDP accounting so that the position’s collateral is reflected through locked(token, participant). From the CDP system’s perspective, the SY contract now owns an increased amount of deposited slisBNB collateral, which becomes eligible for downstream protocol logic such as collateral valuation, borrowing power, and Launchpool qualification.
After the provider call completes, execution returns to the Pendle SY contract. At this point, the Lista-side flow is finished: the slisBNB has been deposited into the GemJoin contract under the SY contract’s address, and the corresponding slisBNBx receipt has been minted to the designated delegatee. The SY contract then mints SY-clisBNB shares on the Pendle side. The newly minted SY is sent to the Pendle AMM, and PT is withdrawn from the Pendle AMM and transferred to the user address.
Crucially, SY-clisBNB minting is based strictly on the amount of slisBNB deposited. In practice, in PendleClisBNBSY._deposit, the contract ignores the return value of the provider call and explicitly returns amountDeposited. The base SY logic uses this returned value to mint the same amount of SY-clisBNB ERC20 shares to the user’s specified recipient. In other words, all exchange-rate logic is handled entirely within the Lista provider and CDP system for the purpose of Launchpool reward accounting and distribution, rather than at the SY layer.
Redeem
Redeeming PT tokens begins by converting PT into SY. If a user wishes to redeem PT before maturity, they must return their PT tokens to the Pendle AMM or order-book to acquire SY, which is subject to slippage due to reliance on secondary market liquidity. Once PT has matured, the user can redeem PT into SY and then into the underlying asset on a 1:1 basis without market exposure.
After SY-clisBNB shares are acquired on Pendle, the SY contract requests the corresponding slisBNB to be released from its position in Lista DAO. From this point on, redemption is executed through Lista’s SlisBNBProvider and Interaction contract calls. The SY contract calls the provider via BaseTokenProvider.release(), making the SY contract caller and therefore the position owner being withdrawn from. Inside _withdrawLp, the provider first calls _syncLp(msg.sender) to reconcile its internal receipt accounting against the DAO’s current locked collateral for that address (dao.locked(token, account)). In SlisBNBProvider, this sync uses exchangeRate and userLpRate to compute the expected user vs reserve receipt balances and mints/burns LP as needed.
Once the provider’s accounting is synced, it performs the actual unwind in _withdrawLp: it calls dao.withdraw(account, token, amount) to reduce the SY contract’s collateral position, and then burns the corresponding receipt LP via _burnLp(account, amount) using the provider’s exchangeRate and userLpRate rules. After the DAO withdrawal completes, the provider transfers the redeemed slisBNB out to the user-specified receiver. If the DAO-side withdrawal cannot be executed under the DAO’s constraints (e.g., insufficient withdrawable collateral for that position), dao.withdraw reverts and the entire redemption transaction reverts with it.
Considering the full redemption path from PT-slisBNBx to BNB, the process follows the sequence: PT-slisBNBx → SY-slisBNBx → slisBNB → BNB. At the PT layer, users may either hold the position until maturity or exit earlier via Pendle’s secondary-market liquidity. This exit is atomic but subject to available on-chain liquidity. The SY-to-slisBNB conversion follows the on-chain redemption flow described above and is atomic. Currently, the SY contract only supports redemption into slisBNB. As a result, users who initially deposit BNB to mint PT-slisBNBx can only redeem into slisBNB at the SY layer. The final conversion from slisBNB to BNB mirrors the PT-to-SY step. Users may either exit via the native unstaking pathway, which is subject to a protocol-defined delay of 7–8 days, or exit atomically through secondary-market liquidity, subject to available liquidity.
Reward Distribution
YT-clisBNB holders are exposed to two sources of yield: the internal staking yield of slisBNB and the Binance Launchpool rewards. Both yields require explicit claiming. This behavior can be seen on-chain by examining the ClisBNBLaunchPoolDistributor contract and its historical claim events, where the beneficiary addresses are consistently YT-clisBNB holders.
The Distributor’s reward computation is ultimately based on the receipt-token framework defined at the mint section above. However, it is critical to note that the Distributor itself does not compute or stream rewards on-chain based on live token balances. Instead, the protocol periodically takes off-chain snapshots to determine which addresses are eligible and how much each should receive, aggregates these results into a Merkle tree, and publishes only the epoch-specific Merkle root on-chain.
In contrast, PT-slisBNBx holders do not receive either slisBNB staking yield or Binance Launchpool rewards. By design, PT represents the principal component of the position and deliberately forgoes all ongoing yield accrual. Instead, PT holders obtain exposure to the underlying asset at a discounted implied price and realize returns by holding the PT until maturity, at which point it redeems 1:1 into the underlying asset. This structure allows PT holders to effectively lock in an implied yield upfront, with realized returns determined by the entry discount rather than by any reward distributions.
Finally, to verify whether slisBNBx is exposed to rewards at the Lista CDP layer, we conducted a detailed review of Lista’s core CDP contract, Interaction. We confirm that during the SY-clisBNB minting process, all deposited slisBNB is locked in the CDP under the SY contract’s address. This can be verified directly on-chain via Interaction.locked(token, usr): the total amount of slisBNB locked in the CDP consistently matches the total supply of SY-clisBNB. In addition, the SY address has never initiated any borrowing activity throughout its lifetime, meaning its CDP position carries no outstanding debt.
Under this structure, the CDP position is effectively a deposit-only passive position. Because no borrowing is performed from this position, it does not generate any CDP-level income and is not exposed to liquidation risk. Its sole purpose is to act as a compliant and identifiable collateral position that allows the underlying slisBNB to enter Lista’s internal accounting system, thereby satisfying the prerequisites for Launchpool snapshotting and reward distribution. This directly corresponds to the repeated sync steps observed earlier in both the mint and redeem flows. Consequently, the CDP in this context is not a yield amplifier, but rather an infrastructure-layer state anchor, used to map Pendle SY assets into Lista’s reward framework.
Fixed-Principal Structure and Pricing Dynamics
PT-slisBNBx-24JUN2026 represents the fixed-principal component of slisBNBx within Pendle’s yield-splitting framework and is redeemable for 1 slisBNB at maturity on June 24, 2026. Its market price is determined by discounting the remaining yield of slisBNBx, which causes the PT to trade below parity and gradually converge toward 1 as expiry approaches. Liquidity is provided through Pendle’s AMM between PT and SY, where SY serves as the standardized yield-bearing wrapper of slisBNBx. Liquidity distribution is governed by the AMM’s parameters, including the scalarRoot, where a higher value narrows the valid implied-yield range and raises the minimum PT price, and the rateAnchor, which continuously re-centers liquidity to reflect prevailing market yield expectations.
Structural safeguards ensure PT never exceeds 96% of pool value, preventing complete depletion of the SY side and capping the maximum yield the AMM can represent; when slisBNBx yields exceed this cap, PT can trade down to the AMM’s lower bound, with further trades occurring on Pendle’s order book. As time to maturity decreases, the discounting effect weakens, the minimum PT price increases, and PT-slisBNBx-24JUN2026 naturally converges to SY-slisBNBx as the remaining yield approaches zero.
Risk Parameter
Supply Cap
With PT-slisBNBx-24JUN2026, liquidity depends on both the underlying slisBNBx markets and Pendle’s PT/SY AMM pool, and current depth is solid. The plot below represents the amount of liquidity available under 3% slippage as the market approaches expiry, given the current liquidity distribution in the AMM. As the market matures and moves closer to expiry, the slippage associated with swapping PT becomes less extreme. This effect is more pronounced for assets with lower scalarRoot values, which correspond to a wider implied yield range and greater variability in liquidity concentration. Supported by on-chain liquidity in the Pendle AMM, the market currently facilitates swaps of up to 22K PT with less than 3% slippage.
The SY liquidity in PT-slisBNBx-24JUN2026’s AMM has reached 50K (approximately $45M in notional value). Between approximately November 17, 2025 (around 0.6 years to maturity) and November 26, 2025 (around 0.575 years to maturity), liquidity showed a clear upward trajectory, increasing rapidly from 10K to 50K. This growth indicates a robust level of LP support and reflects strong market participation.
Given the current liquidity depth, recent growth in SY liquidity, and the observed slippage profile in the Pendle AMM, we recommend a 25K PT-slisBNBx initial supply cap.
Collateral Factor, LT, and LI
Given the expected looping use case, we propose configuring PT-slisBNBx-24JUN2026 to be non-collateralizable and non-borrowable in the Core Market, while allowing it to be used exclusively as collateral within the BNB E-Mode.
For PT-slisBNBx-24JUN2026, a conservative configuration is warranted due to its meaningful remaining duration. At the time of writing, approximately six months remain until maturity. Given this long time-to-maturity, the PT price is still sensitive to changes in forward yield expectations. As a result, shifts in perceived yield can continue to translate into material PT price volatility.
In addition to duration risk, PT-slisBNBx is exposed to the yield uncertainty risk driven by Binance Launchpool rewards. Unlike slisBNB’s native staking yield, Launchpool rewards are inherently episodic and volatile. In our prior BNB/WBNB IRM analysis, we noted that Binance Launchpool activity had been dormant since May 2025; however, roughly one month after that publication, Binance launched the KITE Launchpool. While this does not imply a structural return to frequent Launchpool campaigns, it demonstrates that such events can reappear in a unpredictable manner, introducing additional uncertainty to forward yield assumptions. Taken together, the combination of potential volatile yield dynamics and non-trivial duration risk supports a conservative stance on risk parameters for PT-slisBNBx-24JUN2026.
Finally, our risk parameter recommendations rest on the current structural reality that all slisBNB deposited by Pendle into the Lista CDP system is used strictly for accounting purposes, rather than as active borrowing collateral. However, if this usage were to change and the slisBNB were instead used to collateralize lisUSD borrowing, the asset’s risk profile would fundamentally shift. In such a scenario, liquidation events could result in the seizure of slisBNB collateral, which would in turn prevent PT tokens from reliably redeeming one unit of the underlying at maturity, effectively introducing protocol-level bad debt. Should this usage model change, Chaos Labs strongly recommends that the Venus team coordinate closely with Pendle and Lista to preserve collateral integrity and, if necessary, proactively adjust risk parameters or freeze the market and gradually off board the PT asset to eliminate potential bad-debt exposure.
Pricing
We recommend using Pendle’s 30-minute TWAP of the PT-slisBNBx / slisBNB market and combining it with the existing slisBNB price oracle for pricing. The slisBNB oracle derives the slisBNB-BNB exchange rate by reading the convertSnBnbToBnb function from the ListaStakingManager contract and multiplying the result by the BNB-USD price provided by Venus’s Resilient Oracle. In addition, the slisBNB oracle applies an dynamic exchange rate cap through a correlated oracle design, where the maximum allowed slisBNB-BNB exchange rate is constrained by a configured annualGrowthRateparameter.
Specification
BNB Core
| Parameter |
Value |
| Asset |
PT-slisBNBx-24JUN2026 |
| Collateral |
No |
| Borrowable |
No |
| Supply Cap |
25,000 |
| Borrow Cap |
- |
| Collateral Factor |
- |
| Liquidation Threshold |
- |
| Liquidation Incentive |
- |
| Kink |
- |
| Base |
- |
| Multiplier |
- |
| JumpMultiplier |
- |
BNB E-Mode Parameters
| Parameter |
Value |
Value |
Value |
Value |
| Asset |
asBNB |
slisBNB |
PT-slisBNBx-24JUN2026 |
WBNB |
| Collateral |
Yes |
Yes |
Yes |
No |
| Borrowable |
No |
No |
No |
Yes |
| Collateral Factor |
89% |
90% |
87% |
- |
| Liquidation Threshold |
92% |
93% |
90% |
- |
| Liquidation Incentive |
4% |
4% |
4% |
- |
Disclaimer
Chaos Labs has not been compensated by any third party for publishing this recommendation.
