Two-Step Oracle Method for Accurate LST Pricing

Two-Step Oracle Method for Accurate LST Pricing


The following proposal aims to replace the use of LST/USD oracles based on secondary markets with custom oracles that follow a 2-step process to first convert the LST token to its underlying denomination and then convert this token to USD.


Liquid Stake Tokens (LSTs) bridge the gap between staking and liquidity, offering users the dual benefits of yield generation and asset flexibility.

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:
    • Set 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 for various LSTs. 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.

Recommendation for the LST pools

Currently, Venus Protocol either has or will soon have markets with the following LSTs:

Liquid Staked BNB pool, on BNB chain

  • BNBx
  • ankrBNB
  • stkBNB
  • SnBNB

Core pool, on BNB chain


Liquid Staked ETH, on Ethereum

  • wstETH (To be released)

For LSTs, best practice suggests that oracles quote the smart contract of the LST to derive its value in underlying token units and then multiply that by the price of the underlying. With this, the proposal is to cease using LST/USD oracles and instead start using custom oracles that would:

  1. Convert the LST to the underlying tokens (using the exchange rate provided by the LST contract).
  2. Convert the underlying token calculated in the previous step to USD using a “traditional” oracle based on market price.

For example, for SnBNB, where the underlying token is BNB, the new custom oracle would:

  1. Obtain the SnBNB/BNB exchange rate.
  2. Multiply the previous exchange rate by the BNB/USD price.

Risk Considerations

  • 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 LSTs, 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.

This issue is very important to us, thank you for your suggestion!

It is a good thing if more accurate risk management can be done.

As usual - security is number 1. Have to agree.

Looks good to me.
I like the fact that security is a top priority. :100: