Optimistic vs ZK Withdrawals: Finalized but Not Received?

If an optimistic or ZK rollup withdrawal says finalized but the funds have not arrived, first identify what was finalized. The label may concern the L2 transaction, a batch accepted on Ethereum or the withdrawal’s final delivery. Those are different objects. Check the remaining bridge action and the actual destination record before starting a second withdrawal or concluding that the asset disappeared.

Read the noun beside finalized

Save the page, chain and identifier attached to the status. A batch number is not the same reference as a user transaction hash or a withdrawal message. A bridge interface can display several statuses on the same journey. Copying only the word finalized into a support request removes the information needed to tell which part of the journey completed.

Treat a missing reference as an investigation gap. Do not assign a stage from a screenshot’s colour or from a duration quoted for another bridge. The bridge’s current documentation should explain which object each term describes. A generic statement that a chain has fast finality cannot replace the state of your particular withdrawal message.

Optimistic: proving a withdrawal is not the final delivery

The OP withdrawal specification distinguishes initiation on L2, proving on L1 and finalizing on L1. Those names are useful even when inspecting a newer deployed implementation: a successful proving transaction is not the same record as a successful finalizing transaction. Use the bridge’s current process rather than copying old contract names or parameters from an example.

The current OP Standard Bridge guide describes its challenge-period withdrawal route and the additional message-relaying actions for L2-to-L1 movement. This does not mean that every ordinary transfer within an optimistic L2 waits through the bridge’s withdrawal process. Identify whether you are using the canonical withdrawal route, a different bridge service or a same-network transfer.

The OP finality guide separately explains chain finality terminology. The destination bridge conditions are a further question. If a user interface says a block is finalized, ask which requirement of the actual withdrawal is now satisfied and which action remains. Do not assume that a block label authorizes every later contract call immediately.

ZK: an accepted proof can still leave a claim step

Ethereum’s ZK-rollup explanation describes validity proofs used to establish state transitions. That mechanism differs from an optimistic fraud-challenge design. It does not imply that every bridge delivers funds at the instant an L2 wallet first shows success. The batch, settlement and bridge-specific operations still need to be identified.

A concrete example is Scroll’s messenger process: L2-to-L1 messages are executed on L1 with a corresponding proof after the applicable state becomes available. A user or another party can submit the execution. A finalized batch and a completed execution of your withdrawal are therefore different records to examine.

ZKsync’s bridge description similarly distinguishes creating the withdrawal message from finalization on L1. Its security-delay page, checked on 27 October 2026, describes a three-hour minimum execution delay after commitment and expressly says that this is not a guarantee of finalization within three hours. Do not start a universal delivery countdown from the moment you clicked Withdraw.

Case file A: the batch is finished, the claim is not

In a hypothetical record, the L2 withdrawal transaction succeeded and the associated batch reached its stated final stage, but the bridge still shows an available claim action. There is no completed destination execution linked to that message. The useful next question is whether the documented final action is required and ready—not whether another withdrawal should be initiated to make the first one visible.

Open the official route independently and match the original withdrawal. Check the destination chain, intended recipient, asset and required action. If the interface cannot find the message, compare the source account and reference it is searching for. A front end’s missing history entry does not, on its own, establish that the underlying message was never created.

Before a required destination action, establish who submits it and how its network fee is paid in the actual flow. A relayer may act on behalf of a user, or the interface may require a wallet transaction. Neither arrangement is universal. Do not send an unrelated payment to a private address offered as an ‘activation fee’ for a claim; it does not establish execution of the bridge message.

Case file B: destination execution succeeded, the wallet is quiet

In a different hypothetical record, the final L1 action succeeded for the intended withdrawal, and its delivery evidence matches the recipient. The remaining issue concerns the destination view. Check the chain selected in the wallet, the exact token representation and the actual recipient address. The initiating account and the beneficiary are not necessarily the same role.

For a token, examine the relevant asset record rather than assuming an unchanged native-coin balance means no delivery. For a contract-mediated value movement, a simple list of outgoing transactions from the beneficiary may not describe the whole receipt. Use the explorer’s actual record and the bridge’s description. Do not blindly copy a source-chain token contract into a different network’s asset list.

If the recipient is a custodial service, successful destination movement and internal credit remain separate evidence. Ask the service about that transaction and the exact deposit route. Do not turn a wallet-display issue into another bridge transfer, and do not tell a service that a mere finalized batch proves its address already received the funds.

Define what would close your investigation

1. Link the successful source withdrawal transaction to its actual message or bridge reference.
2. Identify the object described as finalized and the chain on which that status is reported.
3. Check the named route’s remaining eligibility, proof, waiting or execution requirements.
4. Verify a completed destination action for that withdrawal, including the correct recipient and asset.
5. Separate a missing wallet display or service credit from an incomplete bridge claim.
6. Keep both chain references and the bridge reference for support; share no seed phrase, private key or unrelated document archive.

If the goal is an exchange after withdrawal, wait until the required asset is actually available on the supported network. Read KOT.CASH’s exchange workflow, supported assets and current simple-swap instructions. This does not establish that a bridge’s direct contract delivery or every wrapped asset is accepted by an order. Confirm the intended deposit method instead of substituting a batch-finality label for receipt of funds.