Block-level attack surfaces
Censorship and inclusion attacks
An attacker can report a bad price, censor all disputes for the settlement time, and settle the bad price, draining any external notional that depended on it.Censorship context
Assume all block producers are accepting bribes, and if the bribe is large enough, they will not include dispute transactions. Assume zero altruistic block producers, perfect bribery infrastructure with 100% participation, and zero slashing. Alternatively, assume ePBS is live, which makes these conditions realistic. The attacker submits a bad price and tries to censor all disputes with bribe payments for the settlement time.Block count vs. unique producers
The below formulas assume per-block bribery and try to find an oracle game settlement time to enforce costs on an attacker, where each block is an independent bribe event (e.g. via ePBS). More generally, the settlement window must contain enough independent bribe events to satisfy the grief ratio. What counts as an independent event depends on the bribery infrastructure:- Per-block bribery (ePBS flow): each block is a separate bribe event, so in blocks is correct as stated below.
- No strong commitment infrastructure: a producer controlling non-contiguous streaks (e.g. AAAA BB AAAA) must be re-bribed per streak, so the settlement window must contain enough runs to satisfy the grief ratio.
- Credible long-horizon bribery commitments: a producer is bribed once for all their blocks regardless of streaks, so the settlement window must contain enough unique producers.
Linear notionals
The attacker has an external notional , submits a price with error with oracle initial liquidity , and censors disputes for blocks. The profit and cost of the attack are:Binary notionals
For binary notionals, the internal oracle price error must be the distance from the true price to the binary threshold . Here, we assume the attacker’s profit is . Define the required price error as . The cost of the attack is the same:L2 sequencer trust
On L2s, a sequencer is generally trusted for transaction inclusion. This places a hard limit on the amount the oracle can secure without better inclusion guarantees. If the amount at stake exceeds what the sequencer can be relied upon for, the oracle can migrate to L1.Parasitic open interest under censorship
External notional can latch onto a report as parasitic open interest, increasing and decreasing , which increases the required settlement time for a given grief ratio. However, in a censorship bribery context, parasitic open interest is unstable. If there is standing liquidity willing to latch onto any report that fits within its parameters, an attacker (original non-parasitic counterparty) can add their own notional to the same report. Anyone who latched on blows up, unfortunately taking the original passive oracle dependent with it. Standing liquidity is therefore economically unstable and likely to be selected out over time before the oracle user submits a price request. Contrived oracle games can also take advantage of parasitic open interest: as soon as there is enough standing liquidity, the payoffs are added together and a game can be contrived to take advantage of them.Block stuffing attacks
Anyone can attempt a block stuffing attack. By spamming high-fee transactions to inflate gas costs, an attacker can report a bad price and make it uneconomic for honest disputers to respond, unless those disputers are economically aligned to the oracle output. Assume one attacker whose counterparty is completely passive, and assume zero swap or protocol fees in the oracle game. The attacker wants to sustain a mispricing for the settlement time. The gas fee per dispute must exceed the dispute profit , where is the percentage oracle price error and is the oracle liquidity. For simplicity, we avoid the cost of reporting in the dispute economics. The attacker’s total cost is:Dynamic programming analysis
Under censorship, the manipulator can report a wrong price and pay ePBS bribes to suppress disputes until suppression is no longer worth it. At that point, they can either let the round settle or self-dispute to refresh the game and repeat. Here, we investigate an unconstrained strategy where the attacker can choose report placement and refresh timing freely. This is exceptionally complicated, so we would invite anyone to correct any errors they see. The analysis should be treated as an approximation. Unless otherwise noted, assume the manipulator effectively controls inclusion and can always capture the dispute slot when choosing to refresh. Under this assumption, internal oracle game losses are abstracted away and the dominant tradeoff is external extraction versus censorship spend. This can be written as a single dynamic program on an augmented state:- Round index with game size
- Settlement timer (blocks remaining in the round)
- Settlement horizon (fixed blocks per round; is initialized at and counts down to 0)
- Raw reported-vs-true error in attack direction (fractional price error)
censor: pay for one block, evolve under unconditional price dynamics, and reduce timer .refresh: self-dispute, choose a new bad report , reset timer, and move to next round size .settle: settlement is only available at timer expiry ().
- Pick a round cap (for example, 80), a settlement horizon , and a list of for price evolution (positive and negative). Then define the attacker-choosable subset for attacker price reports (initial and refresh), where .
-
To handle price movements between blocks (the term above), build the one-block transition probability matrix on the same list of :
All this means is, for a given starting , what are the chances it evolves into other in the list over one block of time. This is how we account for the underlying distribution of returns.
- Fill settlement values for every round and every in the list: .
-
For rounds down to , for blocks remaining starting from to (backwards in time), and for each in the list:
Once we arrive at , we have a list of across all choices of . We first compute this list for , then , and so on: it is easy to calculate the used in the next round in the refresh step, since we have the list of values for the round after it:Here (and in the equation above), is just a scan over all allowed next-round report choices in , and the argmax picks the best one.
- We have enough information to continue until all are filled down to .
Numerical sweeps from this model
Unless otherwise noted:- Counterparty is passive.
- Attacker can choose the prices for the initial report and each refresh report from unconstrained attack-direction space.
- Per-block censorship cost is .
- Score is , reflecting initial report cost + bias extraction out of the notional in a single “cost” term.
- We report score in units, and optionally convert to percent using a 4% daily volatility assumption.
Settlement window tradeoff
For Gaussian increments, sweeping block count (same and grid):Bribe and control sensitivity
At , Gaussian, passive counterparty:Unique entity modeling
You could consider long-horizon bribery commitment infrastructure as a smart contract where validators can prove multiple keys are held by one entity, accept bribes, then be slashed in-contract if there is proof they included a forbidden transaction over the time window. We assume zero social slashing at the validator level. Alternatively, one could imagine an all-or-nothing contract where everybody is only paid if the attempt succeeds, without slashing. To approximate a unique entity bribery regime (rather than strict per-block bribery), a first proxy is to scale per-block censorship spend by an event compression factor:bribe_mult = 0.3).
This is a compressed payment proxy, not a full commitment game. It is best read as a stress shortcut for “fewer payable censorship opportunities” while keeping the same Bellman structure.
At , Gaussian increments:
Late counterbribes
If a defending party chooses to contest near the end of a round, their one-shot loss can be small relative to external notional. In one representative run (Gaussian, , , , , ), forward simulation under the optimal policy gave:- .
- .
- .