Where Destination Gas Comes From in a Cross-Chain Message

A cross-chain message gets its destination gas reserved by setting a budget for the work on the receiving chain, then deducting an estimated fee from the swap output before the protocol broadcasts the call. The budget describes the execution resources requested; the reserve is the amount of destination asset set aside to pay for them. Those are related, but they are not the same thing.

In Chainflip, the message travels with a swap and tells a receiver contract or program what to do with the output. For example, the receiving program might use the swapped asset in another transaction. The source-chain deposit pays its own network fee separately; the destination reserve covers the later transaction that delivers the output and runs the requested logic.

What does the destination gas budget pay for?

The budget covers the receiver’s work on the destination chain, such as executing a contract call. The chain sets the unit: an EVM network measures gas, Solana uses compute units, and other networks may use a different resource measure. The message includes this requested budget when the swap is initiated.

The protocol also needs resources to verify and deliver the cross-chain message. It adds that overhead on top of the requested budget, so the amount available for the receiver’s logic is not swallowed by the protocol’s own transaction work. A useful analogy is booking a room for a meeting: the request includes the meeting space, while the venue needs extra room to get everyone through the door.

For a concrete example of the asset-conversion route, see how Chainflip swaps SOL for USDC. The destination budget is a separate setting: it pays for the follow-on call, not for converting the source asset.

How does the protocol calculate and set the reserve?

At initiation, the swap request carries the destination, receiver, message data and gas budget. The protocol uses the destination chain’s fee model to estimate the cost of broadcasting the transaction with that work included. It then subtracts the estimated fee from the destination asset that would otherwise be paid out.

The sequence is:

• The user or application supplies the message and requested destination budget with the swap details.
• The protocol adds its own transaction verification overhead to the requested work.
• It estimates the destination transaction cost and converts that cost into an amount of the destination asset.
• After the swap, the protocol deducts that amount from the output and broadcasts the transaction carrying the message.

This is a fee reserve in the payout calculation, not a second deposit the user must make on the destination chain. The protocol handles the broadcast, while the recipient receives the output after the estimated fee is taken out. The amount therefore depends on both the requested work and the destination chain’s transaction costs; it is not a universal flat fee.

What can make the reserve too small or too large?

The requested budget has to match the receiver’s actual logic. If it is too low, the destination transaction may not have enough resources to complete that logic. If it is higher than the call needs, the estimate can reserve more output than a smaller budget would. The application developer must know what the receiver does and choose a budget that gives it room to finish.

Costs also depend on the destination chain’s fee rules. EVM gas, Solana compute units and message-based fees are not interchangeable, so a budget for one destination cannot simply be carried over to another. The asset price and network conditions can also affect how much destination asset corresponds to the estimated transaction cost when the protocol calculates the deduction.

When reviewing a swap, check the destination, the receiver’s expected work, the requested budget and the output after fees. A simple transfer and a call that runs contract logic have different resource needs. The mechanism turns that extra work into a reduction in the payout before broadcast: the message gets a funded path to execution, and the next thing to watch is whether the selected budget still fits the receiver and destination chain.