Anyone Can Challenge: OP Fault Proofs and Arbitrum BoLD

Breaking shift: from allowlists to anyone-can-challenge

Two of the most used Ethereum rollup stacks just took a decisive step toward real trust minimization. Arbitrum activated BoLD on mainnet at 09:00 ET on February 12, 2025, introducing permissionless validation where anyone can challenge incorrect state and force resolution within a bounded time window. That change affects how withdrawals finalize, how bridges and centralized exchanges model risk, and how decentralization guarantees are communicated to users and partners. It is not just a new feature. It is a new operating assumption for rollups. See BoLD adoption details.

On the Optimism side, the OP Stack enabled permissionless fault proofs on OP Mainnet on June 10, 2024. That upgrade allows anyone to propose and challenge state roots used to prove withdrawals, removing the need for a trusted third party in the withdrawal path. Read the OP fault proof explainer.

Think of it like this. A rollup is a train whose final stop is Ethereum. Before, only a few conductors with special keys could pull the emergency brake if something looked wrong. Now, any passenger who knows the rules can pull the brake and a referee will adjudicate on Ethereum who is right. That single change reshapes incentives for builders and confidence for users.

What permissionless fault proofs actually do

A fault proof is a way to prove on Ethereum that a claim about the rollup state is wrong. Under an optimistic rollup, the system assumes state claims are valid unless someone challenges them within a dispute window. Permissionless means any honest party can initiate that challenge and win if the state claim is invalid.

Arbitrum’s BoLD adds two critical properties that were missing from the earlier model:

Time-bounded resolution. Disputes finish within a fixed upper bound. You do not get stuck in a loop of serial one-versus-one challenges where a malicious actor keeps stalling. BoLD turns the dispute into a parallel, all-vs-all game with a timer.
Open participation. Any entity that posts the required bond can become a proposer or challenger. That openness removes the social fragility of allowlists and moves the system closer to pure protocol guarantees.

On the OP Stack, permissionless fault proofs similarly open the door for anyone to propose outputs and challenge others, and the withdrawal path no longer relies on an operator’s benevolence. The result is the same end-user property across both stacks: a single honest participant can force correctness.

Here is the plain-language impact:

If someone posts an invalid rollup state to Ethereum, anyone with the correct view can challenge it within the window and win. The loser’s bond is slashed. The chain continues operating while the dispute plays out. Your transactions are not blocked.
If no one challenges a valid assertion during the window, it is confirmed and can be used to finalize withdrawals. There is no hidden trust lever in the middle of that process.

Withdrawals: slower only on paper, safer in practice

Users often ask one question first. Will this make my withdrawals slower? The practical answer is that the withdrawal delay is clearer and, in adversarial cases, safer.

On Arbitrum today, the typical delay to finalize an assertion and therefore complete a standard withdrawal is about 6.4 days. BoLD is designed so that even in a dispute, finality occurs within at most two challenge periods plus a small delta, making delay attacks uneconomic and bounded.
On OP Stack chains, the new system lets users exit without a trusted party. The delay you see in your wallet is a security parameter, not a central operator’s queue time. If a chain’s governance extends or shortens the window, it must tell you up front, because that window is what protects your right to exit.

One gotcha for operators migrating to BoLD or upgrading OP Stack chains: pending withdrawals that are mid-flight when you flip the switch can be delayed by an extra challenge period. Plan your communications and status pages accordingly so users are not surprised by a reset of the timer.

Bridges and exchanges: risk models update

Permissionless fault proofs change who bears what risk, and when. That ripples through bridge contracts, exchange listings, and deposit crediting policies.

Canonical bridges become more credible. If anyone can challenge invalid outputs, a canonical bridge anchored in the rollup’s contracts is safer to use without relying on a federation or offchain relayers. The path from L2 to L1 goes through a rulebook, not an allowlist.
Third party bridges can reduce bespoke trust assumptions. Many third party bridges used fast-withdrawal liquidity providers to front funds while waiting for the challenge window. With anyone-can-challenge, the remaining risk is mostly the parameterization of the window itself and the smart contract risk of the bridge, not an opaque validator committee.
Centralized exchanges can revisit credit policies. Some exchanges historically credited deposits from L2s sooner than strict finality, based on relationships with operators. Under permissionless proofs, exchanges can align crediting strictly to onchain finality or to conservative heuristics tied to the challenge window. That improves consistency across assets and reduces the need for case-by-case exceptions.

A concrete example: an exchange can choose to credit Arbitrum deposits only after the assertion covering the deposit is outside the challenge window, or it can risk-budget partial credit earlier with an internal cap. The same exchange might set a different policy for an OP Stack chain with a longer or shorter window. The key is that the logic is transparent and derived from protocol rules, not from who runs the sequencer.

Decentralization guarantees: what Stage 1 to Stage 2 means

The ecosystem uses a simple mental model for rollup maturity: Stage 0, Stage 1, Stage 2. At the risk of oversimplifying, here is a practitioner’s translation.

Stage 1: the training wheels are lighter. There is a functioning proof system and users can exit trustlessly, but a security council or similar actor can still override the system in emergencies. Upgrades usually have a short delay. Permissionless challenge is present, but social levers exist for safety.
Stage 2: the training wheels come off. The fraud proof system is fully permissionless. Users get a long exit window for unwanted upgrades, commonly at least 30 days. Any security council is tightly scoped to onchain detectable bugs and cannot override correct code outputs. No small group can push an invalid state, even unanimously, if the code is bug free.

Where do the stacks stand today? Arbitrum’s BoLD was designed to make permissionless validation time bounded and predictable, which is a major Stage 2 ingredient. OP Stack’s permissionless fault proofs and recent governance hardening moved OP Chains to Stage 1 with a clear path to Stage 2. The remaining work for both families is less about writing one more proof and more about wrapping the proof system in governance that respects long exit windows and removes discretionary override powers except for verifiable bugs.

If you are a builder, do not chase labels. Map your own guarantees. Can a single honest party force correctness? How long is the user exit window under every upgrade path your chain allows? Who can pause what, for how long, and under which conditions? Your answers to those questions are what exchanges, wallets, and institutional users will ask for in 2025 and 2026.

Related reading: For adjacent security models, see how restaking goes multi chain and how Solana’s validator design affects new MEV and throughput math.

Why a new market of proof providers and monitoring will grow

Once anyone can challenge, someone needs to show up. That opens a real market for services.

Bond pooling and proof providers. Not everyone who detects an invalid assertion has tens or hundreds of millions of dollars in capital to post bonds. Expect specialized proof providers and pools that let multiple parties contribute capital trustlessly to post a counter assertion and claim the reward.
Watchtowers as a service. A full node with alerting is not exotic, but running fleets of them across chains, tracking assertions, challenge trees, clock ticks, mempool conditions, and client versions is work. We will see monitoring services that guarantee response times in return for a subscription or a slice of challenge rewards.
CEX and bridge risk oracles. Exchanges and bridges will want standardized feeds that say which assertions are in window, which are challenged, and what the expected finality time is. That is not quite an oracle in the price-feed sense, but it looks similar in how it must be operated, audited, and monetized.
Insurance and coverage. If bonds are slashed and rewards paid, coverage products can protect honest challengers against operational failures, like a cloud outage that prevents a challenge submission. Pricing those risks is a new actuarial problem.

Through 2025 and 2026, these niches will grow because the incentives now exist in the protocol. There is real money to be made by showing up to secure the system, and that tends to attract professionals.

Builder checklist: upgrades, UX, and alerting

Use this as a pragmatic starting point for migrations to permissionless proofs and the day-to-day operations that follow.

Governance and contracts

Inventory every contract on Ethereum that your rollup depends on, including outbox, inbox, assertion manager, and any admin or pause roles. Document upgrade keys, time locks, and emergency powers. Map them to public docs for your partners.
If you are upgrading an Arbitrum chain to BoLD, rehearse the exact block at which you switch. Pending withdrawals that are still inside their window at upgrade time can inherit an extra full challenge period. Pre communicate the change on your bridge UI, status page, and to large integrators.
On OP Stack, confirm the fault proof virtual machine version you are on and the dispute game parameters. Make your planned window and any future change process public so bridges and exchanges can hard code rules if they choose to.

Bond economics and liquidity

Decide whether you will operate a house proposer or rely on third parties. If third parties, publish the bond amounts and the expected cadence for assertion posting. Explain your criteria for rotating proposers and how you handle liveness if no one shows up.
If you plan to run bonding pools, treat them like regulated infrastructure. Write a clear policy for key management, upgrades, and how you will pause in emergencies without blocking honest challengers.

Withdrawal UX

Show the clock in the bridge. “Estimated 6.4 days to finalize” beats a spinner. If a dispute starts, show the new bound, not a vague warning.
Distinguish between internal bridge queuing and protocol finality. If your system batches claims to save gas, say so. Users want to know whether time is due to your batching or to the rollup’s safety window.
Encode the window in the transaction data that your frontend displays. After the upgrade, a wallet should be able to tell the user where they stand in the process without calling a custom API.

Monitoring and alerting

Subscribe to assertion events and challenge events on Ethereum. Set alerts for new assertions that disagree with your node’s view, long gaps between assertions, or an unusual branching factor in the challenge tree.
Monitor your sequencer and proposer health, but also monitor the mempool under load. If your challenger needs to land a transaction under fee spikes, you should be able to raise a gas cap automatically for that transaction class.
Publish a public status page that explains the current assertion state and any live disputes. Use the same labels that appear on your explorer or docs so users do not have to learn new terms.

Partner communications

Send a one pager to exchanges and custodians that covers your challenge window, your upgrade process, and who can pause what. Include a timeline for future window changes and how much notice you commit to giving.
Offer a test assertion feed so integrators can simulate deposit crediting and withdrawal holds in staging.

User lens: what changes for you

Safer exits. If something goes wrong, you do not need to know a validator or rely on a multisig to rescue you. The rules let any honest party challenge, and those rules live on Ethereum. That is what protects your withdrawal.
More credible neutrality. The fewer levers a team can pull, the more the system behaves like neutral infrastructure. Permissionless challenge means no one can quietly promise a partner special treatment in the dispute game.
Clearer timelines. The waiting period for withdrawals is not arbitrary. It is a security window. You can plan around it, and in adversarial cases, the bound is explicit.

How the two stacks differ in practice

Dispute engine. Arbitrum’s BoLD turns the dispute into a parallel game with a strict bound, and it defines concrete bond sizes and mechanisms for pooled bonding. The default challenge period on Arbitrum One is about 6.4 days, with a targeted worst case of two periods if a dispute is live.
OP Stack’s model. The OP Stack focuses on a modular proof system and permissionless participation in proposing and challenging outputs. The June 10, 2024 activation on OP Mainnet made exits self service and pushed OP Chains to Stage 1, with governance hardening and multi proof support aimed at Stage 2.

As a builder, choose the stack that aligns with your risk budget and your user base, but make sure your public documentation speaks in protocol terms. Partners will ask for your challenge window, exit guarantees, and who can press pause. For a broader context on shared security across ecosystems, see Bitcoin as shared security layer.

The bigger picture

The move to anyone-can-challenge is the removal of a single point of embarrassment in the rollup story. For years, critics said rollups were just multisigs with better branding. That was never fair, but it rang true in moments of stress. Now, with permissionless fault proofs and time bounded disputes, the withdrawal path does not depend on who you know.

The rest of the journey is governance. Stage 2 is not only about open proofs. It is about long exit windows for unwanted upgrades and strict limits on any council’s power. If the code is correct, no group should be able to push a different outcome. That is a bright line users understand, and it is where the most credible chains are headed.

The market will follow the guarantees. By the end of 2026, expect proof providers with household names, watchtower companies with on call engineers, and exchange dashboards that show assertion health next to price. That is what real infrastructure looks like.

Conclusion

Training wheels are useful, but only until the rider learns to balance. Permissionless fault proofs and BoLD are that moment of balance for rollups. Withdrawals become predictable. Bridges and exchanges get cleaner models. Users gain a right to exit enforced by code, not by reputation. The next two years will be about building the services that show up when anyone can challenge. If there is one action to take now, it is to publish your chain’s guarantees in plain language and wire your alerts to the challenge clock. Everything else will follow from that clarity.