Skip to main content

​
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 take longer, all of the math still holds and the oracle works fine. If there is concern about block producer collusion, longer settlement times than that are acceptable. If using the oracle for some linear applications, max slippage and cancels before settlement can be used to reduce settlement times since extractable value is lower. 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 and the block proposer is not engaging in a block stuffing attack. This may give us the ability to use moderately shorter settlement times on L1, but for super high value transactions it really does not do much unless the settlement time is very long to enable EIP-1559 burns to overwhelm the cartel; however at that point, they fully control the blockchain anyways and can do many more untoward things than attack openOracle. In the case a block proposer decides to censor us and is not engaging in a block stuffing attack, their block is skipped, and the next block number doesn’t change while the timestamp still increments. The oracle does not depend entirely on FOCIL to work, since the only way to pass price error into the oracle is to offer a mispriced swap, and there will be tips for inclusion up to this amount. If we have some initial liquidity L and external linear notional N, set I = L/N, If you calculate 1 / I, you have to bribe that many independent block producers the dispute value to censor. So long enough settlement times are economically unviable for censorship bribery. If you want to impart a grief ratio on the attacker G you can think about (G+1) / I. Parasitic open interest is unstable in high censorship regimes (gets exploited) so it is statistically dead when you as an OI-aware user get a reportId on-chain.

​
Parasitic open interest

Parasitic open interest in openOracle is when an application tries to use an oracle game price without paying for said oracle game. This creates basically two incentives: delay and censorship. The censorship risk does not seem so bad since contrived oracle games exploit the parasitic OI out of existence (possibly via some ePBS-style block space purchase). To the extent parasitic open interest dodges censorship risk, it can actually be a good thing for the parties that paid for the oracle game. For example, in a lending-style liquidation setup, the oracle game can feature protocol fees. For example, 1% of the swap size each round can be charged to disputers then directed to a protocolFeeRecipient address specified at oracle game creation. This address can be a smart contract designed to split the accrued protocol fees between the lender and borrower who paid for the oracle game to start. The delay incentives for liquidation are as follows: P(price X ends past strike Y over settlement time) * payoff of bet > cost to delay oracle where the payoff of bet is the liquidation penalty, Y is the liquidation price, X is the current price, and the cost to delay the oracle is ~ 1% * oracle game size at that round. If the parasitic open interest is very large, the cost to delay is small relatively, but since the initial oracle liquidity was a function of the non-parasitic open interest to begin with (say ~10%), the exponential fees in expectation more than cover for the delay. For example, with a multiplier of 2, the oracle game becomes larger than the paying notional in 4 rounds of delay (10% -> 20% -> 40% -> 80% -> 160%), paying 1% each time split between the original borrower and lender (0.1% -> 0.2% -> 0.4% -> 0.8% -> 1.6% and so on, as % paying notional).

​
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 in the below manipulation section of the docs 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.

​
Block stuffing

Anyone can try a block stuffing attack. If you can increase gas fees enough by spamming high fee transactions, then report a bad price, it isn’t rational to dispute for anyone not economically aligned to the oracle output. This makes it relatively challenging to settle a $1 million dollar notional with something like $100 in the initial report. We will assume there is one gas attacker and their counterparty is completely passive. The attacker can earn the some payoff if they sustain a mispricing for the settlement time. The gas fee per dispute needs to be > R * L, where R is the price error of the report and L is the liquidity in the oracle. So they may need to pay R * L * (G_block / G_dispute) * T, where we have some G_dispute for gas use of a dispute, and G_block for block gas limit, and settlement time of T blocks. Next, on EIP-1559 chains, block stuffing exponentially escalates the base fee +12.5% per block, which is burned. FOCIL helps as well forcing producers to keep blocks full or have their block skipped by consensus. Without FOCIL, block producers can skip an exponential escalation per block they control by submitting empty blocks. The optimal attack is generally to raise the base fee to a bit over the point where it prices out disputers, then alternate blocks in the stuffing attack to keep the base fee stabilized. We will ignore the ramp up period and assume it costs the attacker 0. Block stuffing for the entire period inherits exponential costs and is not really tenable unless the oracle parameters are really bad. So we will say the cost is actually R * L * (G_block / G_dispute) * T / 2. If we assume there is some chance of failure where either the counterparty comes in to blow up the attack, or someone just does it for fun to impart an enormous cost on someone else for a relatively small amount (meaning the attack itself has a really horrible grief ratio to be blown up) by just paying above the gas fee in the non-manipulated alternating block, the profit is decreased. But, we will assume the attack always succeeds. There are a few practical takeaways. First, let’s assume we are on Ethereum L1, where soon there will be a block gas limit of 60 million. Call disputes 250k gas. This is 240 disputes per block you need to price out. For some linear external notional N, you earn R * N and the above cost formula. attack profitability when R * N > R * L * (G_block / G_dispute) * T / 2 ⇒ attack unprofitable when L > 2 * N * G_dispute / (G_block * T) So for a linear notional of $1 million, and we have 15 blocks of settlementTime, you need to pay an initial liquidity of ~ $550. If you want to increase the grief ratio for the attacker, just increase the liquidity, and they blow up linearly. One of the problems with this model is when real gas fees are near the point of pricing out disputes up to some R, the alternating stuffing attack gets cheaper. But this is equivalent to the gas fee problem in general, the liquidity should be high enough so gas fees and even spikes do not impact accuracy more than is tolerable. If we go up to $50k initial liquidity for example, the costs to pay an initial reporter are cheap relative to the $1 million notional, and linear notionals are different from binary like liquidations since the user can choose when they want to trade and customize the parameters per trade. Another issue is the attacker can be a block producer and censor disputes and combine this strategy with alternating stuffing attacks on blocks they don’t control. If the attacker controls some fraction C, we should scale our parameters like initial liquidity / (1-C) or settlementTime / (1-C), or a combination increasing both by some amount. With binary notionals, like liquidations, the required price error is very big. You need to get the oracle to report a price error of the distance from the current price to the liquidation threshold. This should dwarf normal gas fees, and even very high gas fees, for any sensible initial liquidity.

​
Max Slippage

We can imagine using the oracle price to set a swap fulfillment price in some separate swap contract.
  1. User deposits 10 USDC into swap contract, sending a price request to the oracle with some internal swap fee F
  2. Price request gets an initial report, maybe a dispute or two then is settled at some price
  3. During the settlement callback, the price is stored in the swap contract and the swap is activated, meaning anyone can come call fulfill
  4. Fulfill is called, the fulfiller sends an amount of WETH into the contract determined by the stored price and the fulfillment fee L chosen by the swapper, say $9.99 of WETH, and receives 10 USDC back.
Inside of the settlement callback which activates the swap, if the settle was not in the optimal block, or if the implied blocks per second from the block.timestamp and block.number across the oracle life cycle is too out of whack, the swap contract bails out, sending the 10 USDC back to the user. It does not activate the swap. We can have an additional protection of max slippage, passed by the swapper as a price (like $3000) and tolerance (like +/- 1%) upon swap creation. If the settled oracle price falls outside the tolerance band, the swap can bail out and send the swapper back their 10 USDC. If the settled oracle price falls inside the tolerance band, this is effectively a max slippage the user can experience if the oracle network is penetrable. Note that max slippage protects this particular case of bad oracle prices, but it does not protect from someone with a way to get a bad price through the oracle network trying to pretend the price didn’t move when it actually did, but we have statistics on our side because the price must move enough to make this viable. It is still worth further analysis to quantify exactly how much loss this source creates. In terms of the range of swap execution cost a user experiences with this approach, we assume the settled oracle price falls between +/- F (~swap fee), and the fulfiller is paid some fee +L on top of that. So the range is L +/- F. Assuming returns of prices inside F have a mean of 0 (no bias) our mean swap execution is L, given L > F. This case is a bit different from the perp order manipulation detailed in the below manipulation section because a manipulator cannot guarantee they are the fulfiller of the swap (the counterparty). They bid against other fulfillers for the mispriced swap they themselves are trying to create with the manipulation inside the oracle. It is possible there is some angle here and the mean swap execution is biased against the user above L, but we still have a hard bound of L + F as worst case swap execution. If users want reliable swap execution, they should set L > F. As an oracle network, the lower we can get F, the lower we can get L and the better swap execution gets through this particular method. Setting L << F creates bias on the fulfilled price by the fulfiller network. So the mentioned swapping applications are great for very fast blockchains where L>F is still cheap but if you want longer settlement times, there might be too much bias from this source relative to background market volatility. You can avoid this by not allowing cancels and binding both parties to the settled oracle price.

​
Manipulation with a swap fee present

Imagine you are using the oracle to settle a large notional, like a perp open order. You are opening a long and want to manipulate the reported oracle price as low as possible. You can only place the reported price inside the effective fee barrier of the report instance, relative to the true price, or you will instantly be swapped against, which is an optimistic view of dispute network participation but we will stick with it just for this section. This effective fee barrier (called F) will include the internal oracle swap/protocol fees, gas fees, and expected jump loss. Every surviving oracle round (no dispute) is within ±F and every disputed round nets zero, so the manipulator’s cumulative EV is <= F from any game state. We can try to go into what the math looks like to determine how much EV a manipulator can extract even if we know it is bound by F. We will define the ongoing dispute game by three linked states. E_0 is the value from a neutral state, where a manipulator must wait for an opportunity. E_1 is the value from an active state, where a manipulative report is already live. E_2 is the free_move state, which is the initial reporter’s state as well as one branch of the active state. We assume for now the manipulator has 0 expenses and always gets their report on-chain first. Example state paths without conditional survival bias: Trader longs, wants better a opening price, and is using the oracle to settle some external notional. The trader starts the game as an initial reporter (E_2) and chooses a report price R below the true price. This creates a barrier around the true price of (+F-R) / (-F-R). If the true price moves outside of this barrier, the report gets disputed. The true price has three possible paths. One path is it hits neither barrier, in which case the game ends and the manipulator earns some R that is <= F on their external notional. The second path is the price hits the upper barrier +F - R, where there is no move by any active participant other than to have the reported price be the true price. The third path is the price hits the lower barrier -F - R, in which case the manipulator gets a free move. They can place the reported price wherever they would like below the true price, which is equivalent to the initial reporter state. In this third path the game enters back into E_2 and we play again. We say the first, second and third paths happen with some probability P_a, P_b and P_c respectively. Inside the second path of E_2 with an honest reported price, we enter the E_0 game state (neutral). The manipulator’s choice of reported price is constrained by the barriers +F / -F around the true price at 0, since by contract rule you cannot place a price inside the previous report’s fee barrier (we assume for now F = swap fee with every other component of F set to zero). We assume the manipulator waits for the price to hit some Y below 0, at which point they submit a reported price just outside -F relative to the true price when E_0 was entered. So inside E_0, the true price has three possible paths. One path is it hits neither barrier, in which case the game ends and the manipulator earns 0 on their external notional. The second path is the price hits -Y, at which point the manipulator submits a price just outside the lower fee barrier. The third path is the price hits +F, where there is no move by any active participant other than to have the reported price be the true price. Inside the second path of E_0 we enter the E_1 game state (active). The manipulator’s choice of reported price is now constrained by the barrier +Y / (-2F +Y) around the true price at 0. We have three possible paths once inside E_1. One path is the true price hits neither barrier, in which case the game ends and the manipulator earns F-Y on their external notional. The second path is the price hits +Y and we re-enter the E_0 state (neutral). The third path is the price hits -2F + Y and we re-enter the E_2 state (free_move). Below is a more formulaic description of the above example state paths: Paths from E_2: barrier at (+F - R) / (-F - R) P_a: If neither hits -> end game P_b: If +F - R hits -> enter E_0 state P_c: If -F - R hits -> enter E_2 state Paths from E_1: barrier at +Y / (-2F + Y) P(A): If neither hits -> end game P(B): If +Y hits -> enter E_0 state P(C): If -2F + Y hits -> enter E_2 state Paths from E_0: barrier at -Y / + F P(0): If neither hits -> end game P(G): If -Y hits -> enter E_1 state P(H): If +F hits -> enter E_0 state Probability definitions: P(0) = neutral state hitting neither barrier P(G) = neutral state hitting nearer barrier (-Y) P(H) = neutral state hitting farther barrier (+F) P(A) = active state hitting neither barrier P(B) = active state hitting nearer barrier (+Y) P(C) = active state hitting farther barrier (-2F + Y) P_a = free_move state hitting neither barrier P_b = free_move state hitting nearer barrier (F - R_i) P_c = free_move state hitting farther barrier (-F - R_i) Including conditional bias: The surviving price given no dispute is biased depending on its surrounding barriers. One way to think about bias is with the following example: If I told you ETH was $999, and then one week later the only piece of information I gave you was that ETH was below $1000, your best guess for the current price of ETH would be biased much below $999. If I gave you no information one week later, your best guess would be $999. This type of thinking applies to our oracle game. The optimal manipulation strategy does not have symmetrical barriers, meaning the surviving price (no-dispute) is biased away from the true price at time of manipulative report. For example, in the neutral state E_0, if there is no dispute, this means the price did not hit -Y or +F on either side, starting at 0. Since we assume Y is the closer barrier, this biases the price conditional on no dispute closer to the farther barrier. Since the manipulator is opening a long, and wants as low a price as possible, this conditional bias strictly helps them because they got to open a long at a reported price lower than the true price. You can follow the same logic looking at the barriers for E_1 and E_2, and so the no-dispute branches of the active and free_move states have their own specific biases which both hurt the manipulator. We define the three conditional biases as follows: L_0(Y) = Conditional neutral no-dispute price bias (helps manipulator) L_1(Y) = Conditional active no-dispute price bias (hurts manipulator) L_2(R) = Conditional free_move no-dispute price bias (hurts manipulator) Given all of this information, the system is defined by the following three equations: 
E_0 = P(G) * E_1 +P(0) * L_0(Y) + P(H) * E_0
E_1 = P(A) * (F-Y - L_1(Y) ) + P(B) * E_0 + P(C) * E_2
E_2 = P_a * (R - L_2(R)) + P_b * E_0 + P_c * E_2
To find the optimal manipulator strategy, we need to find the choices of R and Y that maximize E_2. It seems numerically, with a continuous distribution (both normal and alpha-stable), low Y attacks are optimal with many dispute rounds. But, because the total extractable value is F and many rounds imply a low extractable value per round, real life frictions like jump loss and price discontinuity make it very difficult to implement the optimal strategy, especially if we link the external notional to the internal oracle game by setting the initial oracle liquidity to some fraction of external notional as well as set the swap fee to +/- 1 st dev (or unit of scale parameter) of returns. Another thing that is not covered here is the impact of jump loss on the allowed placement of the new reported price relative to the swap fee barrier around the last reported price; however, we still know the arbitrage loss is bound above by F which includes jump loss. We go into detail on the manipulation strategy for a 0 swap fee oracle game in a below section “Manipulation without a swap fee.” The assumptions in this section may be too optimistic, specifically with regard to dispute network participation when the immediate profit is > 0 (price past fee barrier) for swap fees on the order of the standard deviation of returns. Also, jump loss may not exactly be relevant, as we get into in the “A stronger form of manipulation” section. This manipulation section was an earlier piece of research, but the three linked state equations may be a useful framing for larger swap fees (>> 1 standard deviation of settlementTime returns); however, for these kinds of oracle games, you don’t care so much about accuracy given the large swap fee. When we were playing the oracle game in a small network early on, we did program our bots to dispute right past the swap fee barrier and incorporate jump loss which in part motivated the analysis. In a more adversarial environment (or even one bot widening their dispute distance), the former strategy seems to be a losing one.

​
Exponential malaise

Based on the underlying market price action and stylized assumptions about dispute network participation, exponential escalation can shift future costs back into the current oracle accuracy. More specifically, if we assume a disputer is looking at some report that isn’t theirs, and they commit to a defensive dispute then self-dispute every round after that strategy with some proportional cost (like a % burn fee or jump loss), and we have a multiplier M and a per-round settlement (no-dispute) probability Q, then we require Q > 1 − 1/M for the expected total future cost of that “always self-dispute” strategy to stay finite. If actual Q makes this inequality false, the expected future cost can become arbitrarily large, so a rational trader may refuse to dispute unless the mispricing is very big, effectively widening the no-dispute band and worsening oracle accuracy. We can derive this inequality as follows. Assume there is some proportional cost C > 0 to fire a dispute. In the first round, you definitely dispute, so your cost is C. The next round, you might need to dispute with some probability P = 1 - Q, so the expected cost is P * C * M. The round after that is C * (P * M)^2, and so on. The total expected cost is an infinite sum represented by 
sum from N = 0 to infinity across C * (M * P)^N
For an infinite geometric series to converge, M * P must be less than 1. 
M * P < 1 ⇒ M * (1 - Q) < 1 ⇒ Q > 1 - 1 / M
It is helpful to think about this “worst case” situation as a toy model, since it informs how a disputer might think if they are pessimistic about other disputers participating. What ends up happening under any oracle parameterization is depending on our choice of M, the no-dispute band widens to ensure the Q inequality creates profitable participation. Another thing to consider is the other pessimistic strategy of “dispute and refuse to self dispute”. This strategy actually results in the same Q > 1 - 1 /M bound as before, and we will try to prove it. In a dispute and refuse to dispute again strategy, you earn the price error of the current report. You also may be disputed against in the next round, and since you refuse to self-dispute, you will lose the price error in that round times the multiplier. But, you will not be disputed with probability Q. We will refer to the oracle price error as a general no-dispute band of R, and the net profit for this strategy being greater than zero implies the following: 
R -(1-Q) * R * M > 0 ⇒ 1 - (1-Q) * M > 0 ⇒ Q > 1 - 1 / M
The dispute and always self dispute toy model tells us something useful about reality, which is the total cost side of the system (regardless of how many participants there are) is: 
sum from N = 0 to infinity across C * (M * P)^N ⇒ Q > 1 - 1 / M strictly
This can be offset by manipulators net losing over a short period to the non-manipulating network.

​
Generalized oracle games

We can construct a simple English oracle game to show how exponentials may impact generalized oracle games when reporters are pessimistic about participation. Assume there is some oracle question. False has been reported with 5 tokens. The multiplier is 2. So, to dispute this report, you first match the 5 False with 5 True and then put up another 10 on True that anybody can trade against. If nobody disputes for long enough (expiration), the oracle resolves. Someone disputing would need to match your 10 and put up another 20 on False. For marginal questions, we assume a low chance of bubbling up to a network fork like how Amoveo or Augur works. If you win by expiration, you win 5 tokens. If you lose by expiration, this implies your order for 10 was matched, so you lose 15 tokens. You need to have a p(win) > 75% to profit in this market, assuming it does not go all the way to a fork. This somewhat similar to the “dispute and refuse to self dispute” strategy in openOracle. Keep in mind this is a worst-case pessimistic bound - you don’t expect anyone else to necessarily participate on your side given the marginality, meaning there aren’t really paths where your 10 get matched and you still win without a fork. In this simplified example, P(win) > (M + 1) / (M + 2), or it isn’t worth it to participate. The point of this tangent is the following: we shouldn’t expect a simple English oracle game with a 1.01x multiplier to have the same accuracy for marginal reports (like price questions) as that of 1000000x.

​
A stronger form of manipulation

Most of the manipulation analysis we have done revolves around a manipulator reporting wrong prices. A different manipulation strategy would be to always report the true price but dispute and refresh the round timer when the would-be-settled price is not in your favor. Assume you are opening a long and want the settled oracle price lower than the true price. Assume there are 0 swap fees or protocol fees in the oracle game. Also, assume your counterparty is passive and lets you manipulate the oracle. Without manipulation, the reported price would have survived a round with some probability given the dispute barriers. Now, the reported price survives around half that time. We need to figure out what the honest dispute barriers are. We can write a disputer’s EV against any choice of adversarial dispute distance as the below: 
EV = dispute_distance - (1-Q(adv_dist))*adv_dist*multiplier
Where:
  • dispute_distance is where an honest disputer disputes and earns the absolute difference in token values of the previous report
  • adv_dist is where anyone else chooses to dispute the honest disputer’s report. The honest disputer loses the absolute distance in token values in their report, which is at an increased size by the multiplier
  • Q(adv_dist) is the probability the price does NOT get to the adv_dist, in either direction
  • multiplier is the oracle game multiplier
(1-Q(adv_dist))*adv_dist is maximized at ~0.83 for a normal, so if dispute_distance is ~ multiplier * 0.83, since Q(adv_dist) > 0, you are net profitable. We can incorporate swap and protocol fees into the disputer’s EV as follows: 
EV = (dispute_distance - swap_fee - protocol_fee) - (1-Q(adv_dist))*(adv_dist - swap_fee)*multiplier
For now though, we will focus on swap_fee = 0 and protocol_fee = 0 cases. If we assume a multiplier of 1.1x and a normal distribution, with dispute barriers at +/- 0.88 st dev, if it were only honest disputers, each round would have ~28% survival probability. Now, half that 28%, the manipulator prolongs the game, so the survival probability of any given round is only ~14%. Expected rounds is 7.3 to completion with per-round mean less than settlementTime, and the mean settled price takes on ~ +0.32 st dev of bias. This is a much better per-round extraction than any other manipulation strategy we have come up with before, even if the total extraction is higher for other strategies (e.g. you commit to many rounds and report wrong prices), especially because the manipulator is not actually doing all 7.3 rounds. In this case, they just need to do one in expectation. Because of the exponential costs in the oracle game, the manipulator wants to opt for the higher per-round extraction. Another option is to choose some Y, and the manipulator disputes if the price is about to settle outside [Y, 0.88]. The case we just analyzed was Y = 0. Here, the manipulator needs to do more rounds than 1 if Y > 0. Manipulation strategy +/- 0.88 is probably moderately too wide, since the theoretical profitability threshold is 0.71 in a normal. If we use the halfway point of ~0.8: Cost analysis CostFact is simply Rounds^1.1 to reflect the multiplier escalating the game. ManipRnds is how many of those Rounds the manipulator creates. Generally, you lose money inside the oracle doing this strategy, unless you always self-dispute, at which point you need to be careful that you are not violating the Q > 1 - 1/M inequality from the Exponential Malaise section because then you are losing divergently. Assuming you don’t self-dispute, each time you dispute it costs you ~ the honest dispute barrier in expectation (~ 0.8 st dev) * the chance you are disputed (~80%). At Y = 0, the manipulator does earn ~ 0.3 st dev from the absolute difference in token prices at time of dispute (mean price conditional on ending inside (-0.8, Y) and never going outside +/- 0.8 over the life of the round), but this is pre-escalation. We will say the manipulator net loses ~0.4 st dev per dispute, assuming they don’t self-dispute. Assume the initial report in the oracle game is set to 10% of external notional, and assume Y = 0. After ~5 rounds on average, the manipulator has an opportunity: a ~50% chance of letting the game settle in their favor and a ~50% chance of prolonging it. 1.1x multiplier escalates to ~ 1.6x the initial liquidity after 5 rounds, so the earning from the manipulator’s dispute is ~0.3 st dev * 0.16, and the loss is ~ 0.8 st dev * 0.8 * 0.16 * 1.1, so the loss for this dispute is ~0.06 in external notional terms , compared to the 0.3 st dev extraction the other 50% of the time. So net, the manipulator’s expected value is ~ +0.12 st dev from committing to a first manipulation. (0.3 * 0.5 - 0.06 * 0.5). The next attempt will still earn +0.3 but cost ~0.1 from the oracle game escalation, so the expected value of this round is only ~0.1 st dev. The round after that, ~+0.07, then +0.02, and so on. It should be noted the manipulator only earns 0.3 total from this game, but each separate manipulation round has a ~50% chance of winning. It seems like with a 1.1x multiplier, unless we go tighter on the honest dispute barriers, the extraction does approach ~0.3 st dev out of the passive party. Even if the manipulator does not make that amount, the cost is effectively transferred as profit to the dispute network.

​
Quick note on theoretical profit zone

Let’s look at our dispute EV formula again: 
EV = dispute_distance - (1-Q(adv_dist))*adv_dist*multiplier
We know (1-Q(adv_dist))*adv_dist is maximized at ~ 0.8 st dev in a normal. We also know that Q(0.8) ~= 20% in a normal distribution, so we have (1-0.2)0.8multiplier ~= 0.64 * multiplier as the point at which EV becomes positive for an honest disputer against a griefing adversary. The 0.64 * multiplier * standard deviation of settlementTime returns figure is surprisingly robust when tested against fat-tailed (leptokurtic), skewed, and jumpy distributions, so much so that it seems like expected move is the wrong thing to focus on when the standard deviation of returns is what really matters. DNT probabilities also seem to be very similar as is conditional mean settled bias if you can kick out (-barrier, 0) otherwise-settled prices. In general, this is not a theorem, we didn’t test every distribution and there is no guarantee real-world price action acts like anything model-able, but it does seem like this is just a consequence of how barrier games work. The honest dispute barriers actually seem to tighten under jumpy regimes (diffusion component of volatility decreases in size) provided the trading bots adapt to the more profitable strategy, and it is almost like the normal distribution is the worst deal for the barrier distance (given that we want it to be tight to reduce manipulation). If this is the case, then we should assume our dispute barriers are in the range of 0.64 * multiplier, since the real world is almost strictly different from normal. It is possible game discretization is a widening force though (discrete blocks on-chain).

​
Back to manipulation

Next, let’s see what a multiplier of 1.3x looks like. We will assume honest dispute barriers of +/- 0.88 st dev, which is somewhat tight but above the theoretical grief-resistant minimum of ~0.832 in a normal distribution. From the original +/- 0.88 barriers, total extraction is ~0.32 and rounds without manipulation is ~3.6. So, starting with 10% initial liquidity, the game would have escalated to ~1.3^3.6 ~= 25% of notional when the manipulator can attempt a dispute. They pay ~ (0.88 * 0.74 * 1.3 * 0.25 - 0.25 * 0.32) ~= 0.13 st dev half the time, and earn 0.32 st dev the other half. It isn’t rational to try again after this (size grows another ~1.3^4.6 times from 25% notional), so the manipulator has ~one 50% chance at extracting 0.32 st dev from the passive counterparty, so they should extract ~ 0.16 st dev on average. Note that the manipulator’s extraction from the passive counterparty is not the same thing as the manipulator’s profits. The passive counterparty doesn’t receive oracle game losses from the manipulator, they just eat the price bias in the oracle game. In terms of Y > 0 strategies, what seems to happen is while the mean extraction increases, the rounds of extraction as a share of rounds that would have settled otherwise decreases. So for example, with Y = 0.2, the survival probability of the oracle is 8.97%, which is ~33% of the ~27% chance the game would have settled otherwise. The cost curve is the same as Y = 0 or worse. So you have ~one attempt at a ~33% chance to extract 0.44 st dev, which is a bit lower expected extraction as Y = 0. At the extremes, like Y = 0.5, oracle survival probability is 1.75% ⇒ 6.5% chance (1.75% / 27%) of extracting 0.61 in the manipulator’s attempt, so it seems like deviating from Y = 0 is worse from an expected profit perspective for the manipulator as long as initial liquidity is not too small. In general, this manipulation style should be modeled more to see what the actual extraction is under an attacker who just prolongs when it’s EV+ and doesn’t otherwise.

​
Viability of committed manipulation strategy

Another thing to consider is the fact that the honest dispute network kind of pushes the game to a knife’s edge relative to the Q > 1 - 1/M violation blow-up, so any strategy that commits to add disputes indefinitely is immediately playing a near-divergent cost game (provided escalationHalt is high enough in oracle game). Honest disputers don’t eat the divergent costs since they are disputing only when it’s worth it to begin with. For example, with a multiplier of 1.1 and assuming dispute barriers of +/- 0.8 (vs theoretical min ~0.7 in normal), we see a ~20% survival rate per round were it only honest disputers. The Q inequality implies ~9.1% is the point at which costs diverge, but even if costs are finite above that they are painfully high until the realized survival rate is much above the floor. For example, let’s add in the manipulator’s prolongation with 10% chance. Now the oracle game survival rate is 10% per round. 10% > 9.1%, but the cost multiple (times whatever proportional cost the oracle game started with) can be represented as: 
sum from N = 0 to infinity across C * (M * P)^N

and

P = 1 - Q

⇒ cost ~= sum from N = 0 to infinity across (1.1 * 0.9)^N 
⇒ cost ~= 100x (proportional)
The manipulator doesn’t pay this entire cost, but they do pay ~11% of it (their round share is technically ~10% / 90% given 10% oracle game survival) and don’t recoup much from the income side. The honest dispute network eats the rest of the cost side, but they are still positive EV net. In general, if the manipulator wants to self-dispute to avoid internal oracle game losses, they need to dispute tighter than the honest dispute network, and it is hard to estimate the exact honest dispute network’s barriers at any given time. The manipulator would probably need to get somewhere near the minimum non-grief-able profit threshold of ~ +/- 0.7 in a normal, which modifies the manipulation game itself heavily. At dispute barriers of +/- 0.73, we see the below: Tight dispute barriers Y = 0 isn’t even an available strategy since the survival of 7.06% violates the Q inequality’s 9.1% floor. So it seems possibly structurally impossible (granted distributional caveats, real world price-action can be different etc) to actually avoid negative pnl via self-disputes unless you go Y < 0 at which point extraction meaningfully falls off.

​
Manipulation without a swap fee present

In the “Manipulation” section, we were looking at a manipulation strategy where wrong prices are reported in the oracle. The swap fee by contract rule places restrictions on the allowed price placement, specifically, the new price must be outside the swap fee band around the last report’s price. Assume now we have a 0 swap fee and have a no-dispute band of the multiplier * 0.8 st dev (wider than theoretical minimum). Assuming M = 1.1, this corresponds to dispute barriers of ~ +/- 0.88 st dev. The manipulator was opening a long and trying to get as low a price as possible to settle in the oracle relative to the true price. For this analysis we assume a normal distribution. The game starts with the initial report, where the manipulator places a price some Y above -0.88 st dev. If the true price goes up by just under Y, the manipulator updates their oracle price Y higher, before the honest dispute network can dispute their report profitably. If the true price goes down ~ 0.88 - Y st dev, the manipulator is now breakeven, so they place a new price some Y above -0.88 st dev from the current price at that time. We can model the extractable value as a simple barrier game, with upper barrier at +Y and lower barrier at -0.88 + Y. The reporter earns the spread between the true price and the settled oracle price at time of finalization. For 0.05 increments of choice of Y, we find the below: Barrier game analysis It does not seem defensible to pursue this strategy. If the manipulator survives the entire 1.1x escalation each round with zero costs, they get to extract ~0.45 st dev in expectation. They can try fewer rounds but in expectation you get proportionately less extraction. The other strategy a manipulator could attempt along these lines is report a price wrong by some Y, then hope the price settles. They can let the honest network dispute at their standard barriers. If the honest network disputes, they can then report another wrong price and try again. 0.88 is probably too loose for the dispute network barriers, so we will go with +/- 0.8 against the theoretical minimum grief-resistant barrier of ~0.7. If a manipulator reports some Y lower than true, the honest network’s dispute barriers are (-0.8 - Y, 0.8 - Y). The conditional mean true price at time of settlement given the choice of Y is actually quite close to Y itself for these barriers. Conditional survival bias offsets the vast majority of extraction from the wrong price, to the point where it doesn’t seem worth it to attempt given internal oracle game costs even at just 10% initial liquidity as % notional.

​
Numerical justification for our choices of dispute barriers

As described in the “stronger form of manipulation section, we can write a disputer’s EV against any choice of adversarial dispute distance as the below: 
EV = dispute_distance - (1-Q(adv_dist))*adv_dist*multiplier
Where:
  • dispute_distance is where an honest disputer disputes
  • adv_dist is where anyone else chooses to dispute the honest disputer’s report
  • Q(adv_dist) is the probability the price does NOT get to the adv_dist, in either direction
  • multiplier is the oracle game multiplier
Next, we can create a table for where the EV shakes out for different choices of dispute_distance and adv_dist. Q(adv_dist) is implied from the DNT probability of +/- adv_dist barriers. We will start with a multiplier of 1.1x, and use a normal distribution: EV table for dispute distances From the table increments, disputing starts to become profitable around 0.75 st dev of price error. The worst adversarial dispute distance appears to be around the expected end-period expected move, but this is just a coincidence in a normal distribution. Let’s see what it looks like for multiplier of 3, even though this is supposed to be a low-multiplier analysis: EV table for multiplier 3 Additional analysis So, even with multiplier = 3, the worst place to get disputed is ~0.8 st dev.

​
Arithmetic dispute barriers versus logarithmic price action

In openOracle, the dispute barriers are ~ 0.65 * volatility * multiplier. Let’s assume for simplicity the volatility * 0.65 is 20%, the multiplier is 1, and we are in some smooth symmetric distribution like a normal. Let’s also assume the honest participants dispute at 20%. From a manipulator’s perspective trying to impart price error to a linear external notional, the no-dispute barriers are +/- 20% (arithmetic bounds), while from the market’s perspective, the chance the price hits +20% is the same as the price hitting -16.6% (log-symmetric bounds). This means the manipulator may have an extra 3.33% of “juice” to capture whenever they finally settle, so they get to extract up to ~3.33/20 ⇒ +0.16F extra. In the real world, when volatility spikes to extremes (say 20% per minute on eth-usd), the distribution is going to be strange, with fat tails, large jumps, lots of cross-venue basis etc, so the extent to which the extra E/(E+1) is extractable may be limited. This environment may increase expected rounds as well despite the extra “arithmetic wedge” in one of the no-dispute barriers.

​
Moral of the story

openOracle price error scales linearly with background market volatility. In the absence of volatility, the oracle cannot drift. The worst-case accuracy bounds (where market volatility dwarfs fixed swap and protocol fees) collapse towards ~ 0.64 * volatility * multiplier. The mean price inside the band remains centered around true price without manipulation. With manipulation, the mean price inside the band can be biased toward the no-dispute band but conditional survival bias on price from optimal manipulator strategy prevents bias-able price error from becoming the entire no-dispute band in expectation. In general, when we think about attacks to bias the mean settled oracle price, there are two categories:
  1. add disputes with correct prices to prolong game if settlement price is against you
  2. report wrong prices
For 1, violating the “per-round settle probability > 1 - 1/multiplier” inequality creates divergent losses for the manipulator. They directly lower settle probability since they have to add disputes some portion of the time the price would have settled otherwise. So the only viable strategy seems to be a small number of opportunistic delays at the beginning of the game versus a commitment to long-run manipulation. For 2, the closer the wrong price is to true, the lower the extraction, and the farther from true, round survival chance in the oracle game (no dispute) goes to 0 faster than extraction increases. The lower survival probability from skewed pricing also may violate the settle probability inequality. For these two, we are looking specifically at low multiplier oracle games for linear-type oracle applications. For binary events like liquidations, you use higher multipliers and quick delay cost is much more important than granular accuracy.