# How openOracle works — settlement by absence > openOracle is a permissionless on-chain price mechanism where a report is two limit orders at the same price. Report, dispute, settle — with exponential commitment escalation and per-instance security. Source: https://www.openoracle.org/protocol Protocol # ABSENCE OF TRADE IS EVIDENCE OF CORRECTNESS. 01 Mechanism 02 Lifecycle 03 Parameters 04 Roadmap 01 // Mechanism ## Not a feed. A game, per use case. There is no shared price. Each consumer creates its own oracle game — liquidity, timers, fees and escalation sized against the value at risk. report two limit orders at one implied price dispute take a side, replace both with larger orders at a new price, reset the timer settle timer expires without further dispute price = currentAmount1 / currentAmount2 The settled price is the ratio of the surviving amounts. Raw amounts — account for decimals. Anyone can report, dispute or settle. No admin keys, no upgradeability, no privileged roles. ### Why lying is expensive A wrong price is a cheap order for everyone else. Correcting it is profitable, and the cost of holding it grows exponentially each round. The tradeoff, stated plainly The system is designed so well-parameterized games end in accurate prices at the cost of bounded influence over settlement timing. ▸ Reference [Introduction](https://docs.openoracle.org/openoracle/introduction#overview) [Advantages](https://docs.openoracle.org/openoracle/advantages) [Terminology](https://docs.openoracle.org/openoracle/terminology#core-stages) ### Oracle Lifecycle ⟨ Resolution Flow. ⟩ Permissionless Price Discovery At its core, the oracle works by having a reporter submit both a limit bid and ask at the same price. 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. PAIR: WETH/USDC MULTIPLIER: 2× LOCKED: 0.1 ETH LOCKED: 300 USDC TIMER: ACTIVE DISPUTES: RESET\_TIMER BID\_FILLED: FALSE ASK\_FILLED: FALSE PRICE\_CONFIRMED: TRUE AVAILABLE: ONCHAIN ![Oracle lifecycle diagram](/oracle-lifecycle-graph.svg?v=spine) Absence\_Timer 00:04:27 WAITING\_FOR\_ABSENCE Liquidity\_Locked 1× → 16× Settlement by Absence No Dispute = Evidence of a Good Price 01 // REQUEST ### Price Request Application submits a price request with the token pair, initial liquidity, settlement time, multiplier, fees, and settler reward. 02 // REPORT ### Initial Report Reporter locks two assets in a ratio that implies the price. For example, 0.1 ETH and 300 USDC implies $3,000/ETH. 03 // DISPUTE ### Dispute Window Anyone can dispute the price by swapping against it—but to take, you must replace larger. Each dispute resets the timer. Order size grows by the multiplier each round. 04 // SETTLEMENT ### Settlement by Absence If settlement time passes with no disputes, the price is considered final and applications can use it. 03 // Parameters ## Security is a configuration Because there is no shared feed, there is no single security level. Each game is configured by whoever creates it, which is what makes the cost of corruption programmable. 01 Initial liquidity The size of the first two-sided report. Higher amounts increase cost, smaller amounts make delay cheaper. 02 Settlement time Per-round timer: how long a report must survive untouched. Longer windows increase initial reporter losses and finalization time, shorter windows leave less time for reaction and inclusion. 03 Multiplier How much larger each dispute’s orders must be. Higher values increase delay cost while lower values increase price accuracy. 04 Escalation halt The size at which geometric growth stops. Disputes can continue but no longer must grow by the multiplier. 05 Swap fee Paid to the previous reporter on each dispute. Lowers the initial reporter’s loss to volatility at the cost of price accuracy. 06 Protocol fee Proportional fee paid to a configured recipient on each dispute, so delay funds whoever depends on the price. Reduces accuracy. 07 Time mode Whether the clock runs on block numbers or timestamps. ### What this buys you - ▸ Applications size oracle security per instance against the value at risk - ▸ Guaranteed starting liquidity — no time-varying AMM depth in your oracle - ▸ A price that reflects chain-specific premiums and discounts automatically - ▸ No shared dependency, so no systemic contagion from one bad feed [SIZE A GAME ⟶](https://www.openoracle.org/build/integrate#parameters)[PRICE AN ATTACK ⟶](https://www.openoracle.org/security) ▸ Reference [Oracle Life Cycle](https://docs.openoracle.org/openoracle/oracle-life-cycle#game-parameters) [Smart Contract Reference](https://docs.openoracle.org/openoracle/game-guide#playing-the-game) Development Trajectory Protocol Evolution Timeline Toward decentralized price infrastructure. ![Protocol Evolution sticker](/assets/fun-4-B_DVjZAe.svg) Phase 01 Q4 2025 ✓ COMPLETE ### Core Protocol Design - ⟨1⟩ Oracle lifecycle architecture finalized - ⟨2⟩ Exponential escalation mechanics - ⟨3⟩ Smart contract development initiated - ⟨4⟩ Initial deployment on Base testnet Phase 02 Q1 2026 ✓ COMPLETE ### Research Stage Launch - ⟨1⟩ Mainnet contracts deployed on Base - ⟨2⟩ Economic incentive testing in production - ⟨3⟩ Community trading bot development - ⟨4⟩ Game theory validation and refinement Phase 03 Q2 2026 ⟳ ACTIVE ### Security & Audits - ⟨1⟩ Comprehensive smart contract audit - ⟨2⟩ Game theory and statistics review - ⟨3⟩ Bug bounty program launch - ⟨4⟩ Parameter optimization based on mainnet data Phase 04 Q3 2026 ○ PLANNED ### DeFi Integration - ⟨1⟩ SDK and developer documentation - ⟨2⟩ Integration with lending protocols - ⟨3⟩ Multi-chain expansion planning - ⟨4⟩ Dispute network tooling and monitoring