LST Isolated Pool Oracle Incident


On December 10th, 2023, the Venus Liquid Staked BNB pool experienced a shortfall of approximately $274,000. This incident occurred due to a malfunction in the SnBNB Oracle, which saw its price inflated to $77 billion. This allowed an exploiter to utilize a small position of ~0.5 SnBNB to deplete the assets available in the pool.

The impact on the Venus protocol was confined to the funds in the LST Isolated pool, ensuring that no user funds in other pools were compromised during this event.

Incident Timeline

Impact Assessment

Following the surge in the SnBNB Oracle price to over $77B, the exploiter was able to utilize ~0.5 of SnBNB collateral to borrow the entire available liquidity from the LST Isolated pool, with the following breakdown:

Asset Amount USD value
BNBx 654.22 $168,370.06
WBNB 275.0 $65,940.48
AnkrBNB 108.76 $27,855.61
stkBNB 46.84 $11,642.08

Risk Assessment

Since the identification of the exploit, Chaos Labs has diligently monitored the protocol, which continues to function as expected. We have confirmed that other pools remain unaffected and have detected no unusual activity.

In collaboration with the Venus and Binance teams, we are thoroughly analyzing the potential impact on other assets, particularly in light of their reliance on the Binance Oracle.


To ensure maximum safety, we have advised temporarily suspending all operations involving assets that depend on similar configurations. This precautionary step should remain in effect until the investigation into the Oracle malfunction is fully concluded and any necessary corrective actions have been implemented.

With this in mind, the following markets have been paused - stkBNB, SnBNB (LST pool) and agEUR (Stablecoin pool)


In response to the abovementioned incident, the community has made the following Governance proposal to remediate affected users as early as possible while we work on recovering funds with our partners:

VIP-214 Repayment of the insolvency in the Liquid Staked BNB pool - stage 1


If passed this VIP will perform the following actions:


Due to the incident explained above, the following insolvencies have been generated in the Liquid Staked BNB market (Venus Protocol) (defined in full tokens):

  • ankrBNB: 108.890115080027695179 ($28,089.03 assuming the price $257.95758234)
  • BNBx: 654.859606916027127141 ($169,444.84 assuming the price $258.74987025)
  • stkBNB: 46.88799297198450373 ($11,733.84 assuming the price $250.2525884)
  • WBNB: 275.071884556669618361 ($66,127.28 assuming the price $240.4)

The USD prices are the valid ones at block 34241940, when the insolvency was recorded ( The total insolvency, considering those USD prices, is $275,394.99. This VIP proposes to send 300,000 USDT to the Community wallet to have some margin and absorb potential changes in the USD prices before the VIP is executed.

This VIP is part of the mitigation plan. Specifically, this step is:

  1. Transfer USDT tokens to the Community wallet (this VIP)
  2. The Community wallet will swap needed assets to cover the generated insolvency. If due to price fluctuations some USDT are not needed, they will be sent to the Venus Treasury. If the USDT transferred is not enough to buy 100% of the needed tokens, the new scenario will be reevaluated.
  3. The Community wallet will send the swapped tokens to the Venus Treasury (
  4. A new VIP will be proposed to remove the insolvency from the affected markets, injecting into the markets the tokens previously received in the Venus Treasury

Vote :point_right:t2: Venus Protocol

1 Like


Following the SnBNB Oracle manipulation post-mortem, we have carried out a thorough analysis aimed at offering guidance on reactivating the markets that were suspended due to issues with the Binance Oracle configurations. Additionally, we aim to propose strategies for enhancing the performance of the isolated markets. Our analysis has led to a set of immediate-term recommendations to facilitate the reactivation of the currently paused LST markets, as well as more comprehensive, optimized suggestions for longer-term implementation.


In the aftermath of the SnBNB oracle manipulation incident, triggered by inaccuracies in the Binance oracle citing an incorrect and illiquid pool, our focus shifted towards optimizing the paused markets—specifically agEUR (now EURA), stkBNB, and the aforementioned snBNB—each sharing a similar configuration. These markets relied on Binance feeds that draw from a singular liquidity source, solely derived from a singular Pancakeswap V3 pool. However, due to the unique ability to concentrate liquidity and selectively determine price ranges for providing liquidity, especially in the case of relatively illiquid pools, exploitative opportunities arise. This vulnerability allows a manipulator to effectively inflate the price incredibly high, subsequently exploiting the oracle update delay within a given block due to the scarcity of liquidity outside specified ranges.

The single source Binance oracles utilize a time-weighted-average-price formula to derive the final price at a given time t. Formally:

Unfortunately, the TWAP functionality does not offer protection against price manipulation. This is because, in a pool with low liquidity, an attacker might purchase the entire amount, as seen in the snBNB attack. If there are no other significant on-chain venues, arbitrageurs can only rebalance the pool using CeFi venues, if available. Given the limited liquidity in these pools and the likelihood that they are not lucrative for arbitrageurs, it can be assumed that the time required to close the arbitrage is substantial. Specifically, if the price can be manipulated to infinity even for a single block, any weighted average price incorporating this manipulated value will also be infinite, irrespective of the number of samples.

The case for pricing the underlying:

LSTs showcase a distinctive trait where the amount of the underlying asset that can be claimed steadily increases due to the accumulation of staking rewards. Slashing events in this context are generally rare and of minimal impact. As a result, if we equate the price of an LST to the value of its claimable underlying tokens, the process of liquidating LST/underlying asset positions is not significantly risky. In scenarios devoid of counter-party risk, this principle can be effectively applied in two key ways:

  1. Direct Price Oracle Configuration:
    • We recommend setting up the price oracle to source quotes directly from the staking protocol’s smart contract. This approach has been successfully implemented on other lending protocols including Venus, with assets like wstETH and sAVAX. It ensures that the price feed is both timely and reflective of the actual value of the underlying assets as they accrue staking rewards.
  2. High Collateral Factor Settings:
    • Given the primary use of LSTs as collateral for borrowing their underlying asset, it is sensible to establish a high CF ratio in the isolated pool. This acknowledges the inherent stability and growth potential of LSTs, facilitating more efficient and secure borrowing practices.

However, the presence of significant counter-party risk complicates this model. If a scenario arises where the underlying tokens cannot be seamlessly redeemed against the LSTs, the accuracy of the smart contract-based price feed could be compromised. In such instances, it becomes essential to rely on price oracles that draw from secondary market prices. This alternative ensures a more accurate and market-responsive valuation of LSTs, safeguarding against potential discrepancies and maintaining the integrity of the liquidation process.


LST Pool

We recommend implementing a price oracle that directly sources price from the staking protocol’s smart contract or LST exchange rate (similar to the solution for wstETH on the Ethereum deployment).

  • Risk Assessment and Community Trust: The primary risks involved with the above approach are related to smart contract vulnerabilities and other counterparty risks that could affect redemption processes. It is imperative for the community to engage in a thorough evaluation of these risks. A key factor in this process is assessing the level of trust and confidence in the reliability of the chosen staking protocol, a decision that needs to be made collectively by the community.
  • Risk Mitigation in Case of Counterparty Risk: In scenarios where there is substantial counterparty risk, notably if the underlying tokens are not redeemable against the LSDs, the direct smart contract pricing might become unreliable. Under such circumstances, it is prudent to switch to price oracles that derive quotes from secondary market prices, thereby maintaining pricing accuracy and reliability.

In addition, given current usage we recommend setting the following conservative caps for the assets on the pool:

Asset Current Supply Cap Recommended Supply Cap Current Borrow Cap Recommended Borrow Cap
WBNB 24,000 15,000 16,000 12,000
slisBNB 3,000 3,000 800 300
BNBx 9,600 3,000 1,920 300
ankrBNB 8,000 2,000 1,600 200
stkBNB 2,900 2,500 580 250