Arbitrum BOLD and Optimism Fault Proofs: Mainnet Progress

Permissionless fault proofs let any participant — not just a whitelisted set of validators — submit a challenge disputing an incorrect state claim on an optimistic rollup, and their arrival on Arbitrum (via a system called BOLD) and Optimism mainnet marks a significant step in closing the gap between these rollups' marketed security and what was actually enforced on-chain for most of their history.

Understanding why this matters requires being honest about a detail that often got glossed over in earlier optimistic rollup marketing: for years, fraud-proof systems on major optimistic rollups existed in code but were not fully live and open to anyone on mainnet. In practice, a small, permissioned set of validators — often controlled or vetted by the core team — were the only parties actually able to submit fraud proofs, meaning the theoretical security model and the practical, deployed security model weren't the same thing.

Why fraud proofs weren't permissionless from day one

Building a fraud-proof system that's both efficient and safe against griefing (spamming false challenges to waste resources or delay withdrawals) is a genuinely hard engineering problem. Early designs often used a single, simple dispute game that could be manipulated by an attacker willing to spend enough on gas or delay tactics, or that couldn't scale to handle many simultaneous disputes without opening new attack surfaces. Teams reasonably chose to launch with a restricted, trusted set of validators as an interim safety measure while the permissionless version was engineered and tested — a trade-off usually disclosed as "training wheels," though not always emphasized to casual users.

What changed with Arbitrum's BOLD

BOLD (Bounded Liquidity Delay) is Arbitrum's permissionless fraud-proof system, designed to let any party — using only bonded funds, not a whitelist — participate in the multi-round dispute process that resolves disagreements about a rollup's state. Its dispute game structure is built specifically to bound the time and cost of resolving a challenge even when many parties participate, addressing the scalability and griefing concerns that motivated the original permissioned design. Its mainnet activation was a meaningful milestone specifically because it removed the "trusted validator set" as a single point of failure from Arbitrum's security model.

What changed with Optimism's fault-proof mainnet launch

Optimism's fault-proof system underwent a similar maturation, moving from a permissioned validator model toward a permissionless one where any party can participate in disputing an incorrect state claim, backed by a dispute game design intended to resolve challenges efficiently on-chain. As with Arbitrum, this shift was specifically about closing the gap between "the code supports fraud proofs" and "anyone can actually use them on mainnet without special access."

Why this matters for users and developers

• Removes a centralization dependency. Previously, users implicitly trusted that the permissioned validator set would actually notice and challenge fraud — a reasonable bet given the reputational stakes involved, but still a trust assumption rather than a trust-minimized guarantee.
• Strengthens the claim that these rollups "inherit Ethereum's security." As covered in our piece on how L2s inherit Ethereum's security, the fraud-proof mechanism is the actual enforcement layer — permissionless proofs make that enforcement real rather than theoretical.
• Doesn't eliminate the challenge period. The roughly seven-day withdrawal delay on optimistic rollups is unaffected by who can submit a proof — it's a separate design choice about giving enough time for any proof to be constructed and submitted.

Era	Who could submit a fraud proof	Practical security model
Pre-permissionless launch	Whitelisted/trusted validator set	Relies on trusted parties acting honestly
Post-permissionless launch (BOLD / OP fault proofs)	Any party with sufficient bond	Trust-minimized — anyone can enforce correctness

What to watch going forward

Permissionless fault proofs are a major milestone, not a finish line. Areas still worth monitoring on any specific optimistic rollup: how decentralized is the sequencer itself (a separate question from fraud proofs, since a censoring sequencer is a different risk than an incorrect one); how battle-tested is the dispute game design against real adversarial activity, not just testnet simulation; and whether a Security Council or upgrade key retains override power that could bypass the fraud-proof outcome in some scenario. These questions apply across the broader optimistic rollup landscape, not just to Arbitrum and Optimism specifically.

Bottom line

The move to permissionless fault proofs on major optimistic rollups is one of the more consequential, if under-discussed, security upgrades in the L2 space — it's the difference between a rollup's security model being enforceable by anyone and being enforceable only by a trusted few. When evaluating an optimistic rollup, check specifically whether its fraud-proof system is live and permissionless on mainnet, not just present in the codebase, before treating its security claims as fully realized.