How a BTC-to-ETH Swap Route Moves Between Chains

A BTC-to-ETH swap route is the sequence of transactions and liquidity pools that turns bitcoin on the Bitcoin network into ether on Ethereum. On THORChain, the protocol routes the swap through two pools linked by RUNE: BTC first swaps into RUNE, then RUNE swaps into ETH. The user sends BTC and specifies an Ethereum destination; the protocol observes the deposit, executes the pool legs and arranges an outbound ETH transaction. The route uses native assets on their own chains, while protocol vaults custody assets during settlement.

What happens along a BTC-to-ETH route?

The route consists of an inbound Bitcoin transaction, two pool swaps and an outbound Ethereum transaction. A wallet or interface prepares a deposit address and transaction details, including any required memo. The user sends BTC to the protocol’s Bitcoin vault. THORChain’s observers detect the transaction and the network processes it under its state-machine rules.

Once the deposit is accepted, the BTC:RUNE pool exchanges BTC for RUNE. That RUNE becomes the input to the RUNE:ETH pool, which determines the ETH output. The two pool legs are often called a double swap; RUNE is the internal settlement asset, so the user does not need to acquire or send it. The final transfer is native ETH from a protocol vault to the Ethereum address specified for the swap.

The swap has one user-facing intent, but it is not one cross-chain transaction: Bitcoin and Ethereum each record their own transactions, and THORChain records the internal swap state. For a fuller account of how the interface presents this path, thor swap describes moving BTC to ETH across chains. The distinction matters when tracking progress: the Bitcoin deposit, protocol execution and Ethereum payout have separate transaction records.

How do the pools set the exchange rate?

Each THORChain continuous liquidity pool holds one connected asset and RUNE, supplied by liquidity providers. The pool ratio sets the trade price, and each swap changes that ratio. A BTC-to-ETH route therefore draws liquidity from both the BTC:RUNE and RUNE:ETH pools; the quoted output reflects both legs, rather than a direct BTC/ETH order book.

Pool depth determines price impact. A swap large in relation to available liquidity moves the pool ratio more than a small swap, reducing output through slippage and the protocol’s liquidity fee. The two legs each consume liquidity, so looking only at a headline BTC/ETH market price misses the route’s actual execution cost. Arbitrage traders can trade against pools when their prices diverge from outside markets, but that process does not guarantee a particular quote at the moment a swap is submitted.

The route also has chain costs. The sender pays the Bitcoin network fee for the inbound transaction; the delivered ETH amount accounts for the destination-chain outbound fee. The protocol’s liquidity fee depends on pool use. A displayed estimate is thus an expected output after relevant fees, while the final result depends on execution conditions and any minimum-output constraint attached to the swap.

What can delay or prevent settlement?

A route cannot complete until the inbound deposit is observed and accepted, then processed into an outbound transaction. Bitcoin confirmation time and Ethereum transaction conditions affect when the user sees final settlement. A pending outbound transaction is different from a failed swap: check the route’s status and transaction records on the relevant chains before treating a delay as a loss.

Execution can also stop when the swap cannot satisfy its minimum output, sometimes called the price limit or slippage limit. This bound protects the user from receiving less than the specified amount; depending on the failure point and protocol handling, unexecuted input may be refunded. The route’s interface should show the estimated output and minimum before the deposit is sent. Read both values instead of treating the estimate as guaranteed.

For a larger trade, THORChain’s streaming swaps can split execution into smaller sequential sub-swaps. This can reduce the price impact of each step, but takes longer and does not remove market or pool risk. A time-optimised swap prioritises faster execution; a price-optimised stream trades over time in pursuit of better pricing. The choice is a trade-off between waiting and accepting the impact of a larger immediate swap.

• Confirm that the source asset is native BTC and the destination is an Ethereum address able to receive native ETH.
• Verify the deposit details and memo exactly as shown by the interface before broadcasting.
• Compare estimated output, minimum output, liquidity impact and network fees before choosing the swap mode.
• Keep the Bitcoin and Ethereum transaction IDs so you can distinguish deposit confirmation from outbound settlement.

A BTC-to-ETH route is best understood as coordinated settlement across chains, with pool liquidity determining conversion and vaults handling custody between the deposit and payout. For most users, the practical choice is to use the quoted minimum output as a hard acceptance bound and to allow enough time for both chains’ transactions to settle. That makes the route’s key trade-offs visible: native-asset delivery without a direct BTC/ETH pool, in exchange for two pool legs, chain fees and cross-chain settlement time.