Optimism
Optimism withdrawals through the Standard Bridge need proof and finalization before funds reach Ethereum
ยท last updatedOptimism withdrawals through the Standard Bridge move ETH and supported ERC-20 tokens from OP Mainnet to Ethereum. The documented mainnet flow includes a minimum seven-day wait, alongside proof and dispute-game checks. Initiation records the withdrawal on OP Mainnet; proving and finalization take place on Ethereum. Funds arrive only after successful Ethereum-side execution. A confirmed OP Mainnet transaction therefore doesn't establish delivery, and the elapsed time since initiation alone doesn't establish readiness.
Proof maturity and game review govern the mainnet wait
OP Mainnet's documented Standard Bridge route includes a minimum seven-day wait before finalization. The proof maturity delay starts when Ethereum records the withdrawal proof. Proving requires an Ethereum-side state proposal covering the withdrawal's OP Mainnet block. The proof must also postdate the dispute game's creation. Finalization then waits for both proof maturity and a valid game result beyond its review period. Proving against an already-resolved game doesn't remove the proof's own waiting requirement. A late proof can therefore postpone release even when the underlying state claim has already cleared review.
The active contracts govern the delays. Configurable portal implementations expose
proofMaturityDelaySeconds
;
disputeGameFinalityDelaySeconds
reports the game's review period. Other OP Stack deployments can use different configurations.
The withdrawal record connects initiation to Ethereum execution
The standard withdrawal path requires three onchain transactions: initiation on OP Mainnet, proving on Ethereum, and finalization on Ethereum. During initiation,
L2ToL1MessagePasser
records the withdrawal hash and emits
MessagePassed
. The message commits to the sender, target, value, gas limit, nonce, and calldata. These fields identify the requested Ethereum-side action. The initial record establishes that OP Mainnet accepted the withdrawal request. It doesn't establish that Ethereum has executed the receiving contract or released its tokens.
For proving,
OptimismPortal
checks an inclusion proof against a state commitment represented by a dispute game. A successful proof records the game and proof timestamp. Finalization later checks eligibility and calls the Ethereum target. The portal marks the withdrawal finalized before that call and reports its success status. A failed target call can therefore leave a finalized record without the intended receiving action. The messenger or token bridge has its own execution outcome. You can retry a message the L1 messenger has recorded as failed if it hasn't since succeeded and pause and target checks pass. Call relayMessage on Ethereum with the original message parameters and no attached ETH value. The outer transaction's success status alone doesn't establish successful delivery through every nested call.
Optimism withdrawals: Standard Bridge delays
- Proof maturity and game review govern the mainnet wait
- The withdrawal record connects initiation to Ethereum execution
- Why can a finalized OP Mainnet transaction still have a pending withdrawal?
For a token withdrawal, completion means successful destination-side bridge execution and the intended recipient's corresponding balance change on Ethereum.
Why can a finalized OP Mainnet transaction still have a pending withdrawal?
A finalized OP Mainnet transaction establishes the transaction's place in the chain; withdrawal finalization separately authorizes execution on Ethereum. OP Mainnet typically reaches Ethereum-backed transaction finality within about 15 to 30 minutes under normal conditions. That timing includes publishing the transaction data and Ethereum finalizing the block containing it. The Standard Bridge's seven-day withdrawal schedule applies to releasing the cross-chain claim. These timings measure different events, so a finalized initiation transaction can coexist with an immature withdrawal proof.
The
safe
and
finalized
RPC block tags describe chain progress. They don't report successful execution of an Ethereum-side bridge call.
Token origin changes the bridge's handling
The token's origin determines whether the Standard Bridge burns a representation or locks a native balance before Ethereum-side execution. Returning an Ethereum-native ERC-20 burns its bridged representation on OP Mainnet and unlocks the original token on Ethereum. Sending an OP Mainnet-native ERC-20 in the same direction uses lock-and-mint handling instead. That route needs a compatible bridged representation on Ethereum. ETH has dedicated bridge functions. Token mechanics change the transfer's accounting; they don't eliminate canonical message verification or the applicable waiting period.
| Asset or message option | Ethereum-side handling | Delay or support condition |
|---|---|---|
| ETH through the Standard Bridge | Transfers ETH to the specified recipient | Documented OP Mainnet route: minimum seven-day wait |
| Ethereum-native ERC-20 returning through the Standard Bridge | Unlocks the original token after burning its L2 representation | Documented OP Mainnet route: minimum seven-day wait |
| OP Mainnet-native ERC-20 through the Standard Bridge | Mints its compatible Ethereum representation after locking the L2 token | Same canonical withdrawal conditions |
| Contract message through the canonical messenger | Calls the target contract with the committed data | Mainnet challenge period and finalization checks apply |
| Fee-on-transfer ERC-20 through the Standard Bridge | Standard Bridge doesn't support this token behavior | No supported Standard Bridge duration |
| Rebasing ERC-20 through the Standard Bridge | Standard Bridge doesn't support this token behavior | No supported Standard Bridge duration |
| Custom token bridge | Follows its own bridge implementation | Design-specific; canonical messaging retains its delay |
Gas costs accrue on both networks
Each withdrawal transaction consumes resources on the network where it executes, so a complete exit involves separate OP Mainnet and Ethereum costs. Initiation uses OP Mainnet's fee model, including execution, L1 data, and any configured operator charge under the active rules. Proving and finalization execute on Ethereum and require Ethereum gas. ETH reserved on OP Mainnet doesn't automatically fund those Ethereum transactions. Their cost varies with gas usage and Ethereum's fee market; the withdrawal's token amount doesn't determine a fixed percentage charge.
Withdrawing an ERC-20 doesn't turn that token into ETH for later Ethereum transactions.
Fault proofs and emergency controls affect release
When a disputed state claim fails, the portal cannot use that claim to authorize the withdrawal. Permissionless fault proofs let participants challenge proposals during the applicable window. A successful fault-proof challenge rejects an invalid state claim without reorganizing the OP Mainnet transaction. The withdrawal can remain legitimate even though its original supporting proposal fails.
The review period after game resolution gives the Guardian a window to reject an incorrectly resolved claim.
The Optimism Security Council's Guardian role can pause withdrawals, blacklist games, or trigger a permissioned fallback. These controls qualify the permissionless withdrawal path. A mature proof doesn't override an active pause or make an invalidated game usable. Finalization also prevents replay of a withdrawal the portal has already finalized.
For portal implementations with a configurable maturity delay, the value in force at finalization also applies to existing proofs.
Can a custom bridge change the withdrawal waiting period?
A custom bridge can use a different transfer design, while a route using canonical L2-to-L1 messaging retains that messaging system's waiting requirement. Its contracts and message path determine when funds can reach Ethereum. Other bridge systems have their own supported assets, execution rules, and security properties. A different delivery schedule applies only when the chosen route's actual mechanism and configuration support it.
Still wondering about Optimism withdrawals?
Can I prove a withdrawal again if its original dispute game becomes invalid?
Yes, a withdrawal can use a new proof against an eligible dispute game if its original game becomes unusable. Re-proving resets the proof maturity timer for that proof submitter. Another account's proof doesn't reset your separate timer. Re-proving changes the supporting proof; it doesn't require a duplicate token withdrawal on OP Mainnet.
Will paying a higher priority fee shorten the Standard Bridge challenge period?
A higher priority fee doesn't shorten the protocol's withdrawal waiting period. It affects transaction inclusion incentives on the network receiving the transaction. Proof maturity and dispute-game review follow separate contract rules. Paying more gas can't turn an immature proof into a finalizable withdrawal.
Why does an explorer show an internal revert during a withdrawal?
Some internal reverts come from the Chugsplash Proxy's normal execution path and don't establish withdrawal failure. A trace warning needs context from the outer transaction and the actual bridge or messenger outcome. An expected proxy revert doesn't excuse a failed receiving call, and it doesn't prove that the recipient received the assets.
How should a smart contract wallet choose the Ethereum recipient for an ERC-20 withdrawal?
A contract wallet should use an explicit recipient it can control on Ethereum through the Standard Bridge's bridgeERC20To function. The same contract address doesn't necessarily provide usable wallet access on both networks. The bridgeERC20 function rejects contract callers, helping prevent accidental transfers to an inaccessible same-address recipient.
Does every Standard Bridge ERC-20 withdrawal need a token allowance?
Returning a compatible bridged ERC-20 representation doesn't require a separate allowance because the Standard Bridge already has authority to burn it. Bridging a token native to OP Mainnet uses different handling: the bridge needs an allowance to pull and lock the native token. The token's origin determines the approval requirement.
Are testnet withdrawals subject to the same seven-day wait as OP Mainnet?
Test networks can use shorter challenge periods than the documented OP Mainnet route. Their configured timing applies to their own withdrawal environment. A successful testnet withdrawal therefore doesn't establish the production waiting period, and a testnet countdown doesn't determine an OP Mainnet claim's readiness.
Who can submit an output proposal if the usual proposer stops operating?
Anyone can submit a state proposal under the permissionless fault-proof configuration. Such proposals can support withdrawal proofs when they cover the required chain state and meet the portal's eligibility rules. This permissionless path remains subject to Guardian controls, including pauses and a possible permissioned fallback.
Which contract addresses identify the right ERC-20 withdrawal pair?
The OP Mainnet token contract and its corresponding Ethereum token contract identify the withdrawal pair. A shared ticker doesn't establish that relationship. The Standard Bridge treats different bridged representations as separate tokens, and its compatible representation must recognize the correct remote token. The bridge tracks backing separately for each token pair, so one representation can't draw on another pair's backing.