Fraud proofs keep invalid L2 withdrawals from reaching Ethereum

An optimistic rollup makes an L2-to-Ethereum withdrawal wait through a challenge period so challengers can dispute an invalid state update before the bridge releases funds. The delay gives independent observers time to check the rollup’s published data and challenge a faulty claim. The exact steps and waiting period depend on the rollup’s contracts.

Ethereum.org’s rollup guide describes a typical exit: the withdrawal is included in an L2 batch, its state is posted to Ethereum, and the user later proves the withdrawal was included. For a closer look at how bridge routes fit into that process, see Mantle Bridge. The key distinction is that a fraud proof challenges a state claim; the withdrawal proof shows that a particular exit belongs to an accepted state.

What does a fraud proof check?

A fraud proof gives Ethereum a way to resolve a dispute over whether an L2 state transition followed the rollup’s rules. The operator publishes data and a commitment to the resulting state; a challenger who finds an error submits a dispute under the rollup’s rules. The onchain verifier then determines which claim is supported.

Many designs narrow the dispute step by step. Instead of replaying every transaction on Ethereum, the parties identify a disputed part of execution, and the verifier checks the final contested step. Ethereum.org’s guide says this reduces the work Ethereum must do, while still requiring the rollup’s transaction data to be available so challengers can reproduce the state.

For a withdrawal, the useful question is not simply whether a user requested an exit. It is whether the state that records the exit is valid and accepted. If a challenge succeeds, the disputed state claim can be rejected; a withdrawal based on it cannot be finalized as though the claim had passed.

What must happen before a user can withdraw?

The rollup must publish enough data and state commitments for observers to check the transition, and its contracts must provide a working route to challenge an invalid claim. Once the relevant state is accepted, the user can provide the bridge contract with evidence that the withdrawal is included.

• The L2 must process the withdrawal and include it in published transaction data.
• The rollup must publish a state commitment that covers that transaction.
• Observers need access to the data and time to challenge an incorrect commitment.
• The user must submit the required inclusion proof and complete the L1 finalization step.

Ethereum.org describes the inclusion evidence as a Merkle proof: it connects the withdrawal transaction to a batch root recorded on Ethereum. The L1 contract checks that evidence against the accepted root before paying out. A user generally does not need to generate a fraud proof to withdraw; that is the challenger’s job. The user does need to follow the rollup’s exit procedure and wait until its contract permits finalization.

Why can’t every L2 withdrawal use the same wait?

Each optimistic rollup sets its own dispute and finalization rules, so a familiar delay is not a universal guarantee. Ethereum.org gives roughly seven days as a general example for optimistic rollups, but the applicable window is the one enforced by the specific rollup’s contracts. A live dispute or other protocol rule can also affect when an exit becomes final.

Liquidity providers can pay users sooner by taking over a pending withdrawal for a fee, as Ethereum.org notes. That trades waiting time for a service charge and reliance on the provider’s terms. For most users who can wait, the direct withdrawal avoids that fee; before sending funds, check the rollup’s current exit instructions and finalization status. The withdrawal becomes claimable when its challenge window has ended and the L1 contract accepts the finalization transaction.