A bridge transfer can stay pending for roughly 13 minutes while an Ethereum block reaches protocol finality, but a bridge’s own confirmation policy can extend that wait. First identify which stage is pending: the source transaction, the bridge’s message processing, or the destination transaction.
These stages are separate because a bridge generally waits for source-chain evidence before authorizing a destination action. For example, what Manta bridge does across chains matters when a transfer combines a bridge and a swap: the source asset must arrive and the destination action must execute. Manta bridge is a cross-chain bridge and swap service; the same staged model helps explain a delayed transfer there.
Use the transaction state to locate the delay
- Pending on the source chain: the transaction has not been included in a block.
- Confirmed on the source chain: the bridge may still be waiting for its required confirmations or message verification.
- Destination action submitted: the bridge has progressed, but the destination transaction may be queued or failed.
- Failed receipt: that transaction executed and reverted; it will not succeed later by waiting.
A pending source transaction usually means the network has not included it, often because its fee offer is below current demand. A wallet’s pending label is not proof that the bridge has received anything.
After inclusion, the source transaction can still be short of the bridge’s confirmation threshold. Bridges may rely on a validator quorum, a light client, or an external attestation system; each must accept the source event before the destination action is authorized. The threshold varies by bridge and chain.
Once the destination transaction is submitted, check its own hash and receipt. A completed source transaction does not by itself prove that the destination transfer or swap completed.
A failed receipt is different from a pending transaction: the chain recorded execution, but the contract reverted. The source transaction’s nonce is consumed, and gas is charged for work performed even though the requested state change did not succeed.
Check what the source transaction actually did
Open the source transaction in a block explorer and verify its sender, destination, value, input data, nonce, block inclusion, and receipt status. For a token transfer, confirm the token contract and event logs; a displayed asset symbol alone is not enough to identify the token.
If the receipt status is successful, check whether the expected bridge contract emitted the relevant event and whether the amount matches the intended transfer. A successful transaction to an unrelated address, or one that called a different function, is not evidence that the bridge accepted the deposit.
If status is failed, inspect the revert reason or trace if available. Common causes include insufficient allowance, a minimum-output check failing after price movement, a deadline expiring, or a contract rejecting an amount or route. The receipt may not expose a readable reason; a trace can show the internal call that reverted.
For an Ethereum transaction with status 0, the fee is based on gas actually used multiplied by the effective gas price. The unused portion of the gas limit is not charged, but the failed execution still costs ETH. Repeating the identical call with identical parameters will usually reproduce the same failure.
Choose between waiting, replacing, and retrying
Wait when the source transaction is included successfully and the bridge is still within its expected confirmation or processing window. Compare the source block and event with the destination status using the bridge’s transaction reference, if one is provided. A busy destination chain or delayed attestation can leave a transfer between chains without requiring a second source deposit.
If an Ethereum transaction remains pending, inspect the sender’s confirmed nonce. Transactions from one account are processed in nonce order, so a stuck lower nonce can hold up later transactions. To replace it, send a transaction with the same nonce and a higher fee; many nodes require both the EIP-1559 max fee and priority fee to rise, often by around 10%, though the required bump varies by node and wallet.
A replacement with the same nonce is an alternative to the original, not an additional transaction. If the replacement is a cancellation sent to yourself, it can prevent the original from executing if the cancellation is mined first. But until one transaction is included, the original may still win. Check the final receipt before treating either as settled.
Retry a bridge transfer only after confirming that the source transaction did not succeed, or after using the bridge’s documented recovery path for a confirmed source event with no destination result. If the source event succeeded, a second deposit can create a second transfer. For a failed destination swap, check whether the bridge recorded a recoverable message or returned the bridged asset before initiating a new route.
Answers to two common follow-up questions
How long should I wait before contacting the bridge?
Use the bridge’s stated processing window, not a generic chain block time. If the source event is final but the destination transaction has not appeared after that window, record both transaction hashes, the source and destination networks, token contract, amount, and any message identifier. Those details distinguish a delayed message from a failed destination execution.
Can I submit the transfer again while it is pending?
Only if you have established that the original source transaction was never included or was replaced. If it has a successful receipt, submitting again can duplicate the transfer. A pending label alone is ambiguous: check the nonce and transaction history, then confirm whether the bridge’s source event exists before retrying.
- Locate the transaction stage: source, message processing, or destination.
- Verify the source hash, nonce, receipt, and bridge event.
- Wait for a confirmed source event that is still inside the bridge’s processing window.
- Replace only a genuinely pending transaction, using the same nonce and an adequate fee bump.
- Retry only after ruling out a successful source deposit; use recovery for a confirmed transfer with a missing or failed destination action.
Top comments (0)