Training Wheels Off: Permissionless Proofs Hit L2s

The moment that changes everything

Two milestones just moved Ethereum’s Layer 2 world from theory to practice. Arbitrum turned on BoLD, a permissionless, time‑bounded fault proof system on Arbitrum One and Nova. See the design overview in the Arbitrum BoLD introduction.

Soon after, Base crossed the threshold to Stage 1 in April 2025, which formalizes permissionless fault proofs and decentralizes upgrades behind a security council. Base detailed the change in its post, Base has reached Stage 1 decentralization.

If you have tracked optimistic rollups for years, these two changes flip the default. Before, users relied on appointed actors to post or contest claims about L2 state. Now, anyone can. That shift unlocks real impacts for withdrawals, bridges, app security, and the policies of exchanges that must manage risk at scale. For additional context on how sequencing is decentralizing in parallel, see how shared sequencers go permissionless.

What permissionless fault proofs actually do

Think of the L1 blockchain as a courtroom that does not know what happened on the L2. Optimistic rollups post compressed evidence to L1, then open a window for anyone to challenge an L2 state claim. Fault proofs are the cross‑examination.

On Arbitrum, BoLD requires disputes to complete within a fixed upper bound, roughly one to two challenge periods, instead of being dragged out by sequential one on one delay games. That removes a key stalling attack that could indefinitely delay withdrawals.

On the OP Stack, the permissionless system uses a modular Dispute Game plus a Fault Proof Program and a Fault Proof Virtual Machine known as Cannon. Cannon compiles the rollup’s state transition logic into MIPS instructions so that, after a narrowing process, a single instruction step can be checked onchain to determine who is correct. Anyone can propose outputs and anyone can challenge them. The user property that matters most is the same in both families: permissionless exits to Ethereum when the timer has run.

The next 3 to 6 months: how user risk really changes

Here is what permissionless withdrawals and anyone‑can‑challenge security mean for people who hold assets and build apps on major L2s.

Exiting becomes an engineering task, not a social favor. Users no longer rely on an allowlisted validator to finalize withdrawals. The risk that an offchain actor refuses to cooperate is replaced by the requirement that at least one honest participant monitors and challenges. On Arbitrum, BoLD also caps the maximum delay for a disputed assertion, so worst case exits are bounded rather than indefinite. Expect wallets and bridges to surface clearer countdowns that reflect a two‑part timeline: the challenge window and the resolution window.
Bridge trust models converge toward the canonical path. When exits are both permissionless and time‑bounded, most rational users will favor the native bridge for final settlement, with fast bridges used primarily for liquidity convenience. Fast bridges can still advance funds instantly, but their risk engines should track a clear ceiling on how long capital is at risk during a dispute.
Watcher economics matter. Because challengers and proposers must post bonds, the cost of participation will shape who actually defends the chain. Expect professional watchers to form pools that share capital and automate response playbooks. For users, security depends less on founding teams and more on a market of independent verifiers that compete on speed, reliability, and bond efficiency.
The Security Council is still in the room. Stage 1 keeps a last‑resort lever for major bugs. On OP Stack chains this fallback can temporarily re‑permission the system; on Arbitrum BoLD there is a short grace period during which the council can intervene. Users should treat Stage 1 as strong progress, not finality nirvana.

For broader performance context as L2s scale, see how PeerDAS cuts L2 fees.

Bridge design in a post training wheels era

Bridges will refactor around four concrete changes.

Withdrawals are now credibly neutral. Canonical bridges can claim their finality does not depend on any named multisig or company. Fast bridges should disclose their net exposure during the challenge period and how they hedge it. BoLD makes that window deterministic up to a bound, letting risk desks set value at risk limits without hand waving around infinite delays.
Proof upgrades are operational events. On OP Stack chains, upgrades to the proof system can temporarily invalidate proofs in flight. Bridge operators need runbooks for halting proofs ahead of the change, draining pending messages, and reproving after activation. Users will occasionally see banners warning of longer than usual finalization. This should be rare, but it is expected as fault systems iterate.
Liquidity networks adapt to bounded risk. With a reliable maximum horizon on disputes, fast bridges can price advance fees more tightly. Expect market makers to lever capital more confidently and compress spreads during quiet markets, while widening during system upgrades or when onchain volatility spikes.
Monitoring becomes a product. The best bridges will run their own challengers, ship real time dispute dashboards, and expose machine readable feeds that alert on every L2 output proposal, challenge, and step of the dispute game. That reduces blind spots for custodians and lets sophisticated users automate their own risk responses.

Exchanges and custodians: policy updates to make now

Large venues will not rewrite everything overnight, but the next quarter should bring visible changes if they want to compete on user experience without compromising safety.

Credit deposits on L2 faster, based on L1 inclusion plus a minimal buffer. For tokens bridged natively, credit once the L2 batch that contains the deposit is posted to Ethereum and reaches the venue’s usual L1 confirmation threshold. For tokens bridged via third parties, treat the bridge’s own finality rules as the bottleneck. Publish token by token rules so users do not guess.
Withdrawals should reflect real challenge mechanics. For OP Stack chains at Stage 1, once a user proves a withdrawal on L2 and submits to L1, the venue should not add extra human approvals beyond fraud proof finalization. For Arbitrum, the BoLD timeline is capped; internal ledgers can reflect that upper bound rather than applying indefinite holds. Build playbooks for the rare case of a successful challenge that invalidates a withdrawal proof and requires resubmission.
Run an in house challenger or contract with one. If you custody significant assets on an L2, operate an independent watcher that will automatically contest invalid outputs. Treat this like running your own validator or light client in other ecosystems. It directly reduces tail risk that stems from relying on others to act.
Track and disclose Security Council powers. Maintain a registry of each chain’s emergency powers and thresholds. For Base, that includes its Security Council membership and quorum; for Arbitrum, the grace period and emergency levers that might pause finality. If a chain widens emergency powers, tighten risk limits until controls normalize.

OP Stack vs Arbitrum: two designs, one destination

Both families now offer permissionless withdrawals and anyone‑can‑challenge security, but they arrive there by different routes.

OP Stack: modular and multiproof ready. The dispute game separates three pieces. The Fault Proof Program derives L2 state, the Fault Proof Virtual Machine executes the program deterministically, and the Dispute Game narrows disagreements to a single step that can be checked onchain. Cannon is today’s FPVM, based around MIPS, with proposals under discussion to expand to 64 bit and multi threading. This design is intentionally swappable so that future systems, including zero knowledge proof variants, can slot in.
Arbitrum: time bounded, parallel defense. BoLD reforms the challenge protocol so that one honest validator can defend against many adversaries in parallel and still finish within a fixed maximum time. Confirmation is no longer subject to a series of sequential one to one games. The upside is a clear bound on exit delays; the tradeoff is higher bond sizes for proposers and challengers, which can concentrate who plays the game unless pools form.
Stage 1 today is not Stage 2 tomorrow. Both designs still retain emergency powers in Stage 1, which is by design a safety valve. Stage 2 asks for stronger properties, including the idea that no one can push an invalid message or block an honest withdrawal without breaking the onchain rules, plus stricter limits on emergency governance. That sets the next target for the roadmaps.

The Stage 2 race: multiproof nirvana

The best mental model for Stage 2 is client and proof diversity. You want multiple independent ways to demonstrate the same truth, so that a bug in one path does not threaten exits. The OP Stack is explicitly designed for this future. Its preimage oracle and Dispute Game can host alternative virtual machines and programs, including a RISC V variant of Cannon or even a zero knowledge proof that attests to the MIPS step.

Arbitrum’s path focuses on fully normalizing BoLD on mainnet, then growing diversity in who runs validators and challengers and how they are implemented. BoLD’s constant time property is already a strong economic base for third parties to offer watch services and capital pools. Over the next 3 to 6 months, expect ecosystem level steps rather than dramatic protocol rewrites: more independent validators, hardened monitoring, and maturity in bond markets that lowers barriers for smaller security operators to participate. For how app developers adapt their stack as throughput rises, see Uniswap v4 on fast blocks.

Builder checklist for choosing an L2 after the training wheels

Use this practical list when you pick a home for your app or liquidity.

Exit path guarantees. What is the current challenge window and, if disputed at the last moment, what is the maximum additional delay? Verify whether the proof protocol is time bounded. If you cannot compute a worst case, treat the chain as Stage 0 in your own risk model.
Proof system maturity. Is the proof system permissionless in production or gated behind allowlists? How often have there been proof system upgrades that required reproving withdrawals, and how are such events communicated to users and integrators?
Security Council powers. What emergencies can the council handle? Can it pause or re permission the proof system? What is the quorum and membership rotation schedule? Note concrete dates for term renewals.
Challenger ecosystem. How many independent organizations run challengers today? Are there grants, bounties, or bonds that incentivize more? Does the chain publish a public dashboard of recent disputes and outcomes?
Client and proof diversity. On OP Stack chains, ask which FPVM and program are live and whether alternatives are on testnet. On Arbitrum, track independent validator clients and third party challenge tooling. Stage 2 will require redundancy in these components.
Bridge invariants. If your app depends on fast exits, can you degrade to canonical exits without breaking user funds flow? Confirm how your providers respond to proof system upgrades that invalidate in flight proofs.
Operational transparency. Does the L2 publish upgrade calendars, incident retrospectives, and a live feed of L2 output proposals and disputes? Can you subscribe programmatically and alert your users before an upgrade window?
Cost and performance envelope. If your app needs high throughput, remember that proof systems themselves must handle bigger blocks. Ask about planned upgrades, such as 64 bit Cannon or equivalents. Build realistic fee simulations that include worst case dispute participation.
Token and asset risk. Native bridge semantics are safer under permissionless proofs, but app specific risks still exist. If your users depend on externally bridged assets, model the trusted parties in those bridges as part of your threat surface.

What this means right now

Arbitrum’s BoLD and Base’s Stage 1 push the industry past the era where friendly operators had to vouch for users. The near term reality is more practical than flashy. Your withdrawals are still not instant, but the delay is now bounded by code. Your exits are no longer favors, they are rights you can enforce. The most important work will happen in the corners of operations where validators, challengers, bridges, and exchanges automate away human bottlenecks.

If you build or custody on L2s, act on the concrete items above. If you are a user, expect bridges to look simpler and exchange withdrawal policies to get clearer. The training wheels did their job. Now the ride gets faster because the frame is stronger, not because the hills got smaller. That is the right kind of progress.