> ## Documentation Index > Fetch the complete documentation index at: https://docs.openoracle.org/llms.txt > Use this file to discover all available pages before exploring further. # Oracle risks Aside from bugs in the smart contracts, there are several oracle risks. Some we can mitigate, and others we will only find out about, since this is an experimental protocol that has not been attempted before. The risks include but are not limited to what is described below. ## Gas and volatility spikes When gas or volatility spikes, disputing a bad price costs more or carries more risk, so oracle prices get less accurate. openPunt only lets an oracle game start if it holds enough liquidity that disputing it is still worth it, given the gas costs recorded onchain when the game starts: Base's base fee and its L1 data fee. When gas is high, whoever starts the game has to post more liquidity. The UI turns this check on. If gas spikes high enough, the required report size can end up higher than the maximum oracle initial report size of the trade, meaning positions cannot be closed or liquidated until gas calms down, or until 60 hours after maturity, when the check no longer applies. The base fee can also stay low while demand for block space is too high for a dispute to get in, for example during a popular NFT mint, when transactions compete on priority fees. The check passes, but a bad price can still settle without being disputed. From this angle, larger positions are safer than smaller ones. The oracle game's liquidity scales with your notional, but the gas cost of a dispute does not, so on a larger position gas is a smaller share of the report and a bad price is more worth correcting. ## Sequencer outages What if someone knows when the Base sequencer is going to go down, or is able to react quickly when it comes back up? * They could report just before the sequencer goes down, so nobody can dispute in time. * They could report when the sequencer comes back up and the chain is congested, while stale state such as AMM prices is being arbitraged. openPunt has two protections against this. When one of them cancels an oracle game, a close or liquidation leaves the position open, and an opening refunds both sides. * **Max execution latency.** A settled game must be executed within 3 minutes of becoming eligible to settle, or it is cancelled, so a price from before an outage cannot be used after it. * **Liquidation heartbeat.** A liquidation needs a public on-chain notice tied to its oracle game, posted at least 15 seconds before the game becomes eligible to settle. The notice cannot be a force-included transaction, so it has to go through a live sequencer. Additionally, openPunt manages block cadence inconsistencies by relating the number of blocks in a window to its change in timestamp: * **Block pace.** An oracle game's result is thrown out if the number of blocks since its last report does not match the time that passed to a close enough tolerance. On Base, outages are typically backfilled with empty blocks at the correct cadence, so this check may only help in tail scenarios, or not at all. ## Empty blocks What if someone knows when a few blocks in a row are going to be empty, or can cause such behavior? They could report an undisputable bad price. Empty blocks are rare, but this is still a risk. If you are concerned about it, use a longer **Oracle timer** under Advanced Settings. ## Selective delay When the price is near a liquidation threshold and a game would settle against someone, they can keep disputing at the true price to delay settlement, hoping the market moves their way in the extra time. Delaying the oracle game can incur geometric costs. See [delay attacks](https://docs.openoracle.org/openoracle/attack-vectors.md#delay-attacks) in the openOracle docs. Furthermore, outside of liquidation, selective delay may be viable for generating edges on opening and closing prices. See [true-price delay](https://docs.openoracle.org/openoracle/attack-vectors.md#stronger-form-true-price-delay-%2F-timer-refresh). ## Liveness In principle, an adversary with unlimited capital can delay an oracle game for as long as they like. A dispute at a fair price restarts the oracle timer, and nothing stops someone from disputing again and again. openPunt tries to make this expensive relative to the size of your position through parameterization. Initial liquidity as a function of your notional, optional per-dispute proportional fees routed back to you, and escalation all increase the cost of such an activity. We cannot defend against an adversary willing to pay that cost, and openPunt makes no guarantee about how long an oracle game takes to settle. While a game is being delayed: * An opening is cancelled and both sides are refunded after 30 minutes. * A close or liquidation waits. Your position stays open, its PnL keeps moving, and funding keeps accruing. [Selective delay](#selective-delay) above is a targeted version of this. ## No capital to dispute a bad price A dispute helper contract is in production that anyone can use to source dispute capital atomically through Uniswap and Aerodrome pools. This helps, but if positions get too large or the underlying pools get too thin, it may not be economic for the existing dispute network to correct a bad price. Disputing is permissionless, so the capital in the oracle contract is not the whole dispute network. Thin pools also do not make arbitrage disappear: a disputer does not strictly need liquidity quoted atomically onchain, in a traditional AMM or a prop AMM, since they can source capital or hedge elsewhere, or may have existing inventory. Still, there is no guarantee that enough capital is watching. ## Tokenized stock corporate actions When Coinbase's token multiplier changes as a result of some corporate action, the underlying value of the token changes. This can create potentially substantial PnL inside the openPunt leveraged position. The UI blocks requests with maturities near announced events, but not ones announced after a position opens, or surprise actions. Additionally, positions left open too long past maturity are at risk. See [The Coinbase multiplier](https://docs.openoracle.org/punt/trading-pairs.md#the-coinbase-multiplier). ## Unknown unknowns This is a very new protocol, and there will be risks nobody has thought of yet. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.