Skip to main content

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. 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 new 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 offer an alternative to 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 concentration, collusion, coercion, and bribery. Other on-chain oracle approaches like AMM price oracles are vulnerable in this context because block producers can inject false prices while avoiding losses to arbitrageurs. In openOracle, a false price must be sustained over the entire settlement time by censoring all disputes. AMM price oracles rely on traded prices, while openOracle relies on the lack of a trade. This trades liveness for safety, while maintaining deterministic, exponentially escalating costs to delay oracle resolution. The contracts have no admin keys, no upgradeability, and no privileged roles. Anyone can create oracle games, report, dispute, or settle. All code is open source under the MIT license. Some of the oracle smart contracts sit on L2 and trust the sequencer.

DISCLAIMER

The contract and protocol are still in the research stage but the system 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 flawless Solidity code 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.