Bridge Fees, Finality Time, Slippage and Stuck Transfers

2026-08-12

Moving an asset from one chain to another is not one transaction. It is a transaction on the source chain, a wait while that transaction becomes hard to reverse, and a second transaction on the destination chain that somebody has to submit and pay for. Every fee you are quoted and every minute you spend waiting comes out of that sequence. This article takes the sequence apart, and ends with how to work out where a transfer that has not arrived is actually sitting.

What a bridge fee is actually made of

A bridge quote arrives as one number, but it is paying for at least four separate things, denominated in different tokens on different networks. LayerZero's documentation splits its pricing into exactly those four components, and the shape is common to most designs.

The first is the source-chain transaction. Locking, burning or depositing your asset is an ordinary transaction on the chain you are leaving, priced by that chain's own fee market. Nothing about it is special, which also means no bridge can make it cheaper: if the source chain is busy, this part goes up.

The second is verification. Something has to attest that the source-chain event really happened, whether that is a validator set signing an attestation, a configured group of verifier networks, or an off-chain attestation service. That work is paid for, and the price scales with how much verification was asked for. More independent verifiers means a higher fee.

The third and fourth both sit on the destination side. Somebody has to submit the destination transaction, and that transaction consumes destination gas. The party that submits it is usually called a relayer or an executor, and it charges for the service. The gas itself is bought in advance, which is the part most people find strange.

Why you prepay destination gas, and what a gas drop is

You cannot pay for a destination-chain transaction with destination-chain tokens you do not have yet. That is the whole problem: you are arriving on a network where your address may hold nothing at all. So the quote converts destination gas into source-chain tokens and charges you for it up front.

The conversion runs on three inputs: how much gas the destination call needs, what gas costs on the destination chain at that moment, and the market price ratio between the two chains' native tokens. Change any one of them and the fee changes without you touching anything, which is also why the same message costs a different amount in each direction.

Some routes go further and deliver a small amount of the destination chain's native token to your address alongside the asset. Wormhole's automatic relayer, for instance, queries the destination contract for that native amount, includes it in the delivery and refunds whatever is left over. This is usually called a gas drop or a native drop.

It matters more than it sounds. Arrive on a new chain holding the asset and none of its native token and you own something you cannot move, because moving it needs gas you do not have. Check before you send whether the route includes a gas drop, or send yourself a small amount of native token first.

Where slippage comes from, and where it does not

For this purpose bridges fall into two families, and only one of them has slippage. In lock-and-mint and burn-and-mint designs the amount is written into the message: burn a quantity here, mint the same quantity there. No pool is being priced, so there is no price impact on the amount itself.

Pool-based routes work differently. You pay into a pool on the source chain and are paid out of a different pool on the destination chain, and what you receive depends on how those pools are stocked. Stargate's documentation defines its transaction fee as the difference between what the user puts in on the source chain and what arrives on the destination chain, and it pays rebates on pathways where demand has drained the pool.

So on a pool-based route the figure labelled as the amount you receive is a quote at that instant, not a promise. Between the moment you sign and the moment the destination transaction executes, the pool can move. That is what a minimum received or a slippage tolerance setting is for: it is the level below which you would rather the transfer not complete at all.

Two habits follow. Read the amount that arrives rather than the headline fee, because the arriving amount already contains everything. And keep swapping separate from bridging in your head: if the route also converts one asset into another, that leg carries its own price impact and belongs to the swap, not to the bridge.

Finality is what the waiting is for

The minutes you spend watching a progress bar are usually not the bridge being slow. They are the bridge refusing to release value on the destination until the source-chain transaction is hard to reverse. Release too early and a reorganisation on the source chain can leave assets minted on one side that were never really burned on the other.

How long that takes is a property of the source chain rather than of the bridge. Ethereum's proof of stake runs on 12-second slots grouped into epochs of 32 slots, and a block is finalised only once checkpoint votes representing two thirds of the staked ETH have accumulated, so finality is counted in epochs rather than in blocks. Wormhole's published finality table puts Ethereum at roughly 19 minutes, Solana at about 14 seconds and Avalanche at about 2 seconds.

Rollups are where intuition fails. A transaction on a rollup confirms in seconds, but its finality is inherited from the chain the rollup posts to. Circle waits for the Ethereum block containing an OP Stack batch to finalise, which its documentation puts at roughly 65 blocks, or 15 to 19 minutes after the batch is posted; the same page gives 6 to 32 hours for standard transfers from Linea and 4 to 8 hours from Starknet.

This is also why fast paths exist and why they are capped. Circle attests fast transfers after a couple of confirmations, in the range of 8 to 20 seconds, and subjects them to a global allowance precisely because they accept reorganisation risk that waiting for hard finality does not. Speed here is not an optimisation, it is a risk setting that somebody chose.

Why the same route is not always the same wait

There are two separate waits and they fail differently. The first is the source-side finality wait, set by the source chain and by the security level the route was configured with. The second is inclusion on the destination side: even once the message is ready, the destination transaction still has to get into a block, and a congested destination chain delays it.

Some routes add a third variable deliberately. Batching several users' transfers into one message spreads the messaging cost across all of them, so it is cheaper, but the batch has to fill up or a timer has to expire before it departs. Stargate documents exactly this trade-off between its batched and its immediate transfer modes. Cheaper and slower is a choice you are making.

A quoted time is therefore a typical case rather than a guarantee, and the same pair of chains can behave differently through two different routes because their integrators chose different finality settings. Wormhole tells integrators plainly that selecting anything other than finalised increases exposure to reorganisation risk.

Before you press send, write down five things: the source transaction hash, which bridge or route you used, the destination chain and address, the quoted amount out, and the quoted time. Without the hash you cannot check anything at all, and it is the item people most often fail to keep.

Bridge fees, finality time and slippage: the four fee components, what sets the wait, and the three stages a transfer that has not arrived can be in

Where a transfer that has not arrived is sitting

When nothing has shown up, the useful question is not how to get the money back. It is which of three stages the transfer is in: has the source chain confirmed it, has the message been verified, and has the destination chain executed it. Each stage has a different answer, and you can check all three yourself with public tools.

Stage one is the source chain. Open the source chain's block explorer, paste your transaction hash and read the status. Still pending means it has not been included yet. Dropped means nothing ever left the source chain and your asset never moved. Reverted means the transaction failed on the source chain, so the asset stayed where it was, although the gas was still spent.

Stage two is the message. The source transaction is confirmed but the destination is quiet, which usually means you are inside the finality window described above, and the honest answer is to wait out the interval that chain requires. Most bridges run a message explorer of their own where you can look up whether the attestation for your transfer has been produced. Some designs also allow manual completion: Wormhole's documentation describes the user submitting the signed attestation themselves, and adds that a manual transfer should be completed within 24 hours, because after that the validator set may have changed and the signatures may need replacing before the destination will accept them.

Stage three is the destination. If a destination transaction exists but reverted, the usual causes are too little gas allocated for the destination call, or a receiving contract that rejected it. Because several designs keep verification and execution as separate steps, this case can often be retried on the destination without resending anything from the source, and the message explorer entry is where you find out whether a retry is available.

Then the part nobody wants to write down: some outcomes have no undo. A confirmed on-chain transfer cannot be reversed by anyone, and if the asset landed on a chain or at an address you do not control, no procedure gets it back. That gap is exactly what recovery services advertise into. The FBI has warned that such operations charge an up-front fee and then either stop replying or produce an inaccurate tracing report and ask for more, often claiming an affiliation with law enforcement, and it states plainly that private recovery companies cannot issue seizure orders. Read your own explorers, and do not pay a stranger who found you in a comment section.

The bottom line

A bridge fee is a source-chain transaction, the cost of verifying that it happened, a relayer's fee for submitting on the other side, and destination gas bought in advance at the two chains' price ratio. The waiting is the source chain reaching finality, which is a property of that chain and of the security level the route chose, and rollups inherit theirs from the chain underneath. Slippage appears only where a pool prices your payout, so read the amount that arrives rather than the fee. And when a transfer has not landed, locate it rather than mourn it: source confirmed, message verified, destination executed. Three explorers answer that question, and nobody who contacts you first can answer it better.

Disclaimer: This article is educational content from Bitbase Academy, provided for information only. It does not constitute investment, trading, tax, or financial advice. Crypto assets are volatile; assess your own risk. Written as of August 2026; refer to the latest official information.