How to Prove and Execute an Arbitrum Withdrawal on L1

05 September 2026

Every withdrawal from Arbitrum to Ethereum mainnet is a two-phase process. The first phase happens on L2: you initiate the withdrawal through the Arbitrum bridge. The second phase happens on L1, and it has two steps of its own - proving the transaction, then executing it. This is a deliberately slow system, designed to give the network time to detect fraud.

You cannot skip either step.

Step 1: Proving the Withdrawal Transaction

After you submit your withdrawal on Arbitrum, the transaction is batched and sent to Ethereum as part of a state root. That state root must be confirmed on L1. Confirmation happens when Arbitrum’s sequencer posts a batch and the challenge period - roughly seven days - has passed without a successful fraud proof.

Once the state root is confirmed, you can prove your withdrawal. Proving means you submit a Merkle proof that links your specific L2 transaction to the confirmed state root on L1. The proof is a set of hashes that shows "this transaction is part of that batch." You call a function on the Arbitrum Outbox contract on Ethereum with your transaction data and the proof.

The Outbox contract checks the proof against the stored state root. If the hashes line up, your withdrawal is marked as provable. You pay a small gas fee for this call.

Common error: "merkle proof invalid"

This error means your proof does not match any state root the Outbox recognizes. Several things can cause it.

• The batch containing your transaction is not yet confirmed. Wait for the challenge period to expire.
• You are using an outdated proof. The Outbox contract prunes old state roots. If you waited too long after confirmation, the root may have been removed.
• You have the wrong transaction index or block number. Double-check the exact transaction you are trying to prove.

The fix in most cases is patience. Wait one confirmation cycle and retry.

Step 2: Executing the Withdrawal on L1

Proving the transaction only registers it as valid. It does not send you your funds. You still need to execute the withdrawal.

Execution is a second transaction sent to the Outbox contract. You pass the same proof and transaction data, but the function call now triggers the actual transfer. The contract releases your ETH or tokens from the bridge’s L1 pool and sends them to your L1 address.

This step also costs gas. It is separate from the proving step, so you pay two gas fees for a complete withdrawal.

Common error: "challenge period not elapsed"

This error appears when you try to execute before the full challenge period has passed. The execution function explicitly checks that sufficient time has elapsed since the state root was posted. If the check fails, the transaction reverts.

There is no workaround. Wait until the period ends. If you are unsure how much time remains, check the block timestamp of the state root submission and add seven days. The exact length of the challenge period can vary slightly depending on network congestion or configuration changes, but seven days is the standard.

Third-Party Relayers as an Alternative

You do not have to do both steps yourself. Several third-party relayers offer a service where they monitor the Outbox contract, prove and execute your withdrawal on your behalf, and charge a fee.

The process is the same on the L1 side. The relayer sends the same two transactions. You simply initiate the withdrawal on L2 and then wait. The relayer handles the rest.

Relayers are convenient, but they introduce a trust assumption. You rely on the relayer to actually execute the transaction. If the relayer goes offline or ignores your withdrawal, you can still do both steps yourself - your withdrawal stays pending and provable until the state root is pruned.

Not all relayers are free. Fees vary. Some relayers batch multiple withdrawals to reduce per-user costs. None of this changes the underlying mechanics: proving, then executing, with a seven-day delay in between.

Why the two-step process exists

Arbitrum is an optimistic rollup. It assumes transactions are valid unless challenged. The seven-day window gives anyone time to submit a fraud proof. If you could withdraw immediately after the transaction, a malicious sequencer could steal funds and exit before anyone noticed.

The proving step verifies that your transaction really happened. The execution step actually sends the funds. Separating the two allows the security model to work without requiring every user to run a full node.

No one has found a way around the seven-day wait. That is by design. If the delay bothers you, third-party bridges like Hop or Stargate offer faster exits. Those have their own trade-offs. For native bridge withdrawals, the two-phase process is the only path.

Back to arbitrum