Follow a Cross-Chain Swap from Deposit to Delivery

A BTC-to-ETH THORChain swap uses two liquidity pools. That means the swap has separate on-chain legs, even when a wallet presents it as one action.

To trace one, start with the transaction that sent the source asset, then follow the protocol’s processing and the destination-chain payout. A transaction hash is a record on one blockchain; it does not identify every step across all chains. The thor swap explanation covers the route in more detail, while the records themselves let you check what happened to a particular transfer.

What happens during a cross-chain swap?

A cross-chain swap exchanges an asset on one blockchain for an asset on another. The route depends on the protocol. In THORChain, supported assets connect through liquidity pools paired with RUNE, the network’s native asset.

For a BTC-to-ETH swap, the user sends BTC to a THORChain vault address on Bitcoin. The network observes the deposit and processes the trade through the BTC:RUNE pool, then the RUNE:ETH pool. It sends ETH from a vault to the specified destination address.

RUNE is part of the route, but the user does not need to receive or manually trade it. The protocol handles the two pool swaps as one operation from the user’s point of view. On the ledgers, however, the Bitcoin deposit and Ethereum payout are distinct transactions, with protocol activity between them.

This is different from sending a wrapped token through a bridge. A wrapped token represents an asset on another chain; a native-asset swap aims to deliver the asset on its own chain. Those designs have different mechanics, so check what the service says you will receive before tracing the route.

How do you trace the deposit and payout?

Start with the source-chain transaction hash, often called a transaction ID or txid. Open it in an explorer for that chain and confirm the asset, amount, destination address, and transaction status. A confirmed deposit establishes that the source-chain transfer was recorded; it does not by itself show that the swap has finished.

Next, use the swap interface or protocol explorer to find the related action. A memo or transaction record may contain the intended destination asset and address. Compare those details with the transaction you initiated. A similar amount alone is not enough to establish that two records belong to the same swap.

The outgoing transfer appears on the destination chain, so look it up with that chain’s explorer. Check that the recipient matches the address you specified and that the transaction is confirmed. Depending on the protocol and interface, you may be able to follow a link from the inbound record, or you may need to search by the recorded destination address or swap details.

Keep these details together while you follow the route:

• The source asset, amount, chain, and inbound transaction hash.
• The swap’s destination asset and the exact recipient address.
• The protocol status or action record that connects the inbound leg to the payout.
• The destination-chain transaction hash and its confirmation status.

Each chain has its own explorer and transaction format. A Bitcoin txid will not turn into an Ethereum transaction hash. The protocol’s action record or swap interface is the bridge between those separate public records.

What can delay or change the amount you receive?

The received amount can differ from a simple exchange-rate estimate because a swap has fees and price impact. Liquidity pools set the trade price based on pool balances. A larger trade relative to available liquidity can move the price more, a cost commonly called slippage.

Network fees also apply to sending on the source chain and delivering the output on the destination chain. Some interfaces show these costs separately, while others give an estimated amount after fees. Read the quote before confirming, including any minimum-output limit: it sets the least amount you accept, and a trade that cannot meet it may not proceed as requested.

Timing depends on the chains and the protocol’s processing. The deposit must be observed and confirmed before the network can act on it; the payout then needs confirmation on its own chain. A pending source transaction, protocol processing, or a busy destination network can therefore leave the legs at different stages.

If a transfer appears stuck, use the status for the exact swap and its source transaction rather than repeatedly submitting a new swap. Check whether the inbound transaction confirmed, whether the protocol recorded the action, and whether an outbound transaction exists. If there is no payout record, the protocol’s documented support route is the right next step; never share a seed phrase or private key to resolve a transaction issue.

For most readers, the clearest trace is a three-part record: confirmed deposit, protocol action, confirmed payout to the intended address. It shows where the route stands without treating separate chain transactions as one hash or assuming that a deposit alone means delivery is complete.