A successful L1 transaction does not alone prove that an Arbitrum deposit finished on L2. First identify whether that transaction was only a token approval, an actual bridge deposit or another call. Then trace its destination-side result on the correct chain. For a route using a retryable ticket, ticket creation and successful execution are separate stages that require separate checks.
Confirm the route before looking for a retry button
This article concerns the canonical parent-to-child bridge flow, such as Ethereum to Arbitrum One. A third-party liquidity bridge, exchange withdrawal or another Arbitrum chain can have a different process. Save the app used, source chain, destination chain, intended recipient and token. The word Arbitrum is not enough to distinguish One, Nova and a test network.
Use the original L1 transaction hash from the sending record. If it only approved token spending, locate the later deposit transaction rather than treating the approval as delivery. A successful generic transfer to a contract address should also not be assumed to have invoked the expected bridge method. The actual action matters.
The Arbitrum bridge quickstart distinguishes source and destination networks and warns about different forms of assets such as USDC. Verify the target token rather than searching only its ticker in the wallet. A correct destination transfer can be hidden by a wrong network view or a different asset entry.
Build a stage record that matches the asset path
| Stage observed | Evidence to preserve | Next question |
|---|---|---|
| L1 token approval succeeded | Approval hash and authorized token | Was the separate deposit submitted? |
| L1 deposit succeeded | Actual bridge call and emitted message | What destination action does it initiate? |
| Retryable ticket created, where applicable | Ticket identity and current state | Did redemption execute successfully? |
| Destination attempt failed | Its execution error | Is a supported retry still available? |
| Destination action completed | Recipient and exact asset | Does the wallet show the correct chain and token? |
| Wallet display differs from chain evidence | Selected account and network | Is the issue presentation rather than delivery? |
| Recipient is a service account | The service deposit instructions | Was the chain receipt allocated internally? |
Arbitrum's parent-to-child messaging documentation distinguishes simpler native-token deposits from token-bridge messages using retryables. Do not apply one retryable-redeem procedure to every ETH deposit. Identify the actual path before deciding which receipt or tool should exist.
For retryables, inspect execution rather than creation alone
In an applicable retryable flow, submission and destination execution are asynchronous. A ticket can be created while an automatic execution attempt fails. The actionable question then concerns that ticket's current status and whether a later supported redemption can execute it. A success label on the creating transaction does not replace the destination result.
The documentation describes a finite ticket lifetime and a way to extend eligible live tickets. Check the actual expiry and available action promptly instead of treating a failed automatic attempt as a reason to wait indefinitely. It also describes native call-value refund handling; that must not be generalized into a promise that every bridged ERC-20 amount automatically returns to the original L1 sender.
The Arbitrum FAQ points to bridge transaction history and an official retryable-ticket tool. Reach tools through independently verified documentation. The initiating transaction hash helps locate the relevant message. A retry of an existing ticket is different from authorizing a new source-chain deposit, which could create another transfer.
Check the receiving account as well as the network
Read the actual destination and resulting asset movement. For ordinary externally owned accounts, familiar address expectations may hold, but contract-based or delegated-account paths can introduce address-aliasing considerations. The messaging documentation describes these cases. Do not manually replace a recipient or apply a guessed address transformation to make an explorer result resemble your wallet.
If the destination execution is successful, investigate the selected L2 network, account and token identity in the wallet. A missing fiat price or token row does not by itself overturn chain evidence. If the receiving account belongs to a platform, its supported-asset policy and internal crediting remain separate from the bridge's execution. Ask that receiver about the specific record.
Also keep deposit direction separate from withdrawal direction. A challenge period described for a child-to-parent withdrawal is not a universal waiting rule for a parent-to-child deposit. Advising everyone with a missing L2 deposit to wait out a withdrawal period can leave an actionable retryable unattended. Identify the state you have instead of borrowing a timeline from the reverse route.
Compare three fictional outcomes
In Case Ash, the only successful L1 record is an allowance approval. No bridge deposit has been established, so there is no missing L2 delivery to trace yet. In Case Birch, the actual deposit created a retryable but the destination execution failed. That is a ticket-status investigation. In Case Cedar, execution completed and the wallet is viewing Nova instead of the intended One network.
These are illustrative cases, not reported incidents. Each can produce the same description from a user: L1 success, no L2 money. Their next actions differ. Sending the source amount again is not a diagnostic test that distinguishes them. Preserve the evidence already collected so a support reply does not restart the investigation at the wrong stage.
Continue only the verified existing flow
- Save the original L1 hash, networks, app, token and intended receiving address.
- Classify the L1 action and distinguish approval from the actual bridge call.
- Open official bridge history and locate the resulting message or deposit record.
- If a retryable applies, inspect its current state, expiry and any destination execution error.
- Use only the documented continuation for that existing record; clarify uncertain costs or instructions with legitimate support.
- If destination execution completed, check wallet display or the receiving platform's account allocation separately.
Bridge troubleshooting supplies the product-specific support path. A useful report names the last verified stage and includes the relevant chain references. It does not claim every failed auto-redemption has the same cause or that every recovery is available. No support investigation needs your wallet recovery words.
The L2 explorer guide helps read destination records, while Arbitrum fees covers a separate cost question. For a no-account swap, use that order's own network instructions rather than assuming it follows this canonical bridge route. Diagnose the transfer you authorized before signing another one.
FAQ
How does an Arbitrum bridge explorer help when L1 succeeded?
It helps locate the destination-side record associated with the initiating transaction. First establish that the L1 action was the deposit itself rather than only an approval.
What should I check on an Arbitrum retryable ticket?
Inspect its current state, expiry and destination execution result. Ticket creation alone does not establish successful redemption.
Does every ETH deposit need manual retryable redemption?
No; the canonical documentation distinguishes native-token deposits from other messaging paths. Identify the actual deposit mechanism before applying a ticket procedure.