Destination gas: how bridges fund the receiving-chain transaction

Destination gas is the native token a wallet needs to submit transactions on the receiving chain after a bridge transfer. A bridge can include that token in the delivery, convert part of the transferred value into it, or use a relayer to submit a destination transaction and recover its cost through the route’s fees. Which mechanism applies determines whether the recipient can act immediately or must first obtain gas separately.

The origin transaction and the destination transaction are distinct. The first authorizes and sends the source-chain assets; bridge infrastructure then processes the cross-chain transfer. If the route includes a swap or another contract call on the destination, that action also needs execution capacity there. Guides to combining a bridge with a swap, such as this Paraswap walkthrough of bridging and swapping in fewer steps, cover the user flow; the key technical question is how the route pays for the destination-side work.

What does destination gas pay for after a bridge?

It pays the receiving chain’s transaction fee, charged in that chain’s gas asset. On an EVM network, a wallet generally needs the chain’s native token to submit a transaction. A token balance alone does not pay this fee, even if the token arrived through the bridge moments earlier.

A plain bridge transfer may only credit the recipient with an asset. That credit does not necessarily trigger a second transaction from the recipient’s wallet: bridge contracts or relayers complete the delivery according to the route design. But if the user wants to swap the received asset, move it, or interact with an application, the wallet needs gas for that later transaction unless the application supplies a sponsored or relayed execution path.

“Destination gas” can describe two related things: a gas-token amount delivered with the transfer, or the cost of having a third party execute a destination action. They solve different problems. A gas-token top-up leaves the user with funds to transact; relayed execution pays for a particular call and may not leave the user with any spendable gas token.

How can a bridge provide gas on the destination chain?

A route can reserve part of the transfer for the destination gas token. It may swap a portion of the incoming value on the receiving chain, or calculate a gas amount and include it in the quote. The recipient receives less of the requested output asset because some value covers conversion costs, execution fees, and any route charge.

Another design uses a relayer, solver, or other service to submit the destination transaction. The service pays the chain fee when it executes, then gets reimbursed according to the route’s settlement rules. That reimbursement might be included in the quoted fee or deducted from the transfer. The user signs the origin transaction, while the third party handles the destination call; the exact authorization and settlement mechanism depends on the bridge.

Routes may also combine these methods. For example, a bridge can deliver the target token and have a relayer execute a destination swap, with the relayer’s cost priced into the transfer. A quote that says “gas included” therefore does not, by itself, tell the user whether they will receive native gas tokens. Check the output and execution details.

What changes when the bridge also performs a swap?

A bridge-and-swap route composes cross-chain delivery with a destination-side exchange. Instead of receiving the bridged asset and then submitting a separate swap transaction, the route encodes or arranges the swap as part of destination execution. This can save a wallet interaction and avoid requiring the user to hold destination gas beforehand, when the route supports relayed execution.

The composition adds dependencies. The bridge message must be delivered, the destination call must be executable, and the swap must have a valid route and sufficient liquidity at execution time. A quote is an estimate of the result under stated conditions, not proof that every later step has completed. If the bridge transfer succeeds but the swap call fails, the user may end up with the intermediate asset, depending on the contracts and failure handling. Some routes retry or provide a recovery path; others require a separate transaction, which still needs gas.

Compare the complete outcomes, not just the displayed token amount:

• Expected amount of the requested output asset after bridge, swap, and service fees.
• Whether the destination gas token is delivered, consumed by a relayer, or still required from the user.
• Which destination calls are included, and what happens if one reverts.
• Whether the quoted minimum output accounts for slippage and route fees.

How should a user assess a destination-gas quote?

First identify the action being funded. If the goal is only to receive tokens, determine whether the route needs a destination transaction at all. If the goal includes a swap or application call, check whether the quote explicitly includes that call and how it is executed. A gas allowance for the bridge’s own destination delivery does not automatically fund a later wallet transaction.

Then inspect the fee currency and net output. A route may charge in the source token, the destination token, or another asset supported by its design. Gas estimates can change with network conditions, and a quoted amount may include a margin or a relayer fee. If the route converts value into gas, the exchange rate and conversion fee affect how much output remains.

The practical choice is straightforward: for a simple transfer, a route that delivers the desired asset and clearly states any gas top-up is easiest to evaluate. For a transfer followed immediately by an on-chain action, bundled execution can remove the need to pre-fund the destination wallet, but it adds call and relayer dependencies. Destination gas is not a universal bridge feature; verify the route’s exact output and failure behavior before signing.