Resilient Price Oracle

Overview

In its previous version, Venus was fully reliant on the Chainlink price oracle for fetching prices. This dependence, while generally reliable, created a single point of failure. An erroneous or stale price could, without a secondary mechanism for validation, pose threats such as unwarranted liquidations or inflated borrowing.

In light of these risks, Venus V4 introduces the Resilient Price Oracle, a more robust system capable of pulling data from multiple sources for cross-validation. The Resilient Oracle is equipped with an algorithm to verify prices between two or more sources, providing a safeguard in cases where the primary source proves unreliable or fails.

Furthermore, the improved oracle infrastructure supports the integration of new price oracles in real-time and permits the enabling and disabling of price oracles per token.

Key Features

Resilient Price Feeds

The Resilient Price Feeds replace the single source price provider used in the Comptroller contract with a more robust and reliable solution. This new component not only fetches asset prices from various on-chain sources but also includes a fallback mechanism to protect the protocol from oracle failures. Presently, this feature incorporates Chainlink, RedStone, Pyth Network and Binance oracles, with the possibility of adding more in the future.

Governance Configurations

The Resilient Price Feeds system can be configured by the Venus governance via Venus Improvement Proposals (VIPs). These configurations include pause and resume functionalities for the oracle, price feed configurations, and fixed price settings, among others.

Safety Measures

In implementing the Resilient Price Oracle, several safety measures have been adopted to ensure the security and continuity of the Venus Protocol:

Price Continuity: Asset prices pre and post upgrade were validated in a simulated environment to ensure consistency.
Testnet Deployment: The oracles have been deployed and tested in the Venus Protocol testnet environment.
Auditing: The code has been audited by OpenZeppelin, Peckshield, Certik, and Hacken.

Protection Mode

For low-liquidity collateral assets, the Resilient Oracle's spot price is wrapped by the DeviationBoundedOracle on the borrow-power path. When the spot deviates beyond a per-asset threshold from the recent rolling window, Protection Mode activates and the Comptroller switches to bounded prices — min(spot, windowMin) for collateral and max(spot, windowMax) for debt — until conditions normalize. Liquidations continue to use the Resilient Oracle's spot price directly.

Correlated Token Oracles

For correlated tokens, like Liquid Staked Tokens (LST), best practice suggests oracles quote first smart contracts to get the exchange rate between the correlated assets, and then multiply that by the USD market price of the second token to complete the calculation.

In Venus we use dedicated oracles for each LST asset in order to calculate the price as follows:

convert the LST to the underlying tokens (using the exchange rate provided by the LST contracts)
convert the underlying token calculated in the previous step to USD, using a “traditional” oracle based on market price

The current list of correlated token oracles in Venus is:

AnkrBNBOracle. It returns the USD price of the ankrBNB token, converting on-chain from ankrBNB to BNB using the exchange rate from the ankrBNB contract.
BNBxOracle. It returns the USD price of the BNBx token, converting on-chain from BNBx to BNB using the exchange rate from the stake manager contract.
eBTCAccountantOracle (instance of EtherfiAccountantOracle). It returns the USD price of the eBTC token, converting on-chain from eBTC to WBTC using the exchange rate from the Accountant contract.
PendleOracle. It returns the USD price of the PT Pendle token, converting on-chain from the PT token to the underlying token using a Pendle market contract.
SFraxOracle. It returns the USD price of the sFRAX token, converting on-chain from sFRAX to FRAX using the exchange rate from the sFRAX contract.
SlisBNBOracle. It returns the USD price of the slisBNB token, converting on-chain from slisBNB to BNB using the exchange rate from the stake manager contract.
AsBNBOracle. It returns the USD price of the asBNB token, converting on-chain from asBNB to slisBNB using the exchange rate from the asBNB minter contract.
StkBNBOracle. It returns the USD price of the stkBNB token, converting on-chain from stkBNB to BNB using the exchange rate from the stake pool contract.
WBETHOracle. It returns the USD price of the WBETH token, converting on-chain from WBETH to BNB using the exchange rate from the WBETH contract.
WeETHOracle. It returns the USD price of the weETH token, converting on-chain from weETH to eETH using the exchange rate from the liquidity pool contract, and assumming 1 eETH = 1 ETH.
WeETHsOracle (instance of WeETHAccountantOracle). It returns the USD price of the weETHs token, converting on-chain from weETHs to WETH using the exchange rate from the Accountant contract.
WstETHOracle. It returns the USD price of the wstETH token, converting on-chain from wstETH to stETH using the exchange rate from the stETH contract, and assumming 1 stETH = 1 ETH.

Assumption on Liquid Staked Tokens

WeETHOracle and WstETHOracle assume a 1:1 price ratio between the LST and the underlying asset (e.g. 1 ETH = 1 stETH). The primary risks associated with this approach involve smart contract vulnerabilities and counterparty risks that could impact the redemption processes of the LSTs. In cases of substantial counterparty risk, particularly if the underlying tokens are not redeemable against the LSTs, the direct smart contract pricing might become unreliable. Here's our plan to mitigate such situations:

We will deploy two on-chain oracles for each LST token:
- The first oracle will return the price based on the assumption of a 1:1 ratio between the LST token and the underlying asset.
- The second oracle will return the price based on a secondary market feed (using Chainlink, for instance).
By default, the ResilientOracle will be configured to use only the oracle assuming a 1:1 ratio between the LST asset and the underlying, serving as the primary oracle.
The second oracle, which derives price from the market price feed without assuming a 1:1 ratio, will not be initially configured in our ResilientOracle.
We have implemented an off-chain monitoring system to track the prices returned by both oracles. In the event of a significant deviation over an extended period, the situation will be reviewed. It will be determined whether to switch the primary oracle from the one assuming a 1:1 ratio to the one that does not, or whether to temporarily include the latter as a pivot oracle in the ResilientOracle configuration.

Current configuration

BNB chain

Pool

Market

MAIN oracle

PIVOT oracle

FALLBACK oracle

Notes

Core

AAVE

Overview

Key Features

Resilient Price Feeds

Governance Configurations

Safety Measures

Protection Mode

Correlated Token Oracles

Current configuration

BNB chain

Ethereum

opBNB mainnet

Arbitrum One

ZKsync Mainnet

Optimism Mainnet

Base Mainnet

Unichain Mainnet

Further Reading

Audit reports

References