Network congestion can slow a cross-chain transfer at either end. A transfer also needs proof from the sending chain and a transaction on the receiving chain, so “pending” can mean different things.
A transfer moves through several separate steps
A bridge first records your transfer on the source chain, the network where your tokens start. Depending on the route, tokens may be locked or burned, and the bridge creates a message that describes the transfer.
That message needs confirmation from the source chain before the bridge can safely act on it. In Wormhole’s wrapped-token route, Guardians, a network of validators, sign a proof called a VAA. The destination chain then uses that proof to release or mint tokens.
Each step can wait for a different reason. Your wallet may be waiting for the first transaction to enter a block; the bridge may be waiting for the source chain’s required confirmation; or the destination transaction may still need to be submitted.
Congestion delays the step that needs block space
Congestion means many users are trying to use a chain at once. Transactions compete for limited space in each block. On networks such as Ethereum, a higher priority fee can help a transaction compete for inclusion, but it cannot guarantee a specific time.
For example, imagine you send tokens from Ethereum while blocks are busy. Your wallet may show a pending transaction before the source transfer is recorded. After it is recorded, the bridge may still need to wait for the required confirmation before it can proceed. A quiet Base destination cannot remove a delay on Ethereum.
Congestion can also hit at the other end. The bridge may have finished its proof, while the transaction that delivers your tokens is waiting for space on the destination chain. So a slow transfer does not always mean the bridge itself is stuck.
The route and chain decide how long to allow
There is no single wait time that applies to every cross-chain transfer. It depends on the source and destination chains, the route, their current load, and the confirmation rules that route uses. A route that waits for stronger source-chain finality can take longer than one designed to complete quickly.
Portal Bridge offers different transfer routes, so a fast-transfer estimate does not describe every possible transfer. Some routes use intents, where a service fulfils the transfer across chains; others use wrapped-token transfers, where a signed proof supports release or minting on the destination. Check the selected route and its displayed estimate before sending.
Congestion can raise the source transaction’s network fee if you choose a higher priority fee. A destination transaction may also require a network fee, especially if you must complete it yourself. These are separate from any route or service fee shown before you confirm.
Check the transaction before trying again
Start with the source transaction hash, the unique ID for the transaction on the sending chain. Open it in that chain’s block explorer and check whether it is pending, confirmed, or failed. If it failed or never entered a block, the transfer did not start successfully.
If the source transaction is confirmed, do not send the same transfer again just because the destination balance has not changed. Check the bridge’s transfer status or Wormholescan for the next step. If a proof is ready but delivery is incomplete, the route may need a destination transaction or a manual completion.
For a Portal Bridge transfer, use the source transaction hash to check its progress and resume the transfer if the interface offers that option. Make sure you have the destination wallet selected and enough of that chain’s native token for any required transaction fee. If the source transaction failed, only retry after checking the amount, destination address, and current fee estimate.
Top comments (0)