acrossbridge in 2026: How transfers work and get unstuck

Acrossbridge moves tokens between chains by recording a deposit on the source chain, having a relayer deliver funds on the destination chain, then settling accounts later. The sender chooses the amount, destination and recipient. A SpokePool contract records those instructions. Relayers watch for the deposit and one can fill it by paying out its own tokens on the destination chain. The recipient usually gets funds before that relayer is repaid.

The design is an intent: the user states the result they want, while the relayer handles the immediate delivery. For a plain transfer, the desired result is tokens for a recipient on another chain. The acrossbridge transfer still depends on the source transaction being confirmed and the destination chain processing its fill. Those are separate events, so a confirmed deposit does not by itself prove the recipient has been paid.

How does an acrossbridge transfer work?

An acrossbridge transfer starts when the wallet submits a transaction to the source chain’s SpokePool. That contract holds the deposit information: input token and amount, destination chain, output token and amount, recipient, and a deadline for the fill. The wallet may also need to approve the contract to use the tokens.

After the source transaction confirms, relayers can see the deposit. A relayer checks whether it can fill the order, then calls the destination chain’s SpokePool and fronts the output tokens to the recipient. Relayers compete to fill eligible orders. This is why the recipient can receive funds quickly without waiting for the protocol’s accounts to be balanced across chains.

Settlement happens afterward. Across groups fills and other activity into a bundle. The protocol uses that settlement process to reimburse relayers and move liquidity between its pools. Think of the relayer as paying the recipient from a till on the destination chain, then collecting from the wider ledger later. The analogy stops there: the actual process uses on-chain contracts, proofs and transactions.

Why can a transfer stay pending?

A pending transfer means the deposit has not yet reached a completed status; it does not identify the cause on its own. First, check the source transaction on the source chain’s block explorer. If it is pending or failed there, the deposit has not been successfully recorded. If it confirmed, use the deposit transaction hash or deposit ID to check Across’s status tracker.

A relayer may not have filled the order yet. Unusual routes, large amounts or temporary relayer unavailability can leave a deposit waiting. The fill deadline also matters: if it passes without a fill, the deposit may become eligible for a refund. Check the status before sending again, since a second deposit is a separate transaction and can result in a second transfer.

Use the status to decide what to do next:

• Pending: Confirm the source transaction succeeded, then keep checking the transfer status.
• Filled: Look up the destination transaction and confirm that the recipient and output token are correct.
• Expired: The fill deadline passed. The refund still needs settlement processing, so it may take several hours rather than arriving immediately.
• Refunded: Check the refund transaction and the address set to receive it, which may differ from the recipient.

What should you do if funds seem stuck?

Follow the transaction through both chains before taking action. Keep the source transaction hash, destination chain, recipient address and deposit ID together. Compare the recipient and token in the deposit with the wallet where you expect to see the funds. A transfer can be filled to the specified recipient while the sender is checking a different address.

If the source transaction confirmed but the tracker does not show the deposit, allow time for indexing, then check the transaction receipt and its contract events. If the status says expired, wait for the refund process and check the designated refund address. Do not share a seed phrase or private key with anyone offering to recover funds; neither is needed to check a transaction.

The key distinction is between delivery and settlement. A relayer can deliver tokens on the destination chain before it receives reimbursement, while an expired deposit follows a slower refund path. Checking the source transaction, current status and destination or refund address shows which part of the process needs attention.