Who Pays to Watch: The Unpriced 1-of-N Honesty Assumption in Optimistic Rollup Fraud Proofs

The assumption stated as safety, operated as a budget

Optimistic rollups are usually described as inheriting Ethereum’s security because anyone can challenge an invalid state transition during a challenge window. Ethereum’s developer documentation puts the mechanism plainly: batches are assumed valid unless someone disputes them, and after the challenge period elapses without a successful challenge, the batch is treated as accepted. The same documentation notes that data availability is critical because without access to state data, challengers cannot construct fraud proofs.

The conditional part is often compressed into a single phrase: the 1-of-N honest assumption. One honest participant, out of N possible watchers, must be able and willing to monitor the rollup and challenge bad assertions. If no honest node checks execution, a malicious operator can post an invalid state transition, let the window expire, and the base chain will not re-execute the batch by default.

That framing is correct but incomplete. “Able and willing” is not a property that exists in the abstract. In a deployed fault-proof system it resolves to a funded operator with a synced node, a trace provider, archival data access, and enough bonded capital to play a dispute game to its end. The protocol spec states the safety condition; the implementation documentation describes the cost of satisfying it. The gap between those two descriptions is where the unpriced assumption lives.

Two roles, not one

Discussions of fraud proofs often collapse the asserter and the challenger into a single “validator” role. They are distinct, and their economics are asymmetric.

The asserter, or proposer, posts output roots and attaches a bond. If the claim is invalid and successfully countered, the bond is at risk. The challenger monitors games, defends valid proposals, and counters invalid ones. In the OP Stack, op-challenger is the honest actor implementation: it relies on a synced, trusted rollup node and a trace provider such as Cannon to verify claims, and it posts counter-claims when its node disagrees with a proposed output root.

That is an operated role, not a passive observer. The challenger must run infrastructure, hold funds, and act inside deadlines. The documentation is explicit that the honest challenger “is willing to put its money on the line” to counter faults. A spec review that treats “someone will challenge” as a free safety property is reading the safety condition without the operational clause attached to it.

The bond is the visible cost, and it is not small

Each claim in an OP Stack fault dispute game requires a bond, including the root claim created when the game starts. Every subsequent claim posts an additional bond scaled by the depth of the claim. The bonds are not prepaid like a stake; they are sent as transaction value when calling attack, defend, or create.

The documentation gives a concrete figure for playing a single game to the final step: just over 631.2 ETH in total, about 315.6 ETH per side. That number is a protocol parameter, not a market estimate, and it should be read as the capital a challenger must be prepared to commit to one dispute. It does not include gas for each move, node operation, or the opportunity cost of locked capital during the resolution and withdrawal delays, which the docs describe as at least 12 hours each by default and up to 3.5 days and 7 days respectively.

The more consequential line is a coordination requirement rather than a per-actor one: the combined funding of all honest actors must exceed the funding available to an attacker. Otherwise the attacker can post claims faster than honest actors can counter them. A single challenger holding exactly the minimum bond for one game satisfies a naive reading of “1-of-N” while failing the condition the documentation actually states. The security claim depends on a funded coalition, not on the existence of one watcher.

Data access is a challenger-side dependency

Data availability is usually discussed as a property the settlement layer provides. The challenger documentation shows it is also an operational dependency on the watcher’s side. An honest actor without a blob archiver can be pushed into a losing position if a disputed block is older than the blob retention period, roughly 18 days. The docs describe the scenario: if the only honest actor lacks a blob archiver and is pushed about 32 claims deep, the challenger logs errors and cannot respond without archival access. The actor then has about 3.5 days on their side of the game clock to switch to a beacon node that has the blobs.

This is a useful test case for spec review. The protocol’s data-availability guarantee is necessary but not sufficient; the challenger must also be able to retrieve historical data on demand. A deployment where the only honest challenger runs a pruned node is not obviously secure, even though the L1 data was published. The recovery path exists, but it is time-bounded and depends on the operator noticing the failure and having an alternative data source ready.

What the incentive literature says about watching for free

The incentive-compatibility literature is worth reading alongside the implementation docs because it isolates the assumption that monitoring is costless. In a stylized model of optimistic rollups, Landis (arXiv:2312.01549) shows that when the aggregator behaves honestly, the validator’s expected utility is zero. The paper asks the obvious follow-up: why would a validator participate at all? It then introduces a search cost, the cost of actually checking whether the aggregator was honest, and analyzes how that changes the equilibrium.

The model is stylized and should be cited as such; it is not a measurement of any deployed system. But the diagnostic is useful. If the direct payoff from the dispute game is zero in the honest case, participation must be motivated by something outside that payoff: protocol interest, node access, explicit payment, or the fact that a frequent user wants assurance about their own transactions. A spec reviewer should ask what that something is for each deployment rather than assuming the bond reward is sufficient. The bond reward only pays when fraud occurs; the monitoring cost is paid every block.

The public-good problem the protocol does not price

Here the argument moves from sourced description to reasoning. The availability of a challenger is a public good for everyone using the rollup. Users and bridge liquidity providers benefit from the fact that an invalid root would be contested, but the bond, gas, archival storage, and liveness costs fall on the challenger. The protocol does not have a line item that pays for watching; it assumes the watching happens.

That is a free-rider structure. Each individual user has little incentive to run a challenger, because the benefit of their challenge accrues to all users while the cost accrues to them. The documentation’s answer is partly economic (bonds and rewards) and partly institutional (the guardian can intervene and reallocate bond payments if an attacker tries to outspend honest actors). The institutional backstop is real, but it is also a trust assumption layered on top of the 1-of-N assumption. A spec review should record both.

A worked example, clearly hypothetical

Consider a deployment with one independent challenger funded for exactly one game at the documented per-side figure, and an attacker willing to open several games concurrently. The challenger can play one game to completion. The attacker’s claims in the other games go unanswered unless additional funded actors appear. The documentation’s condition, that combined honest funding exceed attacker funding, is not met, even though the deployment can truthfully say an honest challenger exists.

This is not a claim that any named rollup is in this position. It is a demonstration that “1-of-N” is ambiguous between “at least one honest actor exists” and “honest actors collectively outfund the attacker.” The first is a safety slogan; the second is the operating condition. The distance between them is the unpriced cost.

Resolution liveness is also assumed

The dispute game does not put a time cap on resolution. The documentation states that because of the liveness assumption on honest challengers and the bonds attached to countered claims, challengers are economically motivated to resolve games quickly and claim their funds. That is a reasonable design, but it is another place where the protocol relies on an operator behaving promptly rather than on a contract-enforced deadline. A challenger that wins a game and then goes offline leaves bonds unclaimed and games unresolved. The incentive is there; the enforcement is not.

Questions a spec reviewer should ask

The point of this review is not to argue that optimistic rollups are insecure. It is to make the conditional security claim auditable. For any deployment, the following questions have concrete answers or they do not:

• What is the challenger’s all-in cost per game, including bond, gas, archival data, and locked-capital time?
• Who funds the challenger, and is that funding committed for the full resolution and withdrawal delay?
• How many independent challengers exist, and does their combined funding exceed a plausible attacker’s?
• Does every challenger have blob archival access, and what is the recovery path if the only one does not?
• What motivates monitoring in the honest case, when the dispute game pays nothing?
• How is the 1-of-N assumption audited over time rather than asserted at launch?

The 1-of-N assumption is not wrong. It is a precise statement about a role that costs money to fill. Treating it as a free property of the settlement layer is the error. The protocol specifies who may challenge; it does not specify who pays to watch. Until that line item appears somewhere, the security claim is conditional on a budget that no one has written down.

FAQ

Does the 1-of-N assumption mean one challenger is enough?

Not according to the OP Stack documentation. The stated condition is that the combined funding of all honest actors must exceed the attacker’s funding. One challenger with the minimum bond for one game satisfies a literal reading of “one honest actor” but not the documented funding condition.

Is the bond the main cost of running a challenger?

The bond is the most visible cost. The documentation gives just over 631.2 ETH for a full game, about 315.6 ETH per side, plus gas per move. Node operation, archival data access, and locked-capital time during resolution and withdrawal delays are additional costs that the bond figure does not capture.

Why does data availability matter to the challenger specifically?

Because a challenger without blob archival access can be pushed into a position where it cannot respond. The documentation describes an honest actor lacking a blob archiver being unable to continue once a disputed block is older than the roughly 18-day blob retention period, with about 3.5 days on the game clock to recover.

Does the incentive literature show that challengers will not participate?

It shows that in a stylized model, the validator’s expected utility is zero when the aggregator is honest, and it introduces a search cost to analyze participation. That is a diagnostic about the model’s assumptions, not a measurement of deployed challenger counts.