Summary
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.
Analysis
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:
-
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.
-
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.
Recommendations
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 |
