Arbitrum native withdrawals require a separate claim to release ETH on Ethereum

Prepare the withdrawal amount and Ethereum recipient

Start with spendable ETH on the originating network, enough ETH for its transaction fee, and an Ethereum recipient you control.

The selected network must hold the balance you intend to withdraw. A wallet can display the same address across networks while showing different balances. Switching its network changes the balance you inspect; it does not move funds. Choose Ethereum as the destination for this withdrawal, and review the recipient separately from the address paying transaction fees.

Keep the withdrawal amount below the balance available after transaction costs. The native ETH withdrawal carries the amount as transaction value. A token balance with an ETH-related name does not automatically qualify for this operation; the selected asset must actually be native ETH.

Before submission, confirm that any recipient contract can accept the bridge’s ETH transfer, and record the destination and amount. After submission, retain the originating transaction hash. Those details connect the initial debit to the later Ethereum claim, whose receipt establishes whether the transfer completed. A wallet signature alone does not establish that either transaction succeeded.

Why does a successful withdrawal still have a waiting period?

The originating transaction creates a withdrawal message, while Ethereum execution requires confirmation of the assertion covering that message.

An assertion is a claim about the originating chain’s state. The protocol allows challenges before confirming it. Batch posting, assertion submission, and confirmation each affect when a withdrawal becomes executable. A displayed countdown estimates progress through those requirements; reaching zero on a local clock does not itself authorize the claim.

Execution through the Outbox requires confirmation of the assertion containing the withdrawal message. The challenge period comes from the chain’s configuration, so a fixed calendar promise can misstate the actual wait. A dispute can extend confirmation, and an assertion covering the withdrawal must exist before that confirmation can occur.

The initial debit creates an outstanding withdrawal

A successful native withdrawal removes the withdrawn ETH from the originating balance and creates a message for later execution. The protocol’s ArbSys.withdrawEth operation burns that amount on the child chain. The corresponding Ethereum ETH remains in bridge escrow until execution releases it. During the wait, the withdrawn amount is no longer available for another transaction on the originating chain. Its absence from both spendable wallet balances can therefore reflect a pending withdrawal.

Claim gas needs funding on Ethereum

The account submitting the claim needs ETH on Ethereum to cover the transaction’s gas requirement before it executes.

View full-size image

ETH remaining on the originating network cannot pay this Ethereum fee directly. The withdrawal amount also remains unavailable until the claim succeeds. Keeping enough funds for the first transaction therefore does not establish that the second transaction has funding. Review the Ethereum account’s available balance when the withdrawal becomes claimable.

The final fee follows Ethereum execution costs and network conditions at submission. An estimate taken when the withdrawal began can become stale during the waiting period. Higher transaction fees can affect inclusion after a claim becomes executable, but they cannot make an unconfirmed withdrawal eligible for execution.

Pending status needs a more precise diagnosis

A pending withdrawal needs investigation at the stage it has reached, because several different conditions can produce the same waiting screen.

The SDK distinguishes UNCONFIRMED, CONFIRMED, and EXECUTED. The first covers several earlier stages, including waiting for a covering assertion. The second means execution is available. The third means the withdrawal has already executed. These labels describe the message, so they can differ from the successful status of its originating transaction.

An overdue countdown calls for checking whether the covering assertion exists and whether it has been confirmed. A missing claim button can also reflect a display or connection problem. Reconcile the interface with the message state before repeating an action. Creating another withdrawal produces another message; it does not advance the existing one.

The proof preserves the recipient and amount

The claim executes the destination and value recorded in the withdrawal message, rather than accepting a new payment instruction.

A Merkle proof demonstrates that the message belongs to a root the Outbox recognizes. The verification covers the recipient, amount, and other message fields. Editing those values would produce a different message hash, so the original proof would no longer establish inclusion. The wallet submitting the transaction therefore cannot redirect the withdrawal simply by becoming its gas payer.

The Outbox rejects execution of a withdrawal it has already marked as spent. This prevents a repeated claim from releasing the same withdrawal twice. An already-spent response calls for locating the successful execution, including one submitted by another account.

Match the Ethereum receipt to the original withdrawal

Completion requires a successful Ethereum execution associated with the same withdrawal message and its recorded recipient.

The originating receipt contains an L2ToL1Tx event with the withdrawal’s position. That identifier helps match the message to its Ethereum execution. The Ethereum claim has a different transaction hash from the originating withdrawal. Searching only for the original hash on Ethereum can therefore miss a completed claim.

Compare the executed amount with the recorded withdrawal amount, then account for gas and any unrelated balance changes. A wallet’s total balance can obscure the credit when the same account also pays fees or makes other transfers. Retain both transaction hashes once the records match. If the claim receipt shows failure, the transfer has not completed through that transaction.

A different exit route changes the settlement assumptions

A liquidity bridge can provide destination funds through a separate liquidity arrangement, with its own fees, availability, and risks.

View full-size image

That arrangement differs from waiting for the native withdrawal’s Outbox execution. It does not automatically accelerate a message already committed to the native bridge. Closing a browser or selecting another route also leaves that existing withdrawal intact. Track it until execution even if other funds move separately.

The native claim remains the relevant next action once its message becomes executable. Timing and execution assumptions change if the actual route uses a liquidity provider or a chain configuration with different confirmation rules.