Arbitrum withdrawals - the bridge wait and Ethereum claim

Returning ETH to Ethereum

An ETH exit from Arbitrum One makes that balance available for use on Ethereum after the native withdrawal completes. The source-chain transaction burns the withdrawn ETH and creates a message authorizing its release on Ethereum. This links the balance change on Arbitrum to the bridge’s Ethereum holdings. The wallet’s address may stay the same across both networks, but each chain keeps a separate balance. Switching the wallet’s network view only changes which balance it displays.

Token gateways and the Outbox

ERC-20 withdrawals use paired gateway contracts to coordinate the asset movement between chains. The Arbitrum gateway handles the token, while Ethereum’s Outbox authenticates the cross-chain message. These contracts perform distinct parts of the same exit, connecting token accounting to confirmed settlement.

The asset release instruction

Standard token gateways

A standard gateway burns the bridged token representation on Arbitrum and sends a message to its Ethereum counterpart. The Ethereum gateway releases the corresponding tokens from escrow when that message executes. The token’s bridge mapping connects those contracts. An ERC-20 balance on Arbitrum therefore needs the appropriate gateway before the standard withdrawal path can handle it.

Custom gateways

A custom gateway can define token-specific behavior beyond the standard burn-and-release arrangement. The router selects the token’s gateway from a token-specific mapping or its configured default. A shared ticker doesn’t establish that mapping, and ERC-20 compatibility alone doesn’t establish an Ethereum bridge route. The actual token contract and configured gateway determine the applicable withdrawal behavior, including which asset the destination receives.

The settlement proof

The Outbox checks a Merkle proof, which establishes that a withdrawal message belongs to a confirmed collection of outgoing messages. The covering assertion must reach confirmation before the normal claim can execute. Posting transaction data to Ethereum makes those inputs available; confirming the assertion authorizes execution of the resulting withdrawal messages.

The source transaction hash identifies the Arbitrum transaction, while the withdrawal event supplies a position identifying its message. That position connects the outgoing message to its later Ethereum execution record. The claim has its own Ethereum transaction hash.

How long does the native bridge withdrawal take?

Standard native withdrawals from Arbitrum One and Nova generally become claimable in about a week when batching and assertion confirmation progress normally. The standard Arbitrum One configuration sets its dispute window at 45,818 Ethereum blocks, roughly 6.4 days. The dispute window runs from creation of the assertion covering the withdrawal. Batch posting and assertion creation add time after the wallet submits its transaction, so the dispute window alone isn’t the complete waiting time.

An assertion is a validator’s claim about chain state, including outgoing messages. The challenge window gives other validators time to contest an incorrect claim. If a dispute affects the covering assertion, confirmation can take longer while the protocol resolves it.

The Rollup contract exposes its configured confirmation period through confirmPeriodBlocks. Other Arbitrum chains can use different settings, so One’s waiting time doesn’t apply to every chain.

Why hasn’t my withdrawal arrived after the countdown?

The countdown estimates claimability; funds arrive only after a successful Ethereum claim. An elapsed timer doesn’t establish that the covering assertion reached confirmation or that anyone executed the message. A successful Arbitrum receipt reports the source transaction. The Ethereum receipt reports execution of the later claim, including whether that transaction succeeded.

The withdrawal status separates these situations. In the Arbitrum SDK, UNCONFIRMED means the message hasn’t reached claimable settlement. It can still be awaiting batch posting, a covering assertion, or assertion confirmation. CONFIRMED means the message is ready for execution, with funds still awaiting the claim. EXECUTED identifies a message whose parent-chain execution has completed.

The native bridge’s Claim action submits the execution transaction on Ethereum once the message is ready. Submission still leaves Ethereum to include and execute the transaction.

Gas on the source and destination chains

The standard wallet-funded route requires gas for initiation on Arbitrum and execution on Ethereum. Arbitrum One and Ethereum both charge transaction gas in ETH. Those balances remain separate. ETH held on Arbitrum can’t directly pay the Ethereum transaction fee, and ETH awaiting withdrawal isn’t available there to prepay its own claim. A wallet withdrawing a token also needs the source chain’s gas currency.

The initiation fee covers source-chain execution and the applicable charge for posting transaction data. The Ethereum claim has a separate fee reflecting its gas consumption and Ethereum’s fee conditions when it executes. ETH and token claims can consume different amounts of gas because they call different contract operations. An initiation quote doesn’t fix the later claim cost. For an ordinary wallet-funded ETH exit, the withdrawal amount must leave enough source-chain ETH to cover initiation.

Faster routes and layered-chain exits

A fast liquidity bridge delivers destination assets using its own liquidity arrangements, allowing receipt before canonical settlement. Fees, available liquidity, and supported tokens determine the offered transfer. This introduces the bridge’s contract and liquidity assumptions. An exchange accepting deposits on an Arbitrum network provides another custody-based option. Its deposit crediting, Ethereum withdrawal availability, and fees follow the exchange’s own rules. An exchange deposit doesn’t itself execute a native Ethereum bridge claim.

Committee confirmation on configured chains

The Arbitrum stack also supports a chain-level fast withdrawal configuration. On a chain enabling it, unanimous validator-committee approval can confirm assertions before the ordinary challenge period finishes. This changes the chain’s settlement assumptions, unlike a liquidity bridge supplying assets ahead of settlement. The feature’s availability doesn’t make it part of One’s standard native exit. Parent-chain execution still completes the confirmed withdrawal message.

An intermediate parent chain

An Arbitrum chain settling to Arbitrum One first exits to One through its canonical bridge. Reaching Ethereum then requires a separate One-to-Ethereum withdrawal. Each leg has its own confirmation settings and parent-chain claim; the first claim must execute before the onward native withdrawal begins. A shorter first-leg wait doesn’t shorten One’s standard second-leg wait. Custom gas currencies can also change the first leg’s fee requirements.

Nova exits and the 2026 support changes

Arbitrum Nova’s approved 2026 minimization plan preserves canonical withdrawals while calling for reduced infrastructure and maintenance-only support. The plan warns that slower assertion posting may lengthen withdrawals without changing the challenge period. The plan scheduled a migration window from June 4 to September 2, 2026. The plan keeps migration possible afterward, so that window wasn’t an expiry for tokens. For large Nova-to-One transfers, the documented route withdraws to Ethereum, then deposits the claimed assets into One. Fast-route availability depends on providers maintaining Nova support. A Nova balance therefore needs a route serving Nova, even when the intended destination is One.

Open full-size image