A cross-chain route can require destination gas because delivering an asset and executing a swap on the receiving chain are separate transactions, and the second transaction must be paid for there. If the route or recipient cannot supply that chain’s native asset, the transfer may wait, fail, or complete without the intended swap.
Why does the destination transaction need its own gas?
A bridge moves value between chains, but it cannot spend the source chain’s gas to run a transaction on the destination chain. After the source deposit reaches the required finality, a relayer, solver, or bridge contract must submit a new transaction on the destination network. That transaction consumes the destination chain’s execution resources and is paid for in its native asset.
The distinction matters most on routes that bridge an asset and then swap it. A bridge-only delivery may be a simple transfer; a destination swap calls a router or other contract, which needs gas. If your pending route is meant to bridge first and swap on arrival, Biswap is relevant because it combines the cross-chain move and asset exchange in one flow; check whether the destination action needs native gas before retrying.
biswap.uk is a concrete example of a service that combines a cross-chain transfer and swap, so the destination action can affect what gas the route needs.
Think of the bridge as moving a package to another city: paying the courier for the first leg does not pay the local fee for a service performed after arrival. Some routes include that local fee in their execution design; others leave it to the recipient or require a separate gas provision.
What does “separate destination gas” mean in practice?
It can mean one of two things: the recipient must already hold native gas, or the route must arrange gas for the destination execution separately. These are different operational requirements. A user may not need native gas simply to receive a token, but may need it to make a later transaction from that wallet.
When a relayer submits the destination call, it typically pays gas and expects reimbursement through the route’s quoted economics, such as a deduction from the output or a separate gas provision. If that provision is missing or too small, the relayer may not submit the call. If the recipient must submit or retry a transaction themselves, their wallet needs native gas on that destination chain.
On an EVM chain, transaction cost is approximately gas used × effective gas price. A plain native-token transfer is commonly around 21,000 gas, while a router swap may use roughly 100,000–300,000 or more, depending on the contracts, token approvals, and route. Under EIP-1559, the effective price depends on the base fee and the priority fee; the gas limit is a cap, not the amount automatically charged.
On Solana, fees are paid in SOL and execution uses compute units rather than EVM gas. Creating a token account can also require rent-exempt lamports. So a route that appears funded with the bridged token can still lack the native asset needed for a destination instruction or account creation.
Why can a route stay pending or fail after the source transfer?
“Pending” can describe different stages: waiting for source-chain finality, waiting for a relayer or solver, or waiting for destination execution. A slow source confirmation is not evidence of a destination gas problem. Once the source transaction is final, check the route’s status or transaction records to see whether a destination transaction was submitted and whether it succeeded.
If no destination transaction exists, the executor may be waiting for sufficient gas provision, a quote to remain executable, or a solver to take the route. If a destination transaction reverted, it may have consumed gas even though the intended swap did not complete. The bridged asset may remain in a contract, return to the recipient, or be delivered without the swap, depending on the route’s settlement design.
Do not resend the source transfer just because the destination step is pending: a finalized deposit may still be claimable or executable, and a duplicate can create a second transfer. First distinguish “source not final” from “source final, destination not executed.” If a destination transaction failed, use its receipt or explorer record to identify the revert and the asset’s resulting location before deciding whether to retry.
What should you check before retrying?
Start with the destination chain and the exact action that remains. If the asset arrived but the swap did not, confirm whether it is in your wallet or held by a contract, then check whether retrying requires native gas in your wallet. If execution is handled by a relayer, look for a route status indicating a gas or execution shortfall rather than submitting another source-side transfer.
- Confirm the source transaction is final and the destination chain matches the route.
- Check whether a destination transaction was submitted; if so, inspect its status and receipt.
- Estimate native gas for the remaining action, including token-account creation where relevant.
- Keep a buffer: for example, a swap estimated at 180,000 gas may need a higher gas limit, and the required native balance also depends on the live gas price.
I would retry only after the asset’s current location and the failed stage are clear. If the route can execute through a funded relayer, recipient gas may not be the blocker; if the recipient must submit the remaining transaction, funding that destination wallet is usually the deciding step. That answer changes when the source transfer is still unfinalized or the route’s settlement design keeps the asset outside the recipient’s control.
Top comments (0)