L2s Finally Flip the Switch on Permissionless Fault Proofs

The training wheels really are coming off

For years, optimistic rollups told users to trust that fraud would be caught. In practice, most systems ran with allowlisted validators and special guardians. That era is ending. On February 12, 2025, Arbitrum activated its BoLD dispute protocol on Arbitrum One and Nova, making validation permissionless on its flagship chains, with clear timelines and new guardrails for exits (Arbitrum BoLD upgrade details). On April 29, 2025, Coinbase’s Base said it had reached Stage 1, with permissionless fault proofs live and a decentralized security council empowered to approve upgrades (Base Stage 1 announcement).

These switches are not just symbolic. They change how withdrawals complete, how bridges manage risk, and how exchanges and custodians integrate rollups. They also set a new bar for the many OP Stack chains that make up the Superchain.

What changed, exactly

Fault proofs let anyone propose or challenge state roots for a rollup. Before 2025, most large optimistic L2s ran permissioned validators with backstops that could pause or override proofs. Two concrete changes landed:

Arbitrum’s BoLD is open by default. Any well funded and technically capable party can assert and defend the correct chain. The protocol sets explicit bounds so disputes resolve inside a fixed window. Arbitrum documents a default challenge period of about 6.4 days and notes that after upgrading to BoLD, withdrawals experience an additional challenge period. That increases total time to finalize withdrawals but removes the old risk that a malicious or failing validator could stall exits indefinitely.
Base formalized permissionless proofs and added a high quorum council. The council is large and geographically distributed. It can approve upgrades and act during emergencies, while day to day proving and challenging is permissionless.

The headline is not that proofs exist. It is that proofs are live in production on major L2s with operational details, economic incentives, and clear upgrade paths.

The new baseline from L2Beat

The community needed a way to tell when a rollup had truly reduced its trust assumptions. L2Beat’s Stage 1 criteria now set that baseline. The bar is higher than a demo proof and requires two essential pieces:

Permissionless exits. A proof system that lets users withdraw without help from a centralized operator. This includes open challengers and the ability to move ETH and tokens from L2 to L1 using only the onchain protocol.
A decentralized security council. At least eight members with a threshold of 75 percent or higher, capable of blocking unsafe upgrades. Stage 1 also enforces a multi day challenge window on optimistic systems to reduce censorship risk and give defenders time to act.

Put simply, Stage 1 means a single honest challenger plus a non captured council should be enough to keep withdrawals safe. You no longer need to trust a sequencer, a foundation, or an operator multisig to exit.

What changes for withdrawals

Withdrawals are where the rubber meets the road. The path to move funds from L2 to L1 now looks different in practice:

The user initiates a withdrawal on L2 and generates a proof tied to a specific state root.
That state root is posted to L1 by a proposer. Under permissionless systems, proposers are not allowlisted. Anyone who posts a wrong root risks losing their bond.
A challenge window opens. During this window, any party can challenge a bad claim. If a dispute starts, the protocol resolves it within a bounded time. On Arbitrum, the default challenge period is about 6.4 days. BoLD adds an additional period to the withdrawal flow, so integrators should expect longer total times to finality compared to pre BoLD operations. On OP Stack chains like Base, the system enforces a multi day window aligned with Stage 1 expectations, with a guardian delay and an open challenge game.
If no valid challenge succeeds within the window, the withdrawal can be finalized on L1.

Two consequences follow:

Worst case exit time is explicit. The slowest path is enforced by code rather than social coordination.
Integrators must monitor proofs. Wallets, bridges, and exchanges need to watch proposals and disputes, not just wait a fixed number of blocks.

What changes for bridges

Bridges now operate under different risk. The canonical bridge for each L2 becomes safer to rely on for delayed finality because anyone can defend it. Third party bridges that offer fast liquidity must adjust their risk models.

How incentives and timing interact:

With permissionless proofs, a bad withdrawal assertion can be challenged by any participant willing to run the software and post a bond. Bounty structures and bond slashing make it economically rational to challenge malicious claims.
Because dispute games are bounded, liquidity providers can cap the maximum time they are exposed to an unfinalized transfer. Some will shorten grace periods if they trust the new guarantees. Others will stick to conservative windows until more battle testing occurs.
BoLD lengthens the path for Arbitrum exits by adding another challenge period. That increases the time cost for providers who wait for L1 finality before settling internal accounting. Providers who underwrite fast exits will price the longer tail but may take comfort in the stronger do not get stuck guarantee.

Risk shifts from who is allowed to post and challenge to whether at least one honest actor will show up. For large chains, that is a comfortable assumption. For small appchains, it creates a need to cultivate external challengers and watchdogs.

What changes for exchanges and custodians

Exchanges and custodians care about predictable settlement. Until now, many relied on a mix of social trust and soft guarantees to accelerate credits. The new environment brings clarity:

Withdrawal windows are permissionless and bounded. Operations teams can codify risk thresholds tied to proof states and challenge timers, reducing one off exceptions.
Monitoring must become active. Teams should track L1 dispute contracts, not just L2 confirmations. Alerting on proposals, challenges, and resolutions becomes standard.
Security councils matter. During emergencies, a council can pause, revert, or force upgrades. Custodians need playbooks for council actions, including when to halt credits during guardian delays.

If your team is also contending with regulatory and reporting shifts, see our coverage of the 2025 crypto reporting reset for how back office policies intersect with new settlement flows.

What changes for security councils

Stage 1 puts the council at the center of responsible upgrades without giving it routine control over exits. The operational implications are concrete:

Council size and quorum. Councils need at least eight members and a 75 percent threshold so no single operator or friendly minority can push through an unsafe upgrade.
Quorum blocking outside the operator. A council must include members not controlled by the core team or parent company.
Clear scope. Councils intervene for bugs or emergencies, not for day to day state proposals, withdrawals, or dispute games.

Base’s council illustrates this direction. It includes independent entities and individuals, plus Optimism and Coinbase, and requires a high quorum to sign upgrades. That structure gives builders a credible safety valve while keeping proof systems open.

The Superchain effect

Optimism’s OP Stack is becoming a standard. OP Mainnet enabled permissionless fault proofs in 2024. Base reached Stage 1 in April 2025. Other OP Stack chains are upgrading to the same proof system and governance patterns. The benefit of standardization is simple. When a single stack defines dispute contracts, monitoring patterns, and guardian delays, integrators can reuse tooling and playbooks.

Expect a staggered rollout across the Superchain. Chains that stick close to the reference configuration will move faster. Chains that modify the stack will need more testing and audits. For a view of how performance innovations are reshaping L2 design, see Unichain 200ms Flashblocks.

Who benefits and who loses

Some parties gain immediately. Others lose the edge they held in a permissioned world.

Winners

Users and developers. Withdrawals are permissionless, bounded, and no longer reliant on a foundation’s goodwill. Builders can deploy with clearer assumptions about exit safety.
Watchdogs and challengers. There is an open market to run challengers and earn bounties when defending the chain. Expect specialized firms to offer this as a service.
Risk teams at exchanges and custodians. Proof states and challenge windows are machine readable, which makes formal policies easier to write and audit.
Canonical bridges. The trust model improves, making them safer for delayed settlement without off chain relationships.

Pressured to adapt

Fast bridge middlemen who relied on soft trust and private deals. Open, bounded proofs reduce the value of privileged relationships.
Appchains that cannot attract external challengers. The model assumes at least one honest actor shows up, so small chains must invest in incentives and community operations.
Operators who used pausing powers too freely. Unlimited pauses or opaque interventions will be frowned upon and may lead to a downgrade by indexers and venues.

For the broader market backdrop that shapes institutional demand, see our take on SEC generic ETF standards.

Practical guidance for teams integrating L2s

If you operate a bridge, wallet, or exchange, use this checklist to update your runbooks:

Track the right contracts. Monitor the dispute factory, portal, and any guardian or council timelock contracts. Alert on new proposals, challenges, resolutions, and any guardian toggles.
Align settlement timers with proof states. Replace fixed block confirmations with logic that waits for the relevant challenge window to pass without successful disputes. On Arbitrum, include the extra period added by BoLD to withdrawals. On OP Stack chains, include the guardian delay and any additional grace periods defined in the stack.
Build a challenger or partner with one. Run a challenger in house or contract a reputable provider so you can defend customer withdrawals if needed.
Document council playbooks. Define when to pause deposits or withdrawals, how to resume, and how to communicate changes during a council led intervention.
Test on testnets and sandboxes. Rehearse disputed withdrawals and recovery paths. Make sure dashboards surface the right signals to on call staff.

What to watch next

More OP Stack chains flipping to Stage 1 as proofs and councils standardize.
Arbitrum’s path to Stage 2. With BoLD live, attention shifts to reducing council powers and hardening the stack.
Multi proof deployments that further cut reliance on councils. Expect early testnets to inform mainnet timelines.
L3s and appchains that adopt BoLD patterns while investing in external challengers.

The bottom line

Permissionless fault proofs are finally in production on the L2s that matter. Arbitrum and Base flipped the switch, and the operational world changed with them. Withdrawal flows are now open and bounded. Bridges can rely more on protocol guarantees and less on social trust. Security councils have clear thresholds and a tighter scope. As OP Stack chains roll this out across the Superchain, Stage 1 becomes the new minimum for credible L2s. The winners will be the teams that operationalize these changes fast and build for a world where exits are code enforced guarantees.