Summary

On December 10th, 2023, the Venus Liquid Staked BNB isolated pool experienced a shortfall event of the sum of ~$274,000, The event was caused as a result of a malfunction in the SnBNB Oracle, which saw its price surge to $77 billion, allowing an exploiter to leverage a minor position of WBNB to empty the available assets in the pool, with a total borrowed asset value of $273,808.

The exposure for the Venus protocol was limited to the funds on the LST Isolated pool, and no user funds on other pools were affected in the event.

Incident Details

Incident Timeline

1. On Dec-10-2023 at 11:58:40 AM +UTC, a fresh EOA funded through Bybit swapped .1902 WBNB for .1886 snBNB. Within this transaction, the entire concentration of snBNB liquidity had been received by the EOA, however, there still contained an incredibly small amount of 0 - inf liquidity, effectively <.0001 snBNB. As such, when this swap occurred, the constant product formula considered this, leading to the underlying asset pumping infinitely.

This comes at a time when the snBNB/WBNB .05% pool on Pancakeswap v3 contained more than $1m liquidity.

1. 12:13:52 PM +UTC - exploiter EOA funded through Binance Hot Wallet
2. 12:21:58 +UTC - Exploiter swaps .5 BNB to .4951 snBNB on the relatively liquid Pancakeswap v3 .05% pool: Note that this exploiter is seemingly entirely abstracted from the initial Univ3 tx; we cannot confirm any internal collusion, however, these EOAs were created within 20 mins of each other.
3. 12:21:58 +UTC - Exploiter supplies .4951 snBNB on Venus - utilizing the UniV3 pool snBNB price
4. 12:26:46 +UTC - Borrows 654.22 BNBx
5. 12:29:01 +UTC - Borrows 275 WBNB
6. 12:29:46 +UTC - Borrows 108.76 ankrBNB
7. 12:30:25 +UTC - Borrows 46.84 stkBNB
8. 12:40:34 PM +UTC - Redeems his .494 snBNB - this is simply due to the oracle price being so incredibly inflated that the exploiter was able to redeem 99.8% of his initial collateral post-borrowing the entire isolated market with just .49 snBNB
9. Swaps all relevant borrowed BNBrelated tokens for approximately 116 ETH, bridging all to Ethereum Mainnet through Celer & some undefined bridge address.

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 identifying the exploit, Chaos Labs has been monitoring the protocol. The protocol has been working as intended, and other pools are unaffected. In addition, we have not observed abnormal behavior.

We have been working closely with the Venus and Binance team to understand potential implications for other assets, considering their Oracle composition.

Immediate Actions Taken

In response to the recent incident, we advised a temporary suspension of all operations involving assets linked to the Binance Oracle. This measure will remain in place until a thorough investigation into the malfunction is concluded.

Analysis and Recommendations

The incident involving the Binance oracle in the snBNB market was primarily due to its reliance on a snBNB/WBNB UniswapV3 pool with a mere $270 in liquidity as the sole data source for its price feed. This setup led to an event where a trivial amount of BNB was exchanged for the entire snBNB liquidity, resulting in an exaggerated price for snBNB. This price distortion was then exploited to borrow against the Liquid Staked BNB isolated pool, culminating in roughly $250k in bad debt.

Critique of Oracle Practices

Our analysis revealed several critical shortcomings in the Binance Oracle’s operations:

• Single Source Dependency: Relying on a solitary on-chain liquidity source for price determination poses significant risks, particularly for assets with limited market presence, necessitating more sophisticated price determination methodologies.
• Misdirected Data Source: Configuring the Oracle to track an incorrect pool, while a human error, underscores a deficiency in audit and validation processes. The oversight persisted until exploited, indicating a lapse in ongoing monitoring.
• LST Pricing Approach: In DeFi, the convention, as seen in platforms like Aave, is to align the pricing of Liquid Staked Tokens (LSTs) closely with their underlying assets. This practice reflects a consensus that smart contract risks are paramount, with an underlying assumption of eventual redemption, albeit with potential delays. The incident highlights the need for distinct pricing strategies for long-tail assets, especially in isolated pools.
• Critical Gap in Incident Detection: The prolonged period during which the incorrect price was reported suggests that real-time monitoring and alert systems were either non-existent or ineffectively configured within the Binance Oracle infrastructure.
• Need for Immediate Implementation: Binance Oracle must integrate a robust real-time monitoring system that instantaneously detects anomalies in price feeds.

Call for Enhanced Oracle Oversight

• Need for Transparency and Collaboration: There is an immediate requirement for more insight into the design and operation of the Binance Oracle, of which we have urged a transparent collaboration with Binance Oracle to safeguard Venus user funds. Binance has since laid out comprehensive documentation pertaining to the current oracles used by Venus, allowing us to thoroughly evaluate the mechanism design, data sources, pricing methodologies, and more. Absent this level of understanding, we cannot confidently vouch for the security of the protocol’s users.

Relevant Immediate Insights

It is important to highlight a key observation guiding the listing of long-tail assets. The more fragile an asset, the higher the risk of market manipulation. Defining "fragility" isn't absolute; it's mainly about the likelihood of extremely thin liquidity. It's not a binary scenario either—one asset might have a 1% chance of manipulation, another 10%. However, once manipulation occurs, the entire pool faces depletion.

Forecasting pool liquidity is challenging, and historical averages offer only a rough indication. V3 pools pose additional complexity due to significant liquidity concentration compared to TVL.

Liquidity on Relevant Pools

Considering the existing liquidity in the snBNB, agEUR, and stkBNB pools, all currently paused on the Venus isolated markets, there's a potential to infinitely push the price up. The key factor influencing the true extent of manipulation lies in the TWAP window size of the Oracle. Yet, success depends on the feasibility of arbitraging this movement with another market, a condition frequently absent, especially for long-tail assets. This level of liquidity is not very low for long-tail assets and the risk can be evaluated by the cost of manipulation.

Long-tail Asset Listing Criteria

The primary criterion for assessing long-tail assets is the existing liquidity. While having various liquidity sources does enhance the oracle's resilience, it's crucial to note that for many long-tail assets, there's typically only one substantial market. Quoting from multiple sources might not effectively mitigate risks and, in some instances, could even increase vulnerability to manipulation. This is because a less liquid market can be manipulated at a relatively low cost, potentially skewing the relative average disproportionately. Ultimately, this component is inherently nuanced and thus requires delving into the specifics to better understand the dynamics.

Avoiding Recurring Instances

Regarding the long-tail asset oracles, Binance Oracle is set to ensure they quote from the primary liquidity sources, covering at least 80% of an asset's total liquidity, even if it's just one source. However, it's important to note that this alone doesn't ensure resilience, especially if the overall liquidity for the asset is insufficient, requiring the exploration of implications and potential strategies to enhance resilience in such cases.

Next Steps

Priority: In-Depth Data Analysis

• Critical Data Gathering: Since the exploit, we have been collecting comprehensive data & analyzing the internal workings of the Binance Oracle algorithm and specifics about the Time-Weighted Average Price (TWAP) window size, focusing on open and closed-source information. This will enable us to offer tailored and positive recommendations aligned with relevant requirements.

Assessing Current Implementation

• Feasibility Study: Evaluate the potential for modifying existing systems, such as introducing fallback mechanisms with specific thresholds to enhance security.

Enhancements for Oracle Feed Integrity

• TWAP Integration Necessity: If TWAP is absent, its integration is essential to counter price manipulation risks associated with momentary liquidity changes.
• Fallback Safeguards: Implementing fallback options with defined limits can bolster feed stability and reliability. Specifically related to LSTs, this could be in the form of temporarily utilizing the underlying ratio of the asset as a proxy for market value.

Conditions for Asset Relisting

• Enhancement Before Relisting: Recommendations on asset relisting will be provided only after confirming the successful implementation of these critical enhancements.

Conclusion

Enhancing the Binance Oracle feed with robust mechanisms like TWAP and safeguarding fallbacks are imperative for maintaining feed integrity. This step is essential before considering any asset listings to protect against manipulation risks inherent in the current system.