Proposal for a trust-minimized price oracle

[j0i0m0b0o]

The below oracle is designed to be a trust-minimized and permissionless way to get token prices that anyone can use.

At its most basic level the oracle works by having a reporter submit both a limit bid and ask at the same price. Anyone can swap against these orders minus a small fee (no partial fills). If nobody takes either order in a certain amount of time, it is evidence of a good price that can be used for settlement. If an order is taken, the taker needs to post collateral in both tokens, imply a new price, and the timer restarts.

The oracle uses exponential collateral escalation during disputes to increase the cost of manipulation and give users some statistical guarantees around total time to settlement and cost to delay. In the average case, the capital required to report accurate prices can be much lower than the notional amount settled by the reported price. The goal is to replace the current set of centralized and trusted oracle intermediaries so DeFi applications can have fewer points of failure.

The design relies on 1 of n self-interested participants who are not economically aligned with the external position being settled by the oracle having their transaction included before the deadline.

One of the clear limitations of the design is censorship (submit bad price → censor disputes → profit). This places a hard limit on how much the oracle can secure on L2 and, until FOCIL, we must use longer settlement times on the L1 to reduce the chance of an attacker controlling many blocks in a row.

Below is a simplified example of the oracle life cycle:

Let’s say an application wants the price of WETH against USDC. In the price request, they specify

1. token1: WETH
2. token2: USDC
3. token1Amount: 0.1 WETH
4. settlementTime: 10 seconds
5. multiplier: 1.5x
6. reward: 0.001 ETH

The oracle contract balance is now 0.001 ETH.

This price request gets on-chain and anybody can report a price. Let’s say the price of ETH is $3000. The next step is a reporter submits an initial report, winning the race against everybody else to claim the 0.001 ETH.

Because an application was using the oracle to get a price, we will assume there are two people who are in opposite positions. Meaning, if the price is reported higher, one person benefits and the other loses, and vice versa. Assume one of the people is completely passive, but assume the other is active, and would benefit were the oracle to settle reporting WETH as not as valuable. So assume the initial reporter is the manipulator in this party, because they are able to outbid everybody else in the block.

In the initial report, they specify:

token1Amount: 0.1 WETH
token2Amount: 150 USDC

The oracle contract balances are now 0.001 ETH, 0.1 WETH, and 150 USDC.

These report balances imply an ETH price of $1500 when the real price is $3000.

After settlementTime of 10 seconds assuming nobody disputes this report, the report may be settled and become usable for the application, at a horrible price. But, it is profitable to come along and dispute this, so we assume a disputer comes along before 10 seconds is up.

In the dispute, they specify:

token1AmountNew: 0.15 WETH
token2AmountNew: 450 USDC
tokenToSwap: USDC

They decide to swap against the initial reporter’s 150 USDC, meaning they choose USDC as the token to swap in their dispute. The token1AmountNew is 50% larger than the initial report by contract rule using the 1.5x multiplier from the price request. The token flows are as follows:

The oracle contract takes 150 USDC from the disputer, then adds this to the initial reporter’s original 150 USDC and sends it all to the initial reporter, for a total of 300 USDC sent to the initial reporter.

Next, the oracle contract takes 450 USDC and 0.05 WETH from the disputer and adds it to the report.

The contract balances are now 0.001 ETH, 0.15 WETH and 450 USDC and the settlementTime timer resets to another 10 seconds.

Assume the manipulator relents and the settlementTime of 10 seconds passes, anyone can come along and settle the reported price. The oracle price is $3000 while the real price is $3000.

In the settlement, the settler only specifies which report they are settling. Typically they receive some settler reward in ETH paid for by the price requestor but we assume 0 for this example. The token flows in the settle are as follows:

Initial reporter (the manipulator) receives 0.001 ETH from the initial reporter reward. This must be netted against the gas cost of outbidding everyone else to be the first initial reporter.

Disputer receives 450 USDC and 0.15 WETH back.

The contract balances are now 0 across all ETH and tokens. If we net the flows across the entire oracle life cycle of price request, initial report, dispute and settlement, we see the following:

Initial reporter:
USDC: +150
WETH: -0.1

Disputer:
USDC: -150
WETH: +0.1

Assume the gas fees and initial reporter reward net to near zero. The true price of ETH is $3000, so the manipulator loses $150, the disputer makes $150, and the oracle price settles fairly for the application to use. If the manipulator decided to keep trying to manipulate the price by disputing the honest disputer’s report, they would lose an exponentially increasing amount of money that scales with the error in reported price.

The reference oracle implementation in solidity has more parameters to tweak, like swap fees, escalation halt, dispute delay, time mode (seconds vs blocks) and many more, but the simplified version is accurate with respect to how the incentives work.

The swap fees are an important parameter for a given oracle instance. A new reporter pays the previous reporter a swap fee in % which is set at time of price request. If the swap fees are too low relative to the background market volatility over the specified settlement time, the total time to settlement may drag on as disputes resetting the timer are more common. If the swap fees are too high, on the other hand, this exposes passive users of the oracle price to arbitrage loss because an active manipulator can try to get the price to settle somewhere inside of the swap fee bound but away from the true price.

So there is a fundamental tradeoff between total oracle instance finalization time and arbitrage loss to end users.

In terms of the maximum arbitrage loss a completely passive end user is exposed to, this number is strictly less than the total internal oracle swap fees per round plus gas fees plus jump loss to the reporter. We call this an effective swap fee F (swap_fees + gas_fees + jump_loss). We assume if the price were outside of F, it would be disputed by 1 of n self-interested participants. Since only the final surviving price contributes to price error in an external notional, the total extractable value is <= F. This applies to linear external notional only. Binary external notional is more complicated as there is no provable bound on arbitrage loss, but one can imagine an oracle instance parameterized to punish settlement delays especially hard if we need to settle binary bets.

Jump loss is a cost to reporters no matter which direction the price moves. Token prices can discontinuously gap past +/- F and the reporter eats the difference versus the standalone swap fee after someone disputes and corrects the price. Higher multipliers burden reporters with more jump loss per round relative to the natural price error of the previous report.

The escalation halt is another important parameter. Past this halt, disputes can continue but no longer need to post exponentially increasing amounts of collateral. This way you can ensure the oracle instance does not escalate past the perceived capacity of the dispute network while still imposing high penalties on manipulators.

The full solidity implementation can be found below. Note the direct function entries may be supplemented with external contract reorganization / replay guards (i.e. if tx not inside passed block number and timestamp revert, or settle must use matching price request stateHash) which may help but do not eliminate risk.

src/OpenOracle.sol

Would love to hear any feedback or criticism on the design, and am happy to answer any questions! We hope to contribute to the development of truly trust-free financial applications.

[Killari]

Hey,

Looks really interesting, why does the disputer take the 150usdc? Do they also have a choice to take the 0.1 weth? If real price is 3000$, and they can choose either usdc or weth, they should choose weth as that’s worth 300$.

[j0i0m0b0o]

Thanks Killari - in the simplified oracle life cycle example, because the disputer chose USDC as the tokenToSwap, the initial reporter only receives 2 times the amount of USDC they had committed (their 150 USDC + 150 USDC from the disputer), leaving the WETH behind for the disputer to effectively claim. It is as if the disputer swapped 150 USDC for 0.1 WETH.

[j0i0m0b0o]

Some updates and new results since the original post.

Mechanism refresher

An openOracle report is two limit orders, a buy and a sell, at the same price. The orders are locked until either the timer runs out or one is taken. To take one of the limit orders, you must replace them with larger ones at a new price. When the timer runs out without a dispute, the price is settled. Any disputes reset the timer.

Censorship defense

We’ve refined the censorship model since the original post. FOCIL doesn’t change things much at the adversarial limit given the block stuffing angle. The defense is simpler: to settle a mispriced oracle report, the attacker must bribe out every dispute opportunity for the entire settlement window. Very roughly, for a linear external notional N with initial oracle liquidity L, price error R > \kappa (otherwise disputes are unprofitable and censorship is unnecessary), cost to report \kappa, and assuming the attacker’s counterparty is totally passive, the required settlement time for a grief ratio G is:

T = \frac{(G + 1) \cdot R}{(R - \kappa) \cdot (L / N)}

The definition of T depends on bribery context: under per-block bribery (e.g. ePBS), each block is an independent bribe event. Without strong commitment infrastructure, each non-contiguous streak of the same producer is an independent event. Under credible long-horizon commitments, each unique economic entity as a producer is an independent event. The settlement window must contain enough independent events to satisfy the grief ratio. If the attacker is themselves a block producer for some fraction of blocks, they don’t need to bribe themselves, so T should be scaled up to account for their expected concentration.

Parasitic open interest (external notional latching onto an oracle report without paying for it) drives N up and L/N down, weakening the grief ratio. However, this seems unstable, since the original attacker can add their own notional to the same report, exploiting anyone who latched on. Alternatively, contrived oracle games can be constructed to exploit parasitic OI directly. Standing parasitic liquidity seems to get selected out of existence before the paying oracle user submits a price request.

Oracle accuracy

The disputer’s EV for taking a mispriced limit order at distance D from true price against an adversary who counter-disputes at distance A is:

EV = D - (1 - Q(A)) \cdot A \cdot M

where Q(A) is the double-no-touch probability (price stays within \pm A for the settlement time) and M is the multiplier. If the disputer calibrates against the worst-case adversarial counter-dispute, we see

C = \max_A \left[(1 - Q(A)) \cdot A\right]

Under a normal distribution, this maximizes at A \approx 0.84 \cdot \sigma(T) with C \approx 0.65 \cdot \sigma(T). Disputes are profitable when D > C \cdot M, giving honest dispute barriers at approximately \pm\, 0.65 \cdot M \cdot \sigma(T).

Including swap fees F_s and protocol fees F_p, the disputer’s EV becomes:

EV = (D - F_s - F_p) - (1 - Q(A)) \cdot (A - F_s) \cdot M

As a conservative threshold, fees are purely additive to required edge, so the dispute distance shifts from D > 0.65 \cdot M \cdot \sigma(T) to roughly D > 0.65 \cdot M \cdot \sigma(T) + F_s + F_p. In practice, the swap fee reduces the loss to an adversary on a counter-dispute (the (A - F_s) term), so the actual barrier can be tighter.

Settlement probability inequality

Dispute frequency is governed by a more fundamental condition than the swap fee. With multiplier M, per-round settlement probability Q, and dispute probability P = 1 - Q, with any per-round proportional cost c > 0, the total expected cost of the oracle game is a geometric series:

\sum_{n=0}^{\infty} c \cdot (M \cdot P)^n

which converges only when:

Q > 1 - \frac{1}{M}

This is what actually governs dispute frequency, not the swap fee. The swap fee shifts the dispute barriers (adding ~F_s to the required edge), which widens the no-dispute band and pushes Q higher, but the fundamental constraint is the Q inequality above. The escalation halt caps the oracle game size, breaking the divergence, but as long as it’s high enough relative to external notional, a manipulator still faces extreme costs when adding too many disputes.

Manipulation bounds

We now have a fuller analysis of manipulation strategies for linear notionals, where a manipulator wants to bias the settled oracle price in their favor as much as possible, and has a completely passive counterparty. We assume smaller multipliers and none to very small F_s and F_p in the oracle game, since this maximizes oracle accuracy for linear notionals.

The strongest manipulation strategy in the absence of censorship seems to be selective delay: the manipulator only reports the true price, but decides whether to delay or settle based on which has higher utility. A very rough way to think about this attack is to delay when the price is against you, and let it settle when it’s in your favor.

Under a normal distribution, using backward induction over the oracle game rounds, the expected bias from this strategy is approximately (0.15\text{–}0.20) \cdot \sigma(T) under reasonable parameterizations (L/N \approx 10\%, M \approx 1.20). This is much smaller than the dispute barriers themselves. Higher initial liquidity fractions reduce bias further at the tradeoff of more initial reporter cost.

Wrong-price strategies (reporting a deliberately incorrect price) come in two flavors. In the first, the manipulator places a wrong price and continuously updates it to stay just inside the dispute barriers. This has positive extraction but requires many rounds with very low per-round survival probability which is impractical with exponential game growth. In the second, the manipulator reports a wrong price and lets the honest network dispute at standard barriers. Here, the conditional survival bias under reasonably low multipliers nearly exactly offsets the placement advantage, yielding close to zero extraction.

Oracle game fee routing

The prior contract had a single hardcoded address accruing all oracle game protocol fees. The current contract lets the oracle game creator specify a protocolFeeRecipient at creation time. Fees can be routed to the parties who paid for the oracle game (e.g. split between lender and borrower in a lending setup), burned by setting the recipient to address(0), or directed anywhere else.

Initial reporter bounty

The initial reporter bears risk from being disputed, losing in expectation unless compensated. To find the market-clearing compensation for this, we use a bounty contract that starts small and escalates exponentially each round (e.g. 1.5x per round). The first reporter to submit claims whatever the bounty has grown to. If conditions are unfavorable (high volatility, high gas), no one reports until the bounty grows enough. The realized payout reveals the true cost of initial reporting under those conditions.

Open work

The goal is a unified DP formulation where the external notional payoff can be any function (linear, binary, convex, etc.) and the manipulator has access to the full strategy space: delay, wrong-price reporting, ePBS censorship bribery, and settlement, all in a single backward induction. Sweep across oracle game parameterizations (L/N, M, T, fee schedules) and distribution families to map out expected extraction across the full space. Right now the linear and binary notional analyses are separate, the linear analysis assumes a normal distribution, there is an assumption of no censorship (e.g. a cooperative L2 sequencer), and the price process is continuous rather than discrete block times. Unifying these under arbitrary payoffs, distributions, inclusion models, and discrete-time dynamics is the main thing left to do.

In conclusion

The oracle problem is hard and the math is non-trivial. We could easily have made mistakes (as there were in the original writeup) or missed attack vectors. It’s been difficult to get substantive feedback on this approach so far, so if you see holes in the analysis or have constructive criticism, we’d genuinely appreciate it.

Full writeups and derivations at Oracle Accuracy & Cost - openOracle and Economic Bounds - openOracle and Attack Vectors - openOracle.

The contract has no privileged access, no admin keys, and no upgradeability. MIT licensed.

Current oracle contract: openOracle/src/OpenOracle.sol at bab490aeeae992c8ae28fb2286dff96d393c96b2 · openOracleProject/openOracle · GitHub

[e3o8o]

Interesting design here. The escalating collateral auction for price discovery is clean; it makes manipulation cost convex while keeping honest reporting cheap, which is the right shape for an oracle incentive structure.

A few observations and questions:

1. The finalization time ↔ accuracy tradeoff as a function of volatility regime

The settlement time parameter creates the most fundamental tension i see: short settlement = fast finality but higher arbitrage exposure; long settlement = better accuracy but slower usability. In practice, this tradeoff isn’t static, it shifts with market volatility. During high-vol regimes (exactly when oracle accuracy matters most), the swap fee bound F, may be insufficient to deter manipulation attempts, because the potential profit from settling a bad price scales with the external notional being settled.

Have you considered making the settlement time or swap fee adaptive like a keyed to a rolling volatility estimate or recent dispute frequency?

2. Censorship resistance beyond FOCIL

You correctly identify censorship as the hard limitation (submit bad price → censor disputes → profit). On L2s this is especially acute because sequencer sets are small. Even with FOCIL on L1, the attack window is settlementTime × P(attacker controls consecutive slots). For applications settling large notional, this may require impractically long settlement times.

One angle that I think could be worth exploring: the oracle accept committed disputes (hash-then-reveal just like ENS’ commit-reveal) that are censorship-resistant because the sequencer can’t identify them as disputes until reveal? This would compress the effective censorship window

3. Applicability to non-price data

The mechanism is elegant for continuous price feeds where arbitrageurs have a natural incentive to dispute. But many DeFi applications also depend on discrete event data, protocol healthchecks, TVL thresholds, governance state changes - where the “1-of-n self-interested disputer” assumption may not hold because there’s no direct arbitrage profit from correcting a bad report.

I am yet to look into how this extends to binary or categorical data feeds, where the economic incentive to dispute is weaker

4. Interaction with parametric settlement

For parametric applications (where payouts trigger deterministically on oracle readings), the effective swap fee F directly bounds the maximum extractable value per settlement. This is a useful property as it means the oracle’s security guarantee is quantifiable per-instance rather than relying on aggregate economic security assumptions (as with staked oracle networks). I would like to see how you formalized the relationship between F, the external notional, and the minimum dispute network size needed to sustain honest equilibrium?

[j0i0m0b0o]

Appreciate your comments and questions.

1. The finalization time ↔ accuracy tradeoff as a function of volatility regime

The settlement time parameter creates the most fundamental tension i see: short settlement = fast finality but higher arbitrage exposure; long settlement = better accuracy but slower usability. In practice, this tradeoff isn’t static, it shifts with market volatility. During high-vol regimes (exactly when oracle accuracy matters most), the swap fee bound F, may be insufficient to deter manipulation attempts, because the potential profit from settling a bad price scales with the external notional being settled.

Have you considered making the settlement time or swap fee adaptive like a keyed to a rolling volatility estimate or recent dispute frequency?

Our understanding is error bounds widen (worse accuracy) with longer settlement times, with very roughly a square root degradation as settlement time increases.

What deters manipulation attempts is the geometric cost of sustaining a lie or delaying the oracle game as well as the cost to censor an initial report over the entire settlement time.

There is another manipulation category that scales with external notional cleanly, which in the linear notional case is an attacker trying to bias a settled price inside the dispute barriers given a passive external notional counterparty. We try to find game parameters that minimize this effect, mainly via multiplier and initial oracle liquidity as some fraction of external notional. The mean bias is then some fraction of the accuracy bound.

Next, the honest dispute barriers are naturally in volatility units, so F already is adaptive to volatility.

Dispute barriers in volatility units also means expected dispute frequency is ~ invariant to the absolute volatility level assuming no oracle game swap/protocol fees. If someone wants to add too many disputes, the geometric series of oracle game cost can diverge in the limit (settlement probability inequality in our update), which is not good for the attacker if each dispute is unprofitable.

In general, one of the challenges with allowing on-chain state to change an oracle game parameter like settlementTime is that it creates another manipulation surface.

2. Censorship resistance beyond FOCIL

You correctly identify censorship as the hard limitation (submit bad price → censor disputes → profit). On L2s this is especially acute because sequencer sets are small. Even with FOCIL on L1, the attack window is settlementTime × P(attacker controls consecutive slots). For applications settling large notional, this may require impractically long settlement times.

One angle that I think could be worth exploring: the oracle accept committed disputes (hash-then-reveal just like ENS’ commit-reveal) that are censorship-resistant because the sequencer can’t identify them as disputes until reveal? This would compress the effective censorship window

On your first point, we give a user the ability to pick their spot on the tradeoff curve, for example using a heuristic bound noted in our update here.

If you want a shorter settlement time, you pay for more initial liquidity in the oracle game, since this increases the costs to censor a bad price via ePBS bribes or something similar. At the adversarial limit it isn’t so much about waiting for slots an attacker doesn’t control. With longer settlement times, the chance a single entity controls that many blocks in a row falls off rapidly, and the main attack is bribery across multiple proposers.

Next, the ~ square root relationship between oracle accuracy and settlement time means longer settlement times are not as bad as they might seem.

Commit–reveal is an interesting idea and we’ve thought about it to some extent, but we’re not yet convinced it materially reduces the worst-case censorship risk when integrated into the oracle game, granted maybe we just don’t have the right construction yet. A sequencer (or proposer set) can add their own commits and selectively censor other commits or reveals just as easily as a plain dispute transaction, and if they’re willing to censor broadly over the settlementTime then hiding intent doesn’t buy inclusion. If the scheme is designed to make commits indistinguishable from normal traffic, you also have to deal with economic/information leakage (token amounts, inclusion tips, etc), and reveal delays can create new exploit surfaces (e.g., trading against a stale price on a late reveal). That said, we are open to the idea. If there’s a commit–reveal construction that is adversarially robust and demonstrably reduces the required settlementTime or initial liquidity in practice without widening accuracy bounds too much, that would be a wonderful thing.

The more work we do, the more it seems like censorship is something that just needs to be priced and approached head-on.

3. Applicability to non-price data

The mechanism is elegant for continuous price feeds where arbitrageurs have a natural incentive to dispute. But many DeFi applications also depend on discrete event data, protocol healthchecks, TVL thresholds, governance state changes - where the “1-of-n self-interested disputer” assumption may not hold because there’s no direct arbitrage profit from correcting a bad report.

I am yet to look into how this extends to binary or categorical data feeds, where the economic incentive to dispute is weaker

We don’t think this oracle design can be used for things that are not “an exchange rate between two on-chain tokens”, for exactly the reason you said. There is no trade to enforce correctness. But, maybe there is something clever we are missing.

4. Interaction with parametric settlement

For parametric applications (where payouts trigger deterministically on oracle readings), the effective swap fee F directly bounds the maximum extractable value per settlement. This is a useful property as it means the oracle’s security guarantee is quantifiable per-instance rather than relying on aggregate economic security assumptions (as with staked oracle networks). I would like to see how you formalized the relationship between F, the external notional, and the minimum dispute network size needed to sustain honest equilibrium?

At scale, an attacker doesn’t know the depth, profit thresholds, or participants in the dispute network (the “dark forest”). It is a global, permissionless game. Arbitrage capital availability is elastic to internal oracle game EV, which scales with price error. Also, if someone starts rapidly escalating the oracle game in an attempt to out-spend the dispute network, this is like a gigantic bat signal to arbitrageurs.

More simply, the attacker must beat an adaptive, permissionless responder set whose available capital increases with visible EV and escalation, so “minimum network size” isn’t a stable parameter in equilibrium.

For this reason we don’t try to model the dispute network size more than how it might relate to the escalation halt, which is the point at which the game stops escalating but disputes can still continue.

That said, we do attempt to formalize the relationship between F (the dispute barrier), external notional, and other oracle game parameters in an optimal stopping / dynamic programming context using backward induction to see how much an attacker can extract from a linear external notional here.

Thank you very much for taking a look at our design and providing feedback. If there’s anything incorrect or unclear, I am happy to correct or clarify.

[e3o8o]

Thank you for the extremely thorough response. Having now looked through the live architecture and the dispute tracking explorer on openoracle.org, it’s great to see this formalized and running in production. A few follow-ups:

On adaptive barriers vs. manipulation surface: Your point that onchain adaptive parameters create new manipulation surfaces is well taken. The fact that honest dispute barriers are already denominated in volatility units (and thus naturally adaptive) is a cleaner property than I initially gave it credit for. Seeing how the exponential collateral escalations are mapped in your docs, it means the system self-calibrates without introducing a new attack vector through parameter governance. That is an elegant design choice tbh.

On commit-reveal for censorship resistance: I appreciate the candid assessment. You’re right that a sequencer willing to censor broadly over the full settlementTime can censor commits just as easily as plain disputes. The construction I had in mind was more along the lines of making commits indistinguishable from normal contract calls (no distinct function signature), but as you noted, the economic leakage from token amounts and inclusion tips likely makes this distinguishable in practice.

That said, I’d mention that I worked on commit-reveal constructions in a different context, specifically for protecting pre-computed state transitions in jbaylina’s sync-rollups - an early draft of the synchronous rollup architecture. In that setting, commit-reveal does materially reduce MEV extraction because the threat model is different; the attacker is trying to front-run a specific submission to claim gas refund or wedge state transition, not to censor all activity over an extended window. The commitmentOwner binding (only the original committer can reveal) eliminates the front-running vector entirely. Whether that construction translates usefully to the oracle censorship context is an open question, but the architectural pattern may be worth examining.

On the dispute network: I like your framing of the adaptive, permissionless responder set. It’s essentially an argument that the oracle’s security scales superlinearly with the value at stake, because the bat signal effect recruits more capital than the attacker can anticipate. This is a much stronger property than the fixed minimum network size assumptions that characterize staked oracle networks. Given that you have a live explorer now, it would be incredibly valuable to see empirical data on how quickly capital actually mobilizes in response to onchain oracle disputes at different notional sizes.

On parametric settlement: I reviewed the formalization in your docs covering linear notional manipulation bounds. And I found the backward induction approach to bounding extractable value rigorous for my work on parametric risk infrastructure - you can reason about the security of each settlement independently.

Excellent work overall getting this to mainnet. Will be following the project closely.

[junbyjun1238]

Very interesting design. I have a practical question regarding the execution and financing side for the dispute network.

Because a disputer’s collateral remains locked until the report is either settled or displaced by a subsequent dispute, it seems that standard same-tx flash liquidity cannot be used to fund the final “active” dispute position.

Is the intended model here that responders rely on pre-positioned inventory, pooled capital, or credit lines? I noticed the contract supports disputes submitted by one address on behalf of another, which gracefully suggests a wrapper or pooled-funding approach rather than relying on atomic callbacks for the collateral itself. This also perfectly contextualizes why the escalationHalt parameter is so crucial—it must be directly calibrated against this specific, non-atomic balance-sheet capacity of the network.

If this understanding is correct, the effective ceiling on honest responder capital depends less on the visible EV of the dispute, and more on the actual non-atomic capital the network can mobilize at any given moment. I’m curious to hear your thoughts on how you view this tradeoff in practice, and how an ideal dispute network might be bootstrapped to handle these upfront capital requirements

[j0i0m0b0o]

Thanks for your comments and questions.

Flash liquidity

You are right that typical flash liquidity is not a part of the defense strategy given the time-lock; however, you can still atomically source the missing leg from an AMM or lending protocol (not a flash borrow), then dispute if you only have one of the two tokens.

Is there an intended model?

We can’t really control how the game plays out. There will likely be a heterogeneous set of strategies employed. Whatever capital is actually available will be pulled into the game from participants who are already liquid. In addition, some participants may explicitly stage capital for oracle participation if they expect adversarial behavior. Credit lines as you mentioned could be used, and along the same lines, a stablecoin minting channel (USDC issuance for example).

In terms of a pooled model to fund disputes, it is doable, granted you are trusting whoever is pricing the disputes and there are some implementation quirks around JIT attacks. It is one of the possible models. A nice thing about this kind of design is capital can be collected from many sources in real time, and everybody can split the payout, but I think the oracle game would work fine without it too.

Ceiling on honest responder capital and tradeoffs

This also perfectly contextualizes why the escalationHalt parameter is so crucial—it must be directly calibrated against this specific, non-atomic balance-sheet capacity of the network.

If this understanding is correct, the effective ceiling on honest responder capital depends less on the visible EV of the dispute, and more on the actual non-atomic capital the network can mobilize at any given moment.

You’re right that because the active dispute stake is time-locked, you must rely on non-atomic liquidity to fund the final live round. Responders need inventory or credit. But I don’t think there’s a specific non-atomic capacity of the network you can calibrate escalationHalt against: that capacity is opaque and time-varying. Since each dispute refreshes the timer, settlementTime and disputeDelay expand the mobilization horizon and make the attacker’s stopping problem inherently non-deterministic. The actual non-atomic capital the network can mobilize at any given moment is very difficult to reason about ex ante, and becomes even harder as escalation unfolds.

On the other hand, we can look into what kind of parameterization we would use if we are pessimistic about response/mobilization (how we might view the tradeoff space in practice).

This kind of pessimistic-regime oracle game would be characterized by longer settlementTime (more time per-round to mobilize) and a disputeDelay where disputes can only fire X seconds after a report (limit escalation speed). It would include per-round proportional fees (protocolFee) directed to the dependents of the oracle game (protocolFeeRecipient contract) combined with moderate multipliers to impose heavy expenses along the escalation path before the attacker can attempt to slip a bad price through. It is a tradeoff space: longer settlement times + higher protocol fees reduce oracle accuracy and increase time to finalization, and in the case of longer settlement times increase initial reporter compensation.

Putting myself in the shoes of the attacker, it is difficult to determine when all available non-atomic capital is out-scaled versus the deterministic costs to escalate the game to that point, so I still feel like a high escalation halt is more useful than a low one even in this pessimistic responder context. For example, if you have a $100 notional, and $10 in initial oracle liquidity, you could set the escalation halt to $1000. At the halt, with a 1% protocol fee, the oracle game dependents are receiving 10% of their notional per dispute (1% * $1000 / $100), not to mention the accrued fees along the escalation path. This is just for illustration and the oracle game can be parameterized however you would like.

So in practice, if you don’t want to set the escalation halt sky-high, you can calibrate escalationHalt to external notional and how much ‘toll’ you want an attacker to have to pay to delay or attempt a mispricing, not to a presumed fixed responder balance sheet ceiling. escalationHalt does not need to be excessively high to make things painful for an attacker.

If this is not what you meant, or I didn’t fully answer your question, let me know and I’ll try to clarify.

Bootstrapping

As soon as meaningful capital is bet on the oracle output, it creates oracle game flow and the potential for high profit opportunities. There is now incentive for unaligned participants to integrate oracle game EV into their trading architecture, as a one-time cost. The ideal dispute network is opaque, deep, and tough to fool. Basically, hard to reason about. We think this emerges naturally from the incentives, but on some level we won’t know until we find out. What seems like a simple game on the surface goes very deep.

There is a chicken-and-egg problem from the perspective of newness: it seems risky, is a dangerous game, and is not widely understood, so it’s hard to get meaningful capital bet on the output in the first place, which limits the amounts in the oracle game, which limits the possible size of the dispute network. So we are starting by building small stuff, getting the word out, and asking for feedback on the design.