Skip to main content
Hashbeam

Crypto protocols, markets and policy

fced3a

Bitcoin-to-Chain Swaps: Routes, Timing and Fees

A Bitcoin-to-chain swap can deliver native coins or a wrapped token; the route determines its settlement steps, waiting time, fees and failure risks.

The Hashbeam Desk··5 min read

Bitcoin-to-Chain Swaps: Routes, Timing and Fees

A Bitcoin-to-chain swap sends value from Bitcoin to an asset on another blockchain, but the route determines what arrives and who controls settlement. A native swap exchanges BTC for the destination chain’s native asset through cross-chain liquidity; a bridge can lock BTC and issue a token representation; an exchange can custody BTC and withdraw a different asset. These routes have different confirmation steps, fee schedules and failure modes, so identify the asset you need before you send.

How does a Bitcoin-to-chain swap work?

A native cross-chain swap observes a Bitcoin deposit, executes a trade against liquidity, then sends the destination asset from a vault or protocol-controlled account. THORChain is one example: its pools pair assets with RUNE, so a BTC-to-ETH trade passes through BTC:RUNE and then RUNE:ETH before native ETH is sent. This is not a Bitcoin smart contract directly transferring BTC into an Ethereum contract; the protocol’s validators observe and account for activity on both chains.

A bridge follows a different path. It takes custody of BTC, then issues a corresponding token on the destination chain; a later redemption burns or returns that representation as the bridge releases BTC. The representation depends on the bridge’s custody and verification design. RenBridge is a useful historical case of that model. For its mechanics and what replaced it, see RenBridge’s bridge model and alternatives. A wrapped token can be useful when the goal is BTC exposure in a destination-chain app, but it is not native BTC and adds bridge-specific custody or validator risk.

An atomic swap uses hash time-locked contracts (HTLCs) to exchange assets directly between parties without a bridge custodian. The Bitcoin side can use Bitcoin Script conditions such as OP_SHA256 and OP_CHECKLOCKTIMEVERIFY: the recipient claims the coins by revealing a secret whose hash was committed in the contract, while a timeout lets the original sender refund. A corresponding contract on the other chain uses the same secret and a shorter timeout. Both parties must follow the claim sequence; if one side fails to act before its refund deadline, the swap may unwind rather than complete. This route requires compatible counterparties and tooling, so it is not the default flow behind every “swap” button.

What steps should I take before sending BTC?

First, check whether the output is native to the destination chain or a wrapped representation, and confirm the exact network and token contract if it is a token. Then compare the quote’s expected output and minimum output with the amount you intend to receive. A quote is an estimate, not a guarantee: pool movement, a deadline or a fee change can affect execution.

  • Use a fresh deposit address and memo or transaction instruction generated for that quote. Reusing an address or omitting a required memo can prevent the protocol from matching the deposit to your swap.
  • Check the Bitcoin network fee in your sending wallet and keep enough BTC for it. The wallet pays this fee when it broadcasts the transaction, separate from the amount sent.
  • Inspect the destination address on the correct chain. A valid-looking address on the wrong network can still send funds somewhere unrecoverable.
  • For an HTLC swap, verify both contract terms, the hash, and the relative refund deadlines before funding either side. A short or incorrectly ordered timeout can leave one party exposed.

For a protocol swap, the sequence is generally: request a quote; send the specified BTC amount to the protocol’s current Bitcoin vault address with its instruction; wait for Bitcoin confirmations and protocol observation; then watch for the destination-chain transaction. Do not treat a broadcast as settlement. The swap is complete only when the destination transaction is confirmed and the received asset matches the quoted network and token.

How long does a BTC-to-chain swap take, and what does it cost?

There is no fixed duration or universal fee. Bitcoin confirmation time depends on the transaction’s fee rate and network demand; after that, the swap protocol must observe and process the deposit, and the destination chain must confirm its payout. A congested chain, additional confirmation requirements, protocol queue or destination-chain slowdown can extend the wait. An atomic swap also includes timeouts, which are refund windows rather than promised completion times.

Count costs as separate components: the Bitcoin transaction fee paid on send; the swap’s liquidity or price-impact charge; any protocol outbound fee deducted from the output to cover destination-chain gas; and any interface or affiliate charge. A bridge can add its own deposit, mint, redemption or withdrawal fees. A custodial exchange adds its trading spread or fee and a withdrawal charge. The total depends on the route, amount, liquidity, destination network and conditions when each transaction is submitted.

For a live quote, compare the net destination amount after all listed charges, not a headline percentage. Larger trades can consume more pool depth and receive a worse execution price; smaller trades may be dominated by fixed Bitcoin and destination-chain costs. If you need native BTC exposure turned into a native destination coin, a supported liquidity swap avoids receiving a wrapped token. If you specifically need a tokenized BTC asset for an application, a bridge may fit, but its custody and redemption path become part of the risk. The right route is the one whose settlement asset and trust assumptions match the job.