Across Bridge: The Destination Fill Test
Across bridge transfers are often described as “confirmed” the moment the source-chain transaction lands. That is the disagreement worth fixing: one camp treats that confirmation as completion; the other treats the destination-chain fill as the only result that matters. The second view is right for the person moving funds. Here, an Across bridge transfer means one deposited instruction whose stated token, amount, destination chain, recipient, and deadline must be matched before the recipient receives the output.
The first failed attempt usually comes from watching the wallet’s source-chain confirmation and then acting as if the assets are already usable elsewhere. For the actual route and transfer, use https://across.to/. What matters after submission is whether a relayer can fill the exact deposit instruction on the destination chain.
When the source transaction confirms but the destination balance is still zero
The transfer is not complete yet: the source confirmation proves that the deposit was accepted and escrowed, not that the destination delivery occurred. Across relayers front their own destination-chain funds, then receive reimbursement through later settlement. That separation is why a bridge can look confirmed in one explorer while the receiving wallet remains unchanged.
| Event | What it proves | What it does not prove |
|---|---|---|
| Source-chain confirmation | The deposit instruction exists | Destination funds arrived |
| Destination fill | The recipient received the specified output | Protocol settlement is finished |
| Later settlement | The relayer can be repaid and accounting reconciled | A new user action is needed |
If the quote and the deposited instruction no longer agree
The downstream path can fail before anyone has done anything visibly wrong. A relayer is not filling a vague request to “move USDC”; it is filling the recorded deposit parameters. A stale quote, changed amount after fees, wrong recipient, mismatched token, or missed fill deadline can turn a routine transfer into one that remains pending or expires.
The number people round off is the deadline. It is not cosmetic: it defines the period in which a fill can happen. Do not reuse old transaction data or assume a quote remains valid after waiting, changing networks, or modifying the amount.
When a transfer stays pending longer than the displayed expectation
Check status before resubmitting. Pending means no relayer has filled the deposit yet; it does not automatically mean funds are lost. Large transfers, unusual routes, congestion, or unavailable relayer inventory can make a fill unattractive or delayed.
- Match the source transaction to the intended origin chain and token.
- Verify the destination chain, recipient address, and expected output token.
- Wait for a terminal outcome:
filled,expired, orrefunded. - Do not send a second transfer merely because the first one is pending.
When no relayer fills before the deadline
The practical consequence is a refund path, not an instant reversal. An expired deposit can be refunded to the origin-side refund address after settlement processing, which can take hours rather than seconds. That is the part quick bridge explainers skip: fast delivery and final recovery run on different clocks.
The settled point: source confirmation starts an Across bridge transfer, but destination fill is the completion test. Treat the exact deposited instruction—and its deadline—as the dependency that decides every outcome after it.