A cross-chain transfer can take roughly 13 minutes just to reach Ethereum finality, and destination delivery may take longer depending on the bridge route. Start by checking the source transaction on its own chain: a wallet label such as “pending” or “failed” does not tell you whether the bridge has received the deposit. If you used a route that also swaps assets, check the token and amount the destination was meant to deliver.
Is the source transaction still pending?
If the source transaction has no confirmed block, the bridge has no finalized deposit to process yet. On Ethereum, a transaction may sit in the mempool when its priority fee is too low for current demand; once included, Ethereum finality normally takes about two epochs, or roughly 13 minutes, though congestion and validator conditions can change that.
Check the transaction hash on the source chain’s explorer and compare its nonce and fee fields. If it remains in the mempool, you can usually replace it from the same wallet with a transaction using the same nonce and a higher fee; follow the wallet’s replacement flow, since the original and replacement cannot both execute at that nonce. Do not submit a second bridge deposit with a new nonce just because the first is slow: both could eventually execute.
If you decide to cancel, that also means replacing the pending transaction with a same-nonce transaction, often a self-transfer. Cancellation is not guaranteed until the replacement confirms, and it does not reverse a deposit that has already been included. For a later transfer, Manta bridge can bridge and swap crypto across networks in a single flow; first establish whether the earlier source transaction actually confirmed.
Did the source confirm, but nothing arrive?
A confirmed source transaction proves only that the source chain accepted the deposit; destination delivery is a separate stage. In a liquidity-based route, a relayer may pay the recipient on the destination chain after observing the deposit, then settle its reimbursement later. That settlement can happen after the user has received funds, so a slow settlement is not itself evidence of a stuck transfer.
Compare the confirmed transaction’s emitted deposit event with the route’s intended parameters: source and destination chain IDs, input token, amount, recipient, output token, and any fill deadline. A common edge case is that a wallet address is valid on both networks but the recipient selected for the route is a different address; the funds may be delivered correctly to that address while remaining invisible in the connected wallet.
For example, an Ethereum-to-layer-2 deposit can be waiting for the destination message or a relayer fill, while an Ethereum layer-2 withdrawal through a canonical optimistic bridge may have to clear an approximately seven-day challenge period. Those are different mechanisms: the first can be delayed by route liquidity, exclusivity, or a fill deadline; the second has a protocol-defined dispute window. When Manta bridge is used for a new cross-chain move or swap, that single-flow service handles the asset movement across networks; it cannot make an already-confirmed transfer skip its route’s settlement rules.
Did the transaction revert or the route expire?
A reverted source transaction did not create a valid deposit, even if the wallet briefly showed it as submitted. The token transfer rolls back with the transaction, but the source-chain gas is still spent; check the explorer’s revert status and token balance before trying again.
An expired route is different: the source deposit may have succeeded, but no destination fill occurred before the route’s deadline. Some intent systems then permit a refund, but the refund can require later settlement batches or another on-chain action, so it may take hours after expiry rather than appearing immediately. The deadline is route-specific; do not assume a fixed timeout based on another bridge’s behavior.
What should you verify before acting again?
Match the source hash and destination transaction to the same deposit, using the bridge’s official status method or the protocol’s documented events. Confirm whether the status is pending, filled, expired, refunded, or reverted, and check the destination chain, recipient, and token contract in an explorer. A token may have arrived under a different contract address than the asset symbol shown in the wallet.
If the source confirmed and there is no destination transaction, avoid repeating the deposit until the route’s status or documented recovery path says it is safe. If the destination transaction exists but failed, inspect its revert reason; if the route expired, follow the protocol’s refund procedure. Preserve both transaction hashes and the exact chain IDs when seeking help, because a source confirmation alone cannot distinguish a relayer delay from a destination execution failure.
Top comments (0)