A Confirmed Source Transaction Is Not a Completed Cross-Chain Swap

A confirmed source transaction proves that the origin chain accepted a deposit; it does not prove that the destination chain delivered the requested asset. A cross-chain swap usually has separate source and destination transactions, joined by a message, liquidity provider, or relayer. The source receipt is evidence of initiation. Completion requires a successful destination-side fill or execution.

What does source-chain confirmation prove?

Source confirmation proves that a transaction was included in the origin chain and its contract call succeeded. In Across’s V3 model, the user calls depositV3() on the origin SpokePool, which escrows the input tokens and emits a V3FundsDeposited event with the destination chain, output token, amount, and recipient. That event records an intent; it does not itself move tokens on the destination chain.

Wallets and explorers often label the source transaction “confirmed” when it has been included in a block. Some applications wait for additional chain-specific finality before treating the deposit as settled enough to act on. Either way, the label describes the source transaction, not every later step. For more on route design and token movement, see fermi swap.

What must happen on the destination chain?

A relayer or other executor must submit a separate transaction that fulfills the intent on the destination chain. In Across V3, a relayer calls fillV3Relay() on the destination SpokePool using its own tokens. A successful fill emits FilledV3Relay and marks the intent filled. The user can then verify the fill transaction and check that the output reached the specified recipient.

This separation lets a relayer deliver funds without waiting for the source asset itself to travel through a slow bridge. It also means the two chains do not share one atomic transaction: source success can precede destination execution. Protocol settlement and relayer repayment may happen later still. Those back-office steps do not necessarily delay the user’s receipt of tokens.

Why can a fill fail or remain pending?

A source deposit can be valid while the destination fill is delayed, unavailable, or reverted. The route has to satisfy the intent’s parameters, including the destination chain, recipient, output token, and minimum output. A relayer must be willing and able to execute the fill. Expired deadlines, insufficient destination liquidity, a changed route, or a failing destination contract call can prevent completion.

• Pending: The source deposit is recorded, but no successful destination fill is visible yet.
• Filled: The destination transaction executed the intent; verify its receipt and recipient balance.
• Expired: The fill deadline passed without execution; check the route’s documented refund process.
• Reverted: The destination transaction failed, so a transaction hash alone does not prove delivery.

For a user, the practical check is to follow the transfer’s status or deposit identifier across both networks, then inspect the destination transaction and recipient balance. Do not treat a quoted output, submitted source transaction, or source-chain confirmation as proof that the swap finished. The confirmed fact is that the source contract accepted the deposit. Until a successful destination execution is verified, delivery remains unverified.