Other considerations

Block timestamp

openOracle relies on the block timestamp. On Arbitrum, where openOracle is first deployed, the timestamp rules are as follows: the timestamp has to be between 24 hours ago and 1 hour in the future (from arbitrum sequencer's perspective) and the current timestamp has to be greater than or equal to the last timestamp. There are four block time regimes to care about: block time slower than normal, block time faster than normal, timestamp halt, and blocks halt. If block time is too fast or there are large jumps forward in time the oracle is vulnerable to attacks, especially if the jumps forward are predictable. In the case of honest but fast blocks (including jumps), the loss can be mitigated somewhat by forcing settlement to be within the a second or two of eligibility; however, you can never prevent a dishonest sequencer from extracting 100% of value. At any point they can censor a dispute and settle a bad price. If block time is too slow, epsilon increases a lot as the probability of getting disputed gets closer to 100%. Arbitrage loss may increase but wouldn't be catastrophic unless blocks were predictably extremely slow. In the case of a halted timestamp but blocks are continuing to be produced, someone could try to submit a bad price and hope it can be finalized as soon as the timestamp is updated but there is still an incentive to dispute it which scales with the error in price. In the case blocks are halted, there is a race to get a transaction in first if someone opened an oracle report just prior to the blocks halting. Because a trader's notional exposure is likely higher than the amount you can dispute, the trader or counterparty is willing to pay the most to be first in the transaction ordering (one of them wants it settled before it's disputed & assuming the one who doesnt is passive). But, since the oracle fails if settlement is not within seconds of eligibility this vulnerability is only possible if the block timestamp both does not align with the actual time when the blocks start again and is exactly within the settlement window.

Overall, the timestamp situation does not seem too dire outside of trusting the sequencer. We are already trusting them for short-term inclusion as are many defi applications. There will likely be good ways to do trustless and accurate timekeeping in the future and sequencing will inevitably improve.

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.

Another way to reduce the gas fee arbitrage is increasing the initial report bond when gas prices are high. The initial bond is specified in the oracle instance creation function, and transaction gas price is also accessible via solidity, so users of the oracle can modify the initial bond based on gas prices. A final way is to have a high floor for the initial report liquidity, but it scales proportionately to trade size above that. It is not very expensive to pay someone with $10k to put their money in a contract for 3 seconds.