Reserve Oracle

Overview


Reserve oracles will provide pricing data with reference to beacon chain balances. This can come from various sources including LST provider provider exchange rate data, custom centralized Ion oracles, or third-party proof of reserve oracles.

Liquidations will be based on the pricing data provided by reserve oracles, allowing Ion liquidations to be fully price agnostic (in terms of the market price).

Design Decisions


  • Aggregation

    • The reserve oracle is an aggregator of price data from multiple sources. While the sources are not going to be the same for each collateral, they will adhere to the interface of IReserveFeed

      • Different reserve oracle instances will have different quorums. A quorum being how many sources will be aggregated.

      • Sources could be third-party reserve oracles or even custom oracles run by Ion themselves

      • Aggregation involves simply taking the arithmetic mean of the sources.

    • The final aggregated value will be minimized against the protocol provided exchange rate.

  • Bounding

  • Because of the critical nature of reserve oracles, it would be too risky to simply depend on these external dependencies without some sort of fail-safe.

  • Some core considerations with the design of the bounding:

    • In traditional lending markets, failure in both directions can be quite devastating as too low of a price yields unnecessary liquidations (and angry borrowers) and too high of a price puts protocol solvency at risk since (potentially) unbacked borrows could take place.

      • With Ion, since the reserve oracle only has an effect on liquidations, the lower bound is much more critical than the upper bound. However, the reserve oracle still provides both upper and lower bounds (since upwards failure is still unideal).

    • Rapid outlier values are very bad

      • One extreme outlier value has the potential to create a lot of irreversible damage (especially considering our market is targeting leveraged positions). With searchers monitoring changes on a block-by-block basis, one bad value is all that is needed.

  • The most likely bound to be used is ~3%.

    • A slashing event can cause at most 1/32 (3.125%) of a validator’s stake to be slashed. Although correlation penalties may follow.

  • After the oracle’s updateExchangeRate is called, there is a cool down period during which the update cannot be updated again.

    • This is necessary in order to delay the oracle value by a specific delay period and to allow the bounding to be applied once.

Last updated