A Bridge Can Refill After Your Transfer Is Already Complete

A cross-chain transfer can take seconds or wait for liquidity to return, depending on how the bridge delivers funds. In a relayer model such as Across, the recipient may be paid from a relayer’s destination-chain funds before the protocol replenishes that inventory; with a pool that must have destination assets available first, a shortfall can hold up delivery. The key is to tell apart the user’s fill from the bridge’s later accounting and rebalancing.

What does a liquidity refill mean for a bridge transfer?

A refill restores assets to a chain or pool after they have been used to pay transfers. Bridges need a way to match assets sent on one network with assets delivered on another, but they do not all do that in the same order.

Some bridge designs rely on destination-side liquidity being available when a transfer arrives. If demand has drawn down the relevant pool, the transfer may wait for a refill or another liquidity source. The delay depends on the bridge’s mechanism, the asset and route, and how quickly liquidity can be moved; “refill” alone does not imply a reliable countdown.

In a relayer model, a relayer can advance its own destination-chain tokens to fulfill a transfer, then receive repayment later through protocol settlement. Across describes its typical fills as taking about two seconds, while relayer repayment and pool rebalancing happen in the background. That means a refill can be important to the system’s next transfers without being something the current recipient must wait for.

For a practical walkthrough of the user steps, see this guide to using acrossbridge between chains. The timing question is separate: after submitting, check whether the destination fill has happened before treating later settlement as a delay to your own transfer.

How long should you expect to wait?

There is no single cross-chain transfer time: the useful estimate is the route’s expected fill time, plus any time required for the source transaction to be accepted. A fast relayer fill can put funds on the destination chain quickly, even though the protocol may take substantially longer to settle the relayer’s reimbursement.

When a transfer depends on destination liquidity being replenished before it can pay out, there may be no universal estimate. The bridge may need to rebalance inventory, wait for a liquidity provider, or use another settlement path. Network congestion and transaction confirmation also affect elapsed time. A quote or route status is more informative than a general claim that bridges take a certain number of minutes.

It helps to separate the stages:

• Source confirmation: the deposit transaction must be included and recognized on its origin chain.
• Destination fill: a relayer or pool pays the recipient, if the route supports that method and liquidity is available.
• Settlement and refill: the bridge reconciles transfers and restores inventory; this can continue after delivery.
• Refund or recovery: if a transfer expires without a fill, the bridge’s rules determine whether and how the source funds can be returned.

A pending status usually means the destination fill has not been recorded yet. A filled status means the destination leg completed; it does not necessarily mean the relayer has already been reimbursed or the underlying pools have been rebalanced. Those distinctions matter when a tracker shows activity continuing after the recipient can use the funds.

How does a refill delay compare with other bridge methods?

A liquidity-dependent pool may offer straightforward delivery when funds are on hand, but depleted inventory can make its timing less predictable. A relayer can decouple delivery from immediate pool replenishment by fronting capital, trading a faster user experience for the relayer’s cost of capital and later settlement risk. The recipient benefits from speed; the protocol still has to balance its books.

Canonical bridges use another trade-off: they generally wait for the source chain’s messages and security process to complete, rather than promising a relayer-funded near-immediate payout. That can mean a longer wait, especially where finality or a challenge period is part of the path, but the delay is tied to the bridge’s settlement process rather than simply to a refill arriving. A route that uses a third-party liquidity provider may be quicker, but its availability and fee can vary.

For most users who need funds promptly, a clearly quoted relayer route is the better fit when its output amount, fees and destination token match the need. A user who values the bridge’s security model or can wait may prefer a route that completes through canonical settlement. Compare the actual route and status, not just the names of the networks.

What should you check if the transfer is still pending?

Check the origin transaction first, then look for a destination fill in the bridge’s tracker or the relevant chain explorer. If the deposit is confirmed but remains unfilled, check the route’s expected fill time and whether the bridge marks it pending, expired or eligible for refund. A displayed refill or settlement event is not, by itself, proof that the recipient has been paid.

Before submitting, verify the destination network, recipient address, token and quoted output. If funds remain pending beyond the route’s stated estimate, use the bridge’s official status and recovery instructions; avoid sending a second transfer simply because the first has not appeared. The next signals to watch are the destination fill event, any expiry or refund status, and whether the route provider reports a liquidity constraint. Those tell you whether you are waiting for delivery or for the system to replenish itself.