Scroll
Scroll withdrawals through the native bridge depend on finalized batches for Ethereum claims
Scroll withdrawals through the native bridge require batch finalization before assets can reach the Ethereum recipient. A successful withdrawal transaction on Scroll starts the exit; a later Ethereum transaction executes the withdrawal message. The wait follows proof generation and Ethereum settlement, so a time estimate is not a release deadline. Third-party transfer routes have their own liquidity and settlement conditions. The main choices concern token support, recipient control, and who pays the final claim fee.
Key takeaway: The account submitting a native bridge claim pays Ethereum gas, even when the bridge releases an ERC-20 token.
Batch finalization sets the requirement while waiting time varies
The native bridge requires a finalized withdrawal root, while the waiting time varies with network processing. Scroll must include the exit in its transaction history, commit the batch, and verify a validity proof on Ethereum. Proving work and Ethereum transaction inclusion affect when this happens. A countdown that finishes before settlement does not satisfy the claim contract.
A confirmed Scroll transaction establishes execution on the layer 2. Committed status establishes that Ethereum holds the batch data. Finalized status adds proof verification and settlement. These states describe different stages, even when an interface groups them under a single pending label. The withdrawal's recorded batch and finalization state explain whether the claim can proceed; elapsed hours alone cannot establish readiness.
The withdrawal message fixes the recipient and amount
Choose the payout recipient and amount before submitting the withdrawal. The later Ethereum claim proves an existing message, so it must preserve the recipient and amount that the gateway recorded.
Before submission
Rejecting an unsigned withdrawal leaves assets in their existing account. Token allowances are separate permissions: an approval can persist even when no withdrawal follows. Recipient contract compatibility also matters before submission, especially when the gateway forwards an additional call.
After successful Scroll execution
Successful gateway execution removes the withdrawn amount from the initiating account's spendable balance and records the exit. Another Ethereum account can pay for the claim without taking ownership of the payout. Editing the payout address changes the encoded message, which would invalidate its original inclusion proof. Declining the Ethereum claim leaves the recorded withdrawal awaiting execution.
| Native withdrawal parameter | Value or control rule |
|---|---|
| Transfer direction | Scroll mainnet to Ethereum mainnet |
| Mapped asset identity | For token withdrawals, the Scroll token contract and its mapped Ethereum token contract |
| Payout recipient | Address encoded in the original gateway withdrawal message |
| Release prerequisite | Valid message inclusion proof against a finalized withdrawal root |
| Claim submission | Anyone may submit valid claim data; payment goes to the recorded recipient |
Asset gateways determine what the Ethereum claim returns
The selected gateway determines the receiving asset and the permissions that initiation needs. Support for a token standard does not make every token contract bridgeable. A bridge interface can also list fewer assets than the underlying gateway contracts support.
Native ETH
An ETH withdrawal sends its value through the Scroll messenger. The Ethereum ETH gateway pays the recipient when the claim executes successfully.
ERC-20 tokens and WETH
Standard and custom ERC-20 gateways require a positive amount and an Ethereum token mapping; initiation reverts if either condition is unmet. They burn the withdrawn Scroll tokens and record a message for their Ethereum counterpart. The Ethereum gateway releases the corresponding tokens that it holds. The gateway mapping establishes that relationship; matching symbols do not establish compatibility. WETH has a dedicated path: its Scroll gateway unwraps the tokens, and its Ethereum gateway wraps the transferred ETH into WETH before payment. That path returns WETH to the recipient, with gas still requiring native ETH.
NFT collections
ERC-721 and ERC-1155 gateways support withdrawals for compatible, mapped collections. The token ID identifies the asset, and an ERC-1155 withdrawal also specifies its quantity. The Scroll token contract must authorize its mapped gateway to burn the withdrawn tokens.
Gas costs belong to separate transactions and network balances
A native withdrawal submitted directly on Scroll incurs a Scroll initiation fee and a separate Ethereum claim fee. Scroll charges ETH for execution and its Ethereum data component. The later Ethereum transaction has its own gas charge. Transferring an ERC-20 token or WETH does not automatically provide the claim payer with native ETH on Ethereum. An ETH withdrawal also needs enough Scroll balance to cover both its transfer value and initiation fee.
The initiation estimate depends on the gateway call, transaction data, and applicable fee parameters. The claim estimate depends on the proof, receiving gateway, any additional contract execution, and Ethereum gas conditions. An approval can add another transaction when the selected token path requires permission. Those spending allowances concern initiation; they do not prepay the later claim. Compare the complete route's charges and receiving asset before authorization, since an interface's single displayed fee may cover only part of the exit.
Paying more gas cannot replace a missing validity proof.
Claim proofs connect the recorded message to finalized history
The Ethereum claim calls
L1ScrollMessenger.relayMessageWithProof
with a Merkle inclusion proof for the withdrawal message. This proof establishes membership in the withdrawal tree. The rollup's validity proof establishes the correctness of the finalized state. These proofs serve different functions, and the claim contract needs a withdrawal root that the rollup has already finalized.
For gateway transfers, the message target is the Ethereum gateway, while the payout recipient appears inside the encoded gateway call. Substituting the wallet recipient for the message target would change the call that the proof authenticates. The sender, target, value, message nonce, and encoded call must match the recorded message. A bridge history service can supply these details, and software can also construct withdrawal proofs permissionlessly from chain data.
Delayed batches and failed claims require different responses
A withdrawal can await finalization, lack an available proof, or encounter an Ethereum execution failure.
Finalization and proof availability
The Ethereum messenger rejects a native withdrawal claim whose referenced batch has not finalized. Once finalization permits a claim, an unavailable proof service can still delay an interface's presentation of claim data. A missing history entry alone does not establish that the initiating transaction failed. The Scroll receipt, recorded message, and finalized root distinguish a processing delay from an interface problem.
Ethereum execution failures
The messenger can emit
FailedRelayedMessage
when the gateway call fails, even if the outer Ethereum transaction succeeds. Receipt status alone therefore cannot prove payout. A
RelayedMessage
event and the messenger's
isL2MessageExecuted
flag establish relay success; the gateway's withdrawal event and recipient transfer establish asset release. A failed target call leaves the message unexecuted, allowing another relay attempt if the failure can be resolved. A message that has already executed cannot pay out again. A pause or invalid proof also prevents the claim from executing.
Retrying the existing claim preserves its withdrawal message. Starting another withdrawal creates a separate exit and can remove additional assets from Scroll.
Liquidity-funded exits use a different settlement model
Some third-party routes pay from liquidity already available on the destination network. Their relayers can deliver assets before completing their own settlement and rebalancing. This can shorten the delivery wait when the selected route supports the asset and amount. It does not accelerate a pending native bridge claim. Destination liquidity, route limits, and the provider's settlement rules govern the alternative transfer.
The native bridge releases assets through the gateway relationship recorded in its message. A liquidity route introduces separate contracts and funding conditions, and a route that includes a swap can deliver a different token. Compare the destination asset and recipient, transaction costs, and any applicable expiry or refund terms. An advertised delivery estimate does not establish a guaranteed delivery deadline. Availability for one token and amount does not establish availability for another.
Enforced transactions offer another way to submit an exit
EnforcedTxGateway lets an externally owned account initiate a Scroll transaction through Ethereum with the same sender identity. The transaction can call a withdrawal gateway on Scroll. This provides an alternative submission path when ordinary sequencer access is unresponsive, subject to the deployed gateway's operating conditions.
The path still requires Scroll execution and the normal finalization and claim requirements. It does not release assets directly from Ethereum merely because Ethereum accepted the submission. Its externally owned account restriction also matters for contract wallets. A contract's ability to initiate a normal gateway withdrawal does not establish eligibility for this enforced submission method.
Proposed network changes need separate migration terms
The September 2026 DAO update described a move toward a permissioned chain, targeting early 2027. It made the timing and migration details subject to further governance review. That proposed target was not a stated withdrawal cutoff or a replacement for the native bridge's claim requirements.
Migration access conditions and deadlines belong to their effective terms. A future migration arrangement would need to specify how it treats funds remaining on Scroll and pending bridge claims. Before committing to that arrangement, confirm which asset you would receive and whether you can access the receiving account.
Popular questions about Scroll withdrawals
Why can an ERC-20 withdrawal claim have a zero ETH value?
A standard native ERC-20 withdrawal can carry zero ETH message value because its token amount sits inside the encoded gateway call. The Ethereum gateway transfers the corresponding token from its own holdings. Zero ETH value therefore does not mean a zero token withdrawal. The claim payer still pays Ethereum gas in ETH. WETH uses a different gateway mechanism that carries ETH for rewrapping.
Does closing the bridge interface stop an existing withdrawal?
Closing the interface does not cancel a withdrawal that has already executed successfully on Scroll. Its message exists in chain history independently of the browser session. The interface may need to retrieve that history again when reopened, and assets still await the required Ethereum execution. A rejected unsigned request has a different effect: it creates no withdrawal transaction.
Must funds leave a Scroll application before I can bridge them?
A gateway withdrawal needs assets that its initiating account or contract can supply. An ordinary wallet bridge call does not redeem an application's deposit on its own. If the application holds the underlying tokens, its withdrawal rules govern access to them. A receipt token has its own bridge compatibility; owning that receipt does not establish that the bridge can release the underlying asset.
Are my withdrawal amount and recipient visible on both networks?
Native withdrawals on public Scroll expose their amount and recipient through transaction data and bridge events. A successful Ethereum claim records the corresponding gateway call and asset transfer. Those records can connect activity across the networks, even when wallet interfaces display only a brief status. The inclusion proof authenticates the withdrawal message; it does not encrypt the recipient or hide the payout.
· updated