If your origin-chain transaction is confirmed but the destination wallet is still empty, check the transfer status before trying again. A confirmed deposit can still be waiting for a relayer to deliver the tokens, and sending a second transfer may duplicate the one you meant to make.
Does “pending” mean the transfer failed?
No: “pending” means the deposit has been recorded but a relayer has not yet filled it on the destination chain. When you deposit, the origin-chain pool holds your tokens; a relayer uses its own funds to send the specified output tokens to your recipient on the destination chain. The fill is a separate transaction, so the two wallets will not update at the same moment.
Most mainnet fills complete in around two seconds, but the status tracker can lag by roughly 1–15 seconds while it indexes the deposit. Give it a minute, then refresh. The Across V3 intent specification separates the fill from later settlement: relayer repayment happens behind the scenes, so you do not need to wait for settlement to use tokens that have already arrived.
Check the deposit before taking action
Start with the transaction hash from the wallet you used to send the deposit. Confirm on the origin chain’s block explorer that the transaction succeeded, then check the bridge’s status tracker using that hash. If your route was a persistent deposit address, the first transfer may still be waiting to be swept into a bridge deposit, so check that flow’s status too.
Read the status and destination transaction details this way:
- Pending: the deposit is recorded, but the relayer fill is not yet reflected.
- Filled: open the fill transaction on the destination chain and check the recipient address and token.
- Expired: the fill deadline passed without a fill; the refund process can begin.
- Refunded: check the refund transaction and the address that received the funds.
A common mistake is to search only the origin chain for incoming tokens, or to assume the bridge is stuck because the destination wallet has not updated. Check the destination chain and the exact recipient in the deposit details. If your recipient differs from your connected wallet, the tokens may already be there; if the fill transaction is confirmed but the wallet balance looks stale, refresh the wallet’s token list or inspect the token contract on the explorer.
If you’re checking a transfer made through acrossbridge, use its recorded destination chain and recipient to make the comparison. A familiar token name alone is not enough: token addresses can differ between chains, and the tracker’s fill transaction is the useful evidence that delivery occurred.
What if the status stays pending or expires?
If it remains pending beyond the usual few seconds, keep the transaction hash and recheck after a few minutes. A slow fill can happen when a transfer is unusually large, the token pair is uncommon, or relayer service is temporarily constrained. Do not send another deposit just to “unstick” the first one; pending does not mean the funds have been released to you.
Once the fill deadline passes, the status may change to expired. That does not mean an instant refund: the expired deposit still sits in the origin pool while the protocol processes a settlement bundle. Across documents bundle proposals at roughly 1.5-hour intervals, and the bundle must pass a challenge period through UMA’s Optimistic Oracle before the refund is executed. Allow several hours for the refund to arrive, and check the recorded refund address.
When should you get help?
Contact the bridge’s official support channel if the origin transaction succeeded but the deposit cannot be found after several minutes, if a filled status has no matching destination transaction, or if an expired deposit remains unrefunded well beyond several hours. Include the origin transaction hash, chain, destination chain, and recipient address; never share your seed phrase or sign an unrelated recovery transaction.
I would wait and track a valid pending deposit rather than pay for a duplicate transfer. Decide differently if the origin transaction itself failed, or if the destination transaction shows a different recipient than you intended: those are separate problems, and the next step depends on the on-chain record rather than the pending label.