Overview
This note summarizes the design of Venus resilient oracles and addresses the proposal to reconfigure BNB (Core) and BTC (Core) markets on Binance Smart Chain, making Binance Oracle the fallback oracle, in lieu of Chainlink, which will remain as the pivot for both.
Resilient Price Oracle
The resilient price oracle feature of the Venus platform allows optional cross-checks of a main oracle feed against a fallback oracle, using a pivot oracle to validate the output of each, returning a price from the source “in agreement” (within some allowed deviation) with the pivot oracle, or keeping the main feed output should there be disagreement with the pivot for both, assuming the main and fallback agree. The price update reverts if there is pairwise disagreement among all three, effectively stalling the protocol.
Allowing the protocol to stall is “failing secure.” The protocol prevents any further interaction with the market until at least two of the oracles come back into agreement, or a fast-track VIP is issued to resolve the disagreement by setting a fixed price or reconfiguring the sources or bounds. This is a defense against feed manipulation and short-term volatility followed by a return to a baseline price.
Manipulation/Stall Risk Trade-Off
A weakness of this design is that, with three distinct oracles configured for the roles, it may stall the protocol precisely when it requires rapid liquidations, such as in a steep price decline. Oracles operate at different cadences, as the proposal shows, suggesting that, in principle, it is possible for all three price feeds to indicate a sustained price drop, but, due to differences in cadence, become so far apart that the price update reverts. Below is a simple example, with relative bounds of [0.95, 1.05]:
- t=1, MAIN reports 10, PIVOT reports 10, FALLBACK reports 10, price updates to 10
- t=2, MAIN reports 10, PIVOT reports 10, FALLBACK reports 9, price updates to 10
- t=3, MAIN reports 10, PIVOT reports 9, FALLBACK reports 8.7, price updates to 8.7
- 9/10 = 0.9, MAIN invalid
- 9/8.7 = 1.0345, FALLBACK within the bounds
- t=4, MAIN reports 9, PIVOT reports 8.5, FALLBACK reports 7.7, protocol stalls
- 8.5/9 = 0.944, MAIN invalid
- 8.5/7.7 = 1.104, FALLBACK invalid
- 7.7/9 = 0.856, MAIN invalid relative to FALLBACK
Note that setting the same oracle to be both pivot and fallback precludes stalls. Excessive deviation between main and pivot/fallback oracles causes the price update to be drawn from the latter. Currently, this is the configuration used for BNB and BTCB in the Core pool, with Chainlink set to be the pivot/fallback oracle.
We can use on-chain data collected from oracle contract events for RedStone, Chainlink, Binance and Pyth to assess whether a stall would have occurred in the course of the actual operation of the platform.
As an applied example, we construct a dataset of BNB/USD price update events for all four feeds since January 1, 2024, with platform price update results calculated for every permutation of oracles and corresponding role assignments (one of four oracles is excluded in each assignment). Below, we can observe a mini-crash on December 9.
Under the default bounds of [0.99, 1.01] on relative variation of prices, the platform never stalls, no matter the assignment of oracles to roles. However, tightening the bounds by an order of magnitude to [0.999, 1.001] would have resulted in recurring stalls (highlighted in red) for all oracle-role configurations through most of the timeframe of this mini-crash.
Additionally, even the default bounds would have resulted in a short-term stall for the proposed RedStone-Chainlink-Binance configuration during the August 5 crash, as seen below, lasting for approximately 1 BSC block.
Candidate Oracles
Under the current configuration, both the BNB and BTC markets use RedStone as main, with Chainlink acting as both pivot and fallback. The proposal is to change the fallback to Binance Oracle. RedStone and Binance Oracle share nominal top-line parameters, with 0.1% allowed deviation and a heartbeat of one minute. Chainlink also shares the 0.1% allowed deviation with these, with a heartbeart of 27 seconds for BNB and 60 seconds for BTC. Due to differences in aggregation methodology and disjoint underlying price sources, the update cadence will be different for each provider, as demonstrated in the proposal.
Chainlink & RedStone
RedStone and Chainlink share architectural similarities, with the output of off-chain and on-chain data sources being aggregated by an external network of oracle node operators, subject, in the case of Chainlink, to some consensus mechanism, then pushed on chain or made available to be “pulled” by a transaction, depending on the particular product used. In the case of push price feeds, there is an “aggregator” contract that stores the updates and makes them available to a price feed contract that is actually used by dApps. These updates can be traced off-chain using the log messages emitted by the aggregators.
Binance Oracle
Documentation for Binance Oracle is limited, but the linked contracts give the impression of an architecture that is similar to that of Chainlink and RedStone, although no events appear to be emitted from aggregator contracts. In practice, it appears that the updates are pushed to an OnChainOracle contract in batches, with updates only observable as transactions, complicating empirical work. Additionally, while RedStone and, in particular, Chainlink, have publicly known and diverse sources of data (in the case of Chainlink, supported by a staked consensus mechanism), Binance’s underlying data sources are unclear.
Target Markets on BNB Chain
The proposed target markets currently account for ~66% of the $2.4B TVL of Venus on BSC, which is, itself, the largest deployment of Venus. The markets are similar in size, with BTCB total supply standing at ~$817M and BNB at ~$699M. The Core pool has been primarily composed of BNB and BTCB for at least a year. The size of these markets requires that any adjustment to existing configurations be done with caution.
BNB
BNB is the native token of Binance Smart Chain, and while it nominally forms a large market, at present a significant portion of the value supplied belongs to the effectively inactive account associated with the BNB Bridge Hack. Consequently, the market is functionally considerably smaller, by about 25%, than suggested by the nominal TVL.
BTC
BTCB is wrapped Bitcoin on BNB Chain, and, setting aside concerns about BNB’s centralization, can be treated like BTC representations on other chains. It is a critically important market due to its size, however, so caution is advised, once more, for any configuration changes.
Recommendations
Oracle Selection
Our recommendation is that the full activation of the resilient oracle feature should be limited, at most, to the BNB market, which is the smaller of the two markets considered in the proposal. We view the BTCB market as too large to be a good candidate for this configuration change.
Full activation implies the possibility of a stall in a sudden price correction, potentially preventing timely liquidations, which may result in excessive bad debt accumulation. The historical data on the oracle price trajectories for BNB suggests that the impact of such stalls would have been limited, but a deeper drop with larger inter-oracle variability could produce a longer duration stall in the future in markets with three distinct oracles.
Full activation of the feature only for the BNB market would provide valuable data on market behavior with the possibility of a platform stall, while limiting risk to aggregate platform health.
Future Work
The possibility of a price update reverting, and consequent platform stall, introduces a trade-off between loss from “excess” liquidations (liquidations of positions that would shortly have become healthy again) and loss from bad debt accumulation during major market corrections. Tightening relative price bounds limits the former, while increasing the latter. Optimal bounds can be obtained using a suitable objective function capturing this tradeoff and a simple grid search.
While this note only examines a single market, BNB, for counterfactual market stalls, it is likely that stalls are a more important potential factor in other markets, where higher volatility may require wider relative price bounds to suppress them. In principle, the optimal bounds, and even optimal oracle assignments, can be determined for every market covered by oracles with available data.
Short of attempting to determine optimal bounds and assignments explicitly, any potential alternative proposal for fully activating the resilient oracle feature in a new market should backtest the oracle role assignment and the bounds to assess the likelihood of a market stall. Additionally, any evaluation of a potential proposal would benefit from price trajectory simulations to assess likelihood of stalls going forward under “average” conditions.
Disclaimer
Chaos Labs has not been compensated by any third party for publishing this recommendation.
Copyright
Copyright and related rights waived via CC0
