When Fraud Proofs Are Never Submitted

Every user assumes someone else will submit fraud proofs, creating a classic tragedy of the commons. The economic incentive to be the sole challenger is often misaligned.

• Cost-Benefit Mismatch: Challenging requires technical expertise and capital for the bond, but the reward is shared by all users.
• Passive Security: The system's safety depends on altruism or specialized watchdogs, not protocol-enforced guarantees.

If sequencers withhold transaction data, fraud proofs are impossible to construct. This turns a liveness fault into a safety failure, allowing theft of the entire bridge TVL.

• Blind Challenges: Verifiers cannot prove fraud without the underlying data posted to L1.
• Window of Risk: The 7-day challenge period becomes a multi-day opportunity for a malicious sequencer with data control.

The entities with the capability to submit fraud proofs—often large stakers or the rollup team itself—can be bribed or coerced into silence. Decentralization of challengers is critical.

• Bribe > Bond: A malicious actor can profit by bribing potential challengers with a share of the stolen funds, exceeding their bond reward.
• Centralized Watchtowers: Reliance on a few branded services (e.g., Chainlink FSS) re-centralizes the security model.

Arbitrum's design includes a last-resort escape hatch: users can force-include transactions via an L1 pre-compile contract if the sequencer is censoring. This is a mitigation, not a solution.

• User-Activated Security: Puts the burden on the victim to act within the challenge window, requiring L1 gas and sophistication.
• Proves the Point: The need for this mechanism highlights the inherent fragility of the optimistic security model under adversarial conditions.

Validity proofs (ZKPs) eliminate the liveness assumption by mathematically verifying state correctness. Security is cryptographic, not economic or social.

• No Challenge Period: Funds are instantly withdrawable upon proof verification on L1.
• Data Availability Remains: ZK-rollups like zkSync and Starknet still require data posting, but safety doesn't depend on it.

Emerging designs like Espresso Systems' shared sequencer with attestation bridges or EigenLayer-restaked watchdogs attempt to institutionalize the challenger role. The endgame may be enshrined validation at the L1 protocol level.

• Professionalized Challengers: Creating explicit economic roles and rewards for proof submission.
• Protocol-Enforced Liveness: Moving the watcher function into the consensus layer itself, as envisioned by Ethereum's PBS and Danksharding roadmap.

A malicious sequencer can censor or delay transactions, knowing the cost to challenge them is prohibitive. The 7-day challenge window becomes a weapon, not a shield.\n- Attack Cost: Minimal for sequencer.\n- Defense Cost: Potentially millions in gas for a full-state proof.\n- Result: Censorship-as-a-Service becomes viable, undermining liveness guarantees.

If a majority of stake is controlled by a cartel (e.g., top validators/sequencers), they can collude to never challenge each other's fraud. The system's security collapses to a permissioned, trusted model.\n- Threshold: >33% stake for liveness failure, >66% for safety failure.\n- Real-World Precedent: Echoes of Tendermint-style governance attacks.\n- Result: The rollup regresses to a high-cost sidechain with extra steps.

Submitting a fraud proof is a public good with asymmetric cost. The prover pays full gas, while benefits are distributed to all users. Rational actors free-ride, leading to proof underproduction.\n- Free-Rider Dynamic: Classic tragedy of the commons.\n- Mitigation Attempt: Projects like Arbitrum use bonded challengers, but this centralizes risk.\n- Result: Security depends on altruistic or specially-incentivized actors, a brittle assumption at scale.

Fraud proofs require the disputed transaction data to be available on L1. If that data is withheld (a Data Availability attack), proofs are impossible. This makes the rollup's security contingent on the DA layer.\n- Primary Dependency: Ethereum calldata, Celestia, EigenDA.\n- Consequence: A successful DA attack on any major provider bricks all dependent optimistic chains.\n- Result: Introduces a systemic risk layer beyond the rollup's own design.

A critical bug in the fraud proof verification contract itself could make valid proofs fail or, worse, allow invalid state transitions. The upgradeability mechanisms of rollups (often controlled by a multisig) become the ultimate security bottleneck.\n- Attack Surface: Complex interpreter logic and cryptographic primitives.\n- Historical Context: The Optimism bug (2021) required a guardian pause.\n- Result: The entire cryptoeconomic security model is backstopped by social consensus and admin keys.

This entire category of failure is why ZK rollups (e.g., zkSync, Starknet, Scroll) are winning the security argument. Validity proofs provide cryptographic finality in minutes, not days, eliminating the fraud proof game theory.\n- Key Shift: Security moves from economic incentives to cryptographic verification.\n- Trade-off: Higher computational cost, but rapidly decreasing.\n- Result: The long-term architectural trend is clear: ZK for security, OP for simplicity (initially).