openOracle

Overview

openOracle is designed to be a trust-minimized way to get token prices that anyone can use.

At its most basic level the oracle works by having a reporter submit both a limit bid and ask at the same price. Anyone can swap against these orders minus a small fee. If nobody takes either order in a certain amount of time (the settlement time), it is evidence of a good price that can be used for settlement. If an order is taken, the taker needs to post collateral in both tokens, imply a price, the timer restarts, and the rules are the same. The documentation goes into some of the challenges around this kind of design. The oracle uses exponential collateral escalation during disputes to increase the cost of manipulation and give users some statistical guarantees around total time to settlement and cost to delay. In the average case, the capital required to report accurate prices can be much lower than the notional amount settled by the reported price. The goal is to replace the current set of centralized and trusted oracle intermediaries so DeFi applications can have fewer points of failure. The oracle design is resistant to high levels of block producer collusion, coercion, and bribery. Other on-chain oracle approaches like AMM price oracles are vulnerable to block producer concentration since block producers can inject lies into the price in each block. In openOracle, a lie must be sustained over the entire settlement time by censoring all disputes. In other words, AMM price oracles rely on traded prices, while openOracle relies on the lack of a trade. This gives us price safety at the tradeoff of liveness while still maintaining deterministic, exponentially escalating cost guarantees to delay oracle resolution for a given period of time.

Given that some of the oracle smart contracts sit on Base and Optimism, they are still trusting the sequencer.

DISCLAIMER

The contract and protocol is still in the research stage but it is on-chain so we can test the economic incentives since these are critical to the design.

We have worked on the contract for several months; however, it has not yet been audited. Users should be prepared to lose all funds when interacting with unaudited contracts. Another thing that has not been audited is the game theory and statistics. Users should be aware that even in the case of perfect solidity it is highly likely there are math and game theory errors that not only render this endeavor moot but also put user funds at risk. Even if it works, user misconfiguration of either oracle parameters or trading bots can lead to the loss of funds. If all of the aforementioned is done perfectly, the underlying blockchain can still fail and users can lose funds. Proceed with care.