When an Exchange Pair Disappears, Compare the Cross-Chain Route

When an exchange pair is unavailable, you may be able to trade the same assets through a cross-chain swap if the protocol supports both. That changes the route: instead of placing an order on one exchange, you send the asset you hold from its native chain and receive the target asset on its chain. A shared liquidity network can make that possible without first depositing to a centralised exchange or manually bridging a token. The trade-off is that availability depends on supported assets and live liquidity, while execution involves transactions on two blockchains and fees at both ends.

Before choosing that route, identify why the pair is missing. An exchange may have paused deposits, withdrawals or trading; an asset may be delisted; or a direct market may simply lack buyers and sellers. Those are different problems. A swap protocol can provide another route for supported assets, but it cannot restore a disabled exchange market or make an unsupported token tradable. This thor swap guide covers the wallet flow in more detail; the key decision here is whether its route delivers a better net result than the alternatives.

How does a cross-chain swap replace a missing pair?

A cross-chain swap uses a protocol that can receive one asset on its source chain and send another on its destination chain. In THORChain’s design, for example, pools pair supported assets with RUNE, the network’s shared settlement asset. A swap between two supported assets is routed through those pools: the protocol exchanges the input for RUNE, then RUNE for the requested output. The user does not need to hold RUNE to make the trade.

This is different from a conventional bridge route. A bridge generally moves or represents an asset across chains, after which the user still needs a market on the destination chain to exchange it. A cross-chain liquidity protocol handles the exchange as part of the route. For supported assets, THORChain’s pools are designed to settle in native assets rather than requiring the user to receive a wrapped version first.

That convenience has limits. The protocol must support the exact asset and chain combination, and the relevant pools need enough depth for the trade. A token with the same ticker on two networks is not necessarily the same asset. Confirm the chain and token address where relevant, and check the quote’s expected destination asset before signing. If either side is unavailable, the missing exchange pair remains missing; changing the interface does not create liquidity or add protocol support.

What should you compare before signing the swap?

Compare the amount you expect to receive after costs, rather than comparing headline prices. A quote should account for the estimated output, pool price impact and fees. THORChain’s documented fee model includes the source-chain transaction fee paid by the user, a liquidity fee that varies with trade size and pool depth, and a destination-chain outbound fee taken from the output. Some interfaces may also charge an optional affiliate fee. The wallet’s network-fee estimate and the interface’s fee display are separate parts of the total.

Check the quote immediately before signing. It can expire or change as pool balances and network conditions move. A large trade relative to pool depth can have greater price impact than a small one. Some THORChain swaps can be streamed into smaller executions over time to reduce price impact, but waiting can expose the trade to further price movement. A minimum-output limit can set a floor for what you will accept; if the route cannot meet it, the swap may be refunded, with costs associated with the source-chain transaction and refund process.

• Confirm the exact input and output assets, including their chains.
• Compare estimated output after fees with the amount you would receive through other available routes.
• Check the price impact, minimum output and any optional interface fee.
• Make sure the wallet can pay the source-chain transaction fee and that you control the destination address.

For a small trade, a cross-chain route may be poor value if network fees make up a large share of the amount. For a larger trade, deeper pools or streamed execution may improve the price, but the quote still depends on current liquidity. A same-chain decentralised exchange can be simpler when both assets already exist on one network with adequate liquidity. A centralised exchange may offer a direct market, but usually requires an account and a deposit, and its pair may be unavailable for the same operational reason that prompted the search.

When is this route the better choice?

A cross-chain swap is useful when the direct pair is absent, both assets are supported, and the quoted net output compares favourably with a practical alternative. It can remove the need to make a separate bridge transaction or route through an exchange account. It does not make a trade risk-free: pool prices can move, settlement takes time, and each chain’s transaction rules still apply. The user signs the source transaction, while the protocol’s nodes observe it and arrange the outbound transaction after processing.

For most users, the sensible test is straightforward: verify the asset and chain, compare the net output and fees, set a minimum you are willing to receive, and sign only if the route meets that threshold. Keep enough of the source-chain native coin for the wallet transaction fee. If the quote is unclear or the destination asset does not match, stop and check the route rather than relying on a ticker or a displayed spot price.

The signals to watch are the exact assets the protocol supports, pool depth for the route, the quoted output after all fees, the minimum-output setting and the time the quote remains valid. If those change, compare the route again before sending.