Other considerations

Block timestamp

openOracle can be run in block.timestamp mode or block.number mode. Base is part of the OP stack which follows the timestamp rules found in the below derivation: https://specs.optimism.io/protocol/derivation.html Some of the important rules from that link are:

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, max_sequencer_drift is 600 seconds meaning the sequencer clock can be up to 600 seconds ahead of the L1 block timestamp. The first rule in the list implies we must have 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, the block times should be relatively well behaved. We have implemented some mitigations for different kinds of sequencer timestamp and block number behavior: Chain halt: Applications can 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. We can have an additional filter in applications of settle block optimality - meaning, if the settle did not come in the optimal block, we ignore the price. 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 our optimal settle block check and the settled price would not be used. Implied blocks per second: On OP stack chains like Base, the 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. This is not a perfect solution but combined with the OP stack rules it should be useful. Timekeeping is definitely an issue that impacts openOracle. There is a high level of complexity to the timekeeping rules on L2 and it is possible our 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, because of state hash validation internal oracle participants are not at risk to the same extent external notionals are, like an application relying on the settled price. As with any technology timekeeping will improve.

Censorship

Someone can report a bad price, censor any disputes, and then settle the bad price, draining any money that depended on this price. On L2s, we are trusting the sequencer, so in this case we are trusting Base. Base is already trusted for short term inclusion for large defi transactions but if the amount at stake is too high, the sequencer cannot be relied upon. So there is a hard limit on the amount the oracle can secure without better inclusion guarantees. In the case the amount at stake increases to where the sequencer is no longer reliable, we can migrate to the L1. Today, there are 12 second blocks. If we use a 3 minute oracle settlement time, this is 15 block proposers. As long as 1 of n of these proposers includes our transaction, oracle price error is mitigated by dispute inclusion. So we can say crudely an attacker would need to control 15 blocks in a row. An attacker with 30% of stake would get 15 blocks in a row every ~27 years. Even if 3 minute settlement times have more arbitrage loss than that of shorter settlement times, all of the math still holds and the oracle works fine provided the fee barrier is configured properly. In the not so distant future, we will have FOCIL on the L1. FOCIL gives us inclusion guarantees as long as 1 of 16 of the rotating inclusion committee includes our transaction. This gives us the ability to use shorter settlement times on L1, reducing arbitrage loss. In the case a block proposer decides to censor us, their block is skipped, and the next block number doesn't change while the timestamp still increments. Using block.number mode in our oracle rather than block.timestamp lets us gracefully handle censorship manipulation on the L1 when FOCIL is live.

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 the vast majority of cases by having a high floor for the initial report liquidity, but initial liquidity should scale proportionately to trade size above that to link the external EV gain to the internal oracle losses in the previous mathematical framework section of the docs. It is not very expensive to pay someone with $10k to put their money in a contract for 3 seconds.