Why a Swap Tracker Can Miss One Leg

A swap tracker can miss a leg because a cross-chain swap is a sequence of transactions, not one transaction with a single status. The source chain records the inbound transfer, the protocol records its action, and the destination chain records the outbound transfer. Each record has its own transaction identifier and confirmation rules. A tracker that indexes one chain, route or stage can show a partial history even while the rest of the swap is visible elsewhere.

Start with the route the swap actually took. A user interface may offer multiple protocols or paths, and the route determines which network records the swap and which explorer can resolve it. For the destination-chain checks behind that choice, see thor swap. Then treat the source transaction hash as the starting point, not proof that every later leg has completed.

Why does a swap tracker show only one leg?

A tracker shows only the records it can associate with its route and data sources. In a THORChain swap, the source-chain transaction sends the asset to an inbound address and carries a memo that encodes the requested action. THORChain observes that transaction, processes the swap through its pools, and schedules an outbound transaction on the destination chain. Those stages are related, but they do not share one universal transaction hash.

The source transaction can therefore be confirmed while the destination transfer has not yet been broadcast. A tracker may label the swap as pending, display an inbound record without an outbound hash, or fail to find it if the search expects a different identifier. An indexed action record can connect input and output details to the inbound transaction, while the destination chain’s explorer is needed to confirm the actual outbound transfer.

Streaming swaps add another distinction. The protocol can process a swap in multiple intervals rather than one execution, so a progress view may represent work still being processed rather than a missing chain transaction. The tracker’s label is an interpretation of indexed state; it does not replace the underlying transaction records.

How do you trace the missing leg?

Follow the identifiers from the earliest confirmed record. For a THORChain route, THORNode’s transaction-status endpoint reports stages for an inbound transaction, while Midgard’s actions endpoint returns an indexed action record with input, output and fees. These answer different questions: the status endpoint describes protocol progress, and the action record summarizes the indexed swap. Neither alone proves that the destination-chain transaction has reached confirmation.

• Open the source-chain transaction and verify the destination address, asset amount and memo. The memo identifies the requested action and destination.
• Use the inbound transaction ID to query protocol status. Check whether the transaction was observed and whether swap processing or outbound scheduling has advanced.
• Look up the related action record. Compare its input and output assets with the route and destination address shown by the interface.
• If an outbound transaction ID is present, search that hash on the destination chain. Confirm the recipient and final token there.

Keep the chain context with every hash. A Bitcoin transaction ID cannot be searched as an Ethereum transaction, and a protocol-level identifier may not be the destination-chain hash. For UTXO chains, inspect the output that paid the receiving address; change outputs belong to the sender and are not evidence of delivery.

When is a missing leg a delay, and when is it a failure?

A missing explorer result does not by itself establish failure. The source chain may still be confirming the inbound transaction, the protocol may still be processing or scheduling the swap, or the destination transaction may not yet be indexed by the tracker. Poll at a pace that reflects the source chain’s block production, then use the protocol status and destination explorer to locate the stage that has stopped advancing.

There are meaningful failure cases. A malformed or invalid memo can prevent the intended swap action; THORChain’s documentation says invalid memos are refunded. A destination address must also match the target asset’s chain, and a swap that cannot satisfy its price limit may not complete as requested. In those cases, look for a refund or protocol error record instead of assuming the output leg is merely late. Do not send a second swap just because one tracker returns no result.

For most readers, the reliable method is to trace the route stage by stage and verify settlement on the destination chain. The confirmed facts are the source transaction, protocol status, action record and destination transaction when each is independently visible. A tracker’s blank field or pending label alone leaves the cause unverified.