Skip to main content

​
Timekeeping

openOracle can be run in block.timestamp mode or block.number mode. On OP stack chains, timestamps follow the derivation rules: 
block.timestamp = prev_l2_timestamp + l2_block_time

l1_origin.timestamp <= block.timestamp <= max_l2_timestamp

max_l2_timestamp = max(l1_origin.timestamp + max_sequencer_drift, prev_l2_timestamp + l2_block_time)
Each epoch must have at least one L2 block. On Base for example, max_sequencer_drift is 1800 seconds (post-Fjord, previously 600), meaning the sequencer clock can be up to 1800 seconds ahead of the L1 block timestamp. The first rule implies an L2 block every l2_block_time seconds, unless L1 blocks are produced too quickly, which shouldn’t be much of an issue with PoS. Outside drift, block times should be relatively well behaved. Applications can implement mitigations for different kinds of sequencer timestamp and block number behavior:

​
Chain halt

Applications can optionally ignore reportIds whose settlement timestamp was greater than 60 seconds past eligibility. On OP stack, the L2 timestamp in which user transactions are first included after a restart is still bound below by the L1 block time + max drift. An additional filter of settle block optimality can be applied — if the settle did not come in the optimal block, the price is ignored. In a recent Base outage, empty blocks were posted between the outage timestamp and the restart timestamp, so this increment in block number would be handled by the optimal settle block check and the settled price would not be used.

​
Implied blocks per second

On OP stack chains like Base, block times and block numbers are relatively well behaved, but for edge case handling applications can calculate an implied blocks per second from the block number and timestamp difference between oracle instance creation and settlement. If this is too far outside the bounds of 0.5 blocks per second (current Base production block rate), the application ignores the settled price.

​
FOCIL and skipped blocks

Depending on implementation, if a block proposer on L1 censors transactions and their block is skipped, the block number does not increment but the timestamp still does. This creates a divergence between block.number and block.timestamp based settlement. Oracle games using block.number mode would not advance toward settlement during skipped blocks, while block.timestamp mode would. This is another consideration when choosing between the two modes.

​
General considerations

Timekeeping is an issue that impacts openOracle. There is a high level of complexity to the timekeeping rules on L2 and it is possible edge case handling does not cover every edge case. To the extent the edge cases are not predictable, this does not impact oracle performance too much. If they are predictable, internal oracle participants are not at risk to the same extent external notionals are because of state hash validation. As with any technology, timekeeping will improve.

​
Max slippage

Applications consuming an oracle price may enforce a tolerance band around the expected price. The user passes a priceTolerated and a toleranceRange (percentage) at the time of the price request. On settlement, the consuming contract checks whether the settled oracle price falls within the band: 
upper = priceTolerated * (1 + toleranceRange)
lower = priceTolerated / (1 + toleranceRange)
If the settled price is outside this range, the application bails out and refunds the parties. This caps the worst-case slippage a user can experience if the oracle network is penetrated. Max slippage protects against bad oracle prices, but it does not protect from a manipulator trying to report that the price did not move when it actually did. Statistics are on the user’s side here because the price must move enough to make this viable.

​
Gas fees

Gas fees spiking reduces the profitability of participating in the oracle. If gas fees spike a lot, someone can open a large notional position and report a price that is just wrong enough to make it likely not profitable to dispute because of the gas cost. The advantage on the notional may be much larger than the gas fee paid for the manipulative report. But this works both ways: it is now worth it for their counterparty to correct toward a fair price. So the rare instance of extreme gas fees may be a cost to the traders and counterparties but the cost is smaller than the amount extracted from the notional. We can sidestep the gas fee issues in many cases by having a high floor for the initial report liquidity with some caveats. Initial liquidity should scale proportionately to trade size above that floor. One reason is it links external EV gain to internal oracle losses. We also must compensate the initial reporter for the risk they bear which scales with the amounts. So the up front cost to use the oracle is the initial liquidity compensation which is itself some fraction of the external notional.

​
Strategies to mitigate gas spikes

During the October 10, 2025 panic an openOracle dispute cost ~$500 or more on L1. Increasing oracle game liquidity shrinks the price error an attacker can impose for a given gas cost. With $100k of oracle liquidity, a $500 dispute cost represents only ~0.5% of price error. With $1k of oracle liquidity, the same $500 represents 50% of price error. The tradeoff is expense. Without a swap fee or protocol fee, paying for $100k of oracle liquidity for 5 minutes might cost more than $200 in typical ETH volatility (see Oracle Accuracy & Cost). Adding a swap fee (say 2%) dramatically reduces this cost — since the price doesn’t move more than 2% in 5 minutes very often, the cost of $100k oracle liquidity drops to the order of $10 or less. If volatility is super high, users can wait until it’s cheaper. A 2% accuracy penalty from the swap fee can be tolerable for liquidations, since generally the liquidation buffer is much larger than this. In the current openOracle model, the swap fee and protocol fee apply to the entire oracle game. If you want to use a 2% protocol fee redirected to oracle game dependents to penalize delay at the same time as a 2% swap fee, the baseline accuracy penalty is 4% total. A proposed alternative is to have the swap fee apply only to the initial reporter and the protocol fee apply only to disputers, so these can be set independently. The initial reporter gets cheap protection while griefers face harsh penalties redirected to dependents. This keeps the accuracy penalty at a lower level across the oracle life cycle.

​
Continuation Games

Under some parameter choices and participation dynamics, the oracle can stop behaving like a tidy dispute process and start behaving like a continuation game. The value of future rounds can become large enough to dominate everything happening in the current round. In that regime, continuation value can outweigh immediate settlement utility and even outweigh the risk of later losing control through dispute. The result is a mechanism that can begin to resemble a repeated financial comedy rather than a simple price oracle, with participants continuing until they can no longer fund a dispute. This is not automatically bad for serious oracle use. A venue with visible internal EV can attract bots, capital, monitoring infrastructure, and highly responsive disputers. Even mildly ridiculous report instances can help subsidize a stronger global dispute network. Also, this may or may not be a meaningful practical risk. Still, the oracle is permissionless and parameterized, so it is worth acknowledging that these regimes can exist in principle and may appear under some configurations. Escalation halt appears to be the strongest way to manage this kind of risk, and per-round protocol fees after that optionally directed to oracle game dependents, if you do not desire a private casino inside your settlement process. On the other hand, price bias for linear notionals does reduce to 0, if you can tolerate the wait.

​
Peer-to-peer versus standing liquidity

Standing liquidity — lending pools, AMMs, perpetual positions — is vulnerable to gas spike sniping. An NFT mint, token launch, or network congestion event can temporarily price out oracle disputes, creating a window to attack positions that depend on the oracle price. The standing liquidity cannot choose when it is attacked. A peer-to-peer model (propose, match, execute) is more robust against this. The oracle game only runs after both parties have committed, and there is no resting position to snipe during a gas spike. If gas is high, users simply wait. For very large amounts, the oracle is naturally safer from gas spike risk. Gas fees are fixed costs — a $500 dispute cost is 0.5% of $100k oracle liquidity but only 0.05% of $1M. As notional size grows, gas becomes negligible relative to the oracle game, and the price error an attacker can impose shrinks accordingly. Since liquidations necessarily imply standing liquidity, small to medium lending positions are most exposed to gas spike sniping. For these, using a swap fee to reduce the cost of the initial reporter (see above) is important — it allows a larger oracle game size for cheaper, shrinking the gas-exploitable price error window without expensive initial reporter compensation.