Proven means a withdrawal proof has been recorded, not that the destination payout has executed. For the applicable OP Stack fault-proof flow, finalization also depends on the proof's maturity, the supporting dispute game's valid state and finality, and a separate L1 action. Check those conditions for the actual chain and portal instead of measuring a single countdown from the original L2 send.
Keep the three transactions separate
The official withdrawal-flow guide describes initiation on L2, proving on L1 and finalization on L1. Each stage has a different purpose. An L2 success establishes the initiation action; an L1 proof establishes evidence for a later action. Neither alone is the destination execution.
| Record or state | What it establishes | What remains open |
|---|---|---|
| L2 withdrawal initiated | The source-side withdrawal action exists | An eligible proposal and proof |
| Proof transaction confirmed on L1 | A proof was submitted successfully | Maturity and the relevant game's eligibility |
| Proven displayed by an app | The app recognizes a proof state | Which proof record and portal conditions it uses |
| Time condition reached | A relevant waiting bound may have passed | Other validity conditions and finalization submission |
| Finalization transaction pending | An L1 attempt exists | Its inclusion and actual execution result |
| Finalization or relay failed | A specific execution problem occurred | The documented continuation for that problem |
| Destination action succeeded | The intended chain-side receipt can be inspected | Any separate custodial account crediting |
This article concerns the standard withdrawal path and its applicable fault-proof portal. A third-party fast bridge, exchange withdrawal or another OP Stack deployment can expose different steps. Save the chain, bridge application, L2 initiation hash, L1 proof hash and intended recipient. A status word without those references can hide which transfer the interface is describing.
Check both waiting conditions and the game's result
The Optimism Portal specification distinguishes proof maturity from dispute-game finality. The proof's age is measured from its own proving record. The game must also satisfy the required valid-claim conditions. A proof against a game still in progress is not evidence that all finalization conditions have already passed.
Proving late against an already resolved game does not automatically remove the proof's own maturity requirement. Conversely, an old proof does not make an unresolved or unsuitable game valid. The chain's configured parameters and current portal state matter. Do not copy a waiting duration from another chain or assume a familiar seven-day summary is a universal payout deadline.
As a fictional timing example, suppose one required time bound is reached at Day 9 and another at Day 11. The time-based lower bound is Day 11, provided the other conditions also hold. These are illustrative labels, not OP Mainnet parameters or promised dates. This comparison explains why satisfying one timer cannot substitute for checking the other.
A recorded proof can still depend on an unusable game
The portal specification describes conditions involving registered, respected and valid games, including cases where a game cannot support finalization. A proof's existence is therefore different from its continuing usefulness. If a game was rejected or made ineligible, waiting longer is not necessarily the next action. The supported application may need to select and submit an appropriate proof.
The bridge-integration specification explains the move from older output-oracle assumptions to dispute-game-based withdrawal verification. Older instructions can use different concepts and field names. Identify the deployed flow before applying a tutorial; a legacy screenshot does not establish the current eligibility of your proof.
Do not repeatedly re-prove as a way to make the status advance. A new proof submission can affect the relevant proof record and timing. Use the official interface's diagnosed next step or ask legitimate support which condition failed. A changed proof is not merely a refresh of an informational page, and a fresh L2 withdrawal would be another transfer altogether.
Ready to finalize still requires the final action
Once the relevant conditions hold, check whether the finalization transaction has actually been submitted. A wallet signature prompt can be waiting, a submitted transaction can be pending, or an execution can fail. Preserve its own L1 hash and exact result. Raising a transaction fee cannot make an immature proof mature or turn an invalid game into a valid claim.
After inclusion, inspect the withdrawal or relay outcome rather than treating the outer transaction's presence as the complete business result. The withdrawal-flow documentation distinguishes failure behavior at different call layers. A target-call failure and an eligibility failure are different cases, so do not assume every error is repaired by sending the same finalization again. Follow the documented procedure for the actual bridge and message.
If the intended recipient is a custodial account, chain-side execution and the service's internal allocation remain separate. Confirm the actual destination and asset before asking that platform about crediting. A finalization receipt with another destination cannot be repaired by changing your wallet's display settings.
Diagnose three different reasons for the same label
Imagine three fictional records all shown as proven. In Ash, the game is acceptable but the new proof is not mature. In Birch, enough time has passed but the supporting game is unsuitable. In Cedar, the conditions are met but no finalization transaction was submitted. The same status label can therefore lead to waiting, proof investigation or a finalization step.
A useful support note names the branch supported by evidence. Include the time you checked, the actual portal and the relevant transaction references. Avoid publishing the entire wallet history when a few public identifiers explain the problem. Keep any proposed further action associated with this withdrawal so another source transfer is not mistaken for a continuation.
- Identify the standard bridge route, source chain, destination and intended asset.
- Locate the L2 initiation and the actual L1 proof record.
- Check proof age separately from the supporting game's resolution, validity and finality conditions.
- Read the current portal state and official application's next action instead of relying only on a countdown.
- If eligible, inspect whether finalization was submitted and what that specific attempt did.
- Escalate an unclear failed condition with the relevant hashes; do not disclose wallet secrets or start a duplicate withdrawal.
The Standard Bridge guide provides the underlying product context. For the distinction between chain layers, see cross-chain bridges and L2 explorers. A no-account swap follows its own order route; its timeline should not be inferred from an OP standard withdrawal countdown.
FAQ
Does Optimism withdrawal time start only from the L2 transaction?
The relevant fault-proof flow also has timing tied to the proof and supporting game's finality. Check the actual chain and portal conditions rather than applying one countdown to every stage.
Why can an Optimism withdrawal stay proven after a long wait?
A proof can still depend on an ineligible or unresolved game, or the separate finalization may be missing. Identify which condition remains open before choosing another action.
Should I create another Optimism withdrawal if finalization is missing?
A new source withdrawal is another transfer and does not complete the existing one. Inspect the proof and finalization records for the original withdrawal first.