Why Swap Integrators Must Track Both Sides of a Trade

Integrators must track both the source and destination sides of a swap because submitting one transaction does not prove that the user received the expected asset. On a single chain, execution and settlement may appear as one compact flow; across chains, the source can succeed while the destination is still pending, delayed or unable to complete. Reporting success at the first step makes the interface simpler, but it can misstate what happened to the user's funds.

This distinction matters for any cross-chain route, including a thor swap, where the route may involve separate transactions and different confirmation rules. The route choice affects how a swap is executed; tracking both legs determines whether an integrator can describe its outcome accurately. A fuller comparison of route choices helps with the first question, but the operational record must follow the swap through to its destination.

Why does a source transaction not prove the swap is complete?

A source transaction proves only what the source chain recorded. It may show that the user's input was accepted, spent or transferred into a route. It does not, by itself, establish that the destination chain processed the corresponding action or that the intended output reached the user.

That gap is normal in a cross-chain flow. Each chain has its own transaction history and confirmation process; the systems do not share a single atomic commit that makes every step succeed or fail at once. The source can reach a settled state while the destination action remains in progress. A route may also take longer than the interface's initial estimate, or encounter a failure after the source transaction has already become irreversible.

By contrast, a same-chain swap can often be treated as one transaction: the application can inspect its final status and relevant execution data on that chain. Even there, a submitted transaction is not the same as a confirmed one. Cross-chain integration adds another state to check: whether the destination leg has completed and what it delivered.

What should an integrator record for each side?

Record enough information to connect the user's request to both chain records and to reconcile the result. A source transaction identifier alone is not a complete swap record. The destination may have a different transaction identifier, and the relationship between the two needs to be retained by the application or service tracking the route.

A useful record follows the swap as a state machine rather than a single success flag. For example, the user-facing status can distinguish a request that has not been submitted, a source transaction awaiting confirmation, a route in progress, a destination transaction awaiting confirmation, and a completed or failed outcome. The labels can vary, but they should reflect observable events. Avoid marking a swap complete merely because the source-side transaction was accepted.

• Source details: the input asset and amount, source chain, transaction identifier and confirmation status.
• Route details: the identifier or reference that links the source activity to the intended destination action, where the route provides one.
• Destination details: the destination chain, transaction identifier, output asset and amount, plus confirmation status.
• Reconciliation: the expected output, actual delivered amount, and any route or network costs the integration can reliably observe.

Keep estimates separate from observed results. A quote describes what the route is expected to deliver under its stated assumptions; the destination record describes what actually arrived. The difference can reflect execution conditions, fees or a route-specific outcome. Showing the estimate as if it were a settled amount hides that distinction and makes support harder when users compare their wallet balance with the original quote.

How should the interface handle delays, failures and retries?

The interface should report each leg's state plainly and keep a pending swap visible until the destination outcome is known. A source-side confirmation can justify saying that the input was accepted, but not that the swap finished. If the route is still processing, say so; if the destination transaction failed, distinguish that from a source transaction that never confirmed.

Retries need care because the original source transaction may already have succeeded. Resubmitting the user's original instruction as if nothing happened can create a second swap or duplicate action. Before offering a retry, check the existing route record and its latest observable state. Where the system can safely resume monitoring or retry a later step, make that different from asking the user to submit the full swap again.

There is a trade-off between giving users immediate reassurance and avoiding a false final status. Frequent polling can make the interface feel responsive, but it does not make the underlying route settle faster and can add service load. A clear pending state, backed by reliable updates and a way to find the transaction records, is more useful than repeated optimistic success messages. For unresolved cases, explain which side is still unconfirmed and what action, if any, the user can take.

The practical rule is simple: treat the swap as complete only when the destination side provides evidence of the result, and preserve the source record so the two can be reconciled. Integrators should watch for the source confirmation, the route's progress signal, the destination transaction and its confirmation, then compare the delivered amount with the quote. Those are the events that turn a submitted swap into a defensible report of what the user received.