A Cross-Chain Swap Is Complete Only After Destination Execution

A cross-chain swap is complete when the destination chain records the promised output for the intended recipient, and that transaction has reached the chain’s required finality. A successful source-chain transaction proves only that the initial call succeeded. It does not prove that a bridge message was relayed, a liquidity provider filled the transfer, or a destination swap executed.

First identify the route’s mechanism. A lock-and-mint bridge waits for a message that releases or mints assets on the destination; a liquidity route may have a relayer pay the recipient before the source deposit is settled; a composed route may also execute a swap or contract call after delivery. For interface-specific steps, see this fuller guide to using ParaSwap for a cross-chain swap. In every case, check the destination result against the quote: the correct chain, token, recipient and minimum output.

What does a confirmed source transaction prove?

A confirmed source transaction proves that the source-chain call was included and executed according to that chain’s rules. Its receipt status, where available, indicates whether the call reverted. It does not establish that the cross-chain leg has finished.

Inspect the source transaction’s logs or protocol event to confirm that it initiated the expected transfer. Match its sender, destination chain, input token, amount, recipient and any route identifier to the intended swap. A wallet’s “success” label may describe only this transaction. An approval transaction is further removed: it grants spending authority and is not the swap itself.

In a message-based bridge, a verifier or relayer must observe the source event and deliver a corresponding message or proof to the destination contract. The destination contract then applies its own validation rules before releasing assets or running a call. In a liquidity-based route, a relayer may instead call a destination contract that pays the recipient from available inventory. These designs have different settlement paths, so “source confirmed” and “destination filled” are separate states.

Do not treat a quoted arrival time, wallet animation or pending status as execution evidence. Estimates describe expected processing; they are not an on-chain event. A source transaction can succeed while the destination operation remains pending, fails, expires or enters a refund path.

How do you verify the destination leg?

Find the destination transaction associated with the source transfer, then inspect its receipt and logs on the destination chain. A route tracker or protocol status endpoint can help locate that transaction, but confirm the result on-chain when the value matters.

Check these fields before marking the swap complete:

• Destination chain: the transaction belongs to the chain named in the route, not merely a chain with a similarly named token.
• Recipient: the intended wallet or contract received the output. Some routes pay a router or settlement contract first, so trace any subsequent transfer or call to the final recipient.
• Output asset and amount: the destination token address is correct, and the delivered amount meets the quoted minimum after route fees and swap execution.
• Execution result: the destination transaction succeeded and emitted the expected fill, transfer or application event. A transaction that reverts is not a completed delivery.

Token symbols are not sufficient identifiers. The same symbol can refer to distinct contracts on different chains, and a wrapped or bridged representation may not be interchangeable with the asset expected by a later application. Compare contract addresses and chain IDs. For a composed swap, verify the final token and recipient after the destination call, not just an intermediate bridge token.

Explorer balances can be useful, but a balance increase alone may be ambiguous if the wallet received other transfers during the same period. The destination transaction’s logs provide stronger attribution. Match the relevant transfer or protocol event to the route’s recipient, token and transfer identifier where one exists.

When is a pending swap actually finished?

A pending swap is finished when the protocol reports its terminal success state and the corresponding destination execution is verifiable at the finality level appropriate to that chain and route. A tracker’s “filled” state usually means the destination delivery occurred; it does not necessarily mean every later accounting or relayer reimbursement step has settled.

That distinction matters in liquidity-based systems. A relayer can pay the user on the destination chain first, while protocol settlement later reconciles the fill and repays the relayer. The user-facing delivery may be complete before that background accounting finishes. Conversely, a tracker can show a provisional fill while the destination transaction is not yet sufficiently final for the user’s risk tolerance.

If the route reports pending, keep the source transaction hash and any transfer or deposit identifier. Check the protocol’s status method and destination explorer for a fill, failure, expiration or refund. Do not submit a second swap just because the first has not appeared in the wallet; the original transfer may still execute. If the route expires, verify the documented refund conditions and the chain and address where any refund is sent.

For most readers, the practical rule is simple: treat the source receipt as proof of initiation, and the successful destination execution as proof of delivery. A ParaSwap screen can help follow a route, but the completion check remains the destination transaction, recipient and output asset. What is confirmed is the state recorded by the relevant chain and protocol; a pending status, estimated time or unverified interface message does not establish that the swap completed.