Swap Bitcoin (BTC)

The numbers below were checked on 14 October 2026 against bitcoin.org, the Bitcoin Core source and the BIPs on github.com, and mempool.space.

Blocks: every 10 minutes on average

Bitcoin Core's chain parameters set the target spacing to 600 seconds and re-tune the difficulty every 2,016 blocks, two weeks at that pace. The target is an average. bitcoin.org's FAQ says a block can come sooner or later, with no guaranteed minimum or maximum: two blocks a minute apart and then a forty-minute gap is normal. Any time written next to a Bitcoin deposit is an expectation, not a promise.

What a confirmation is

A broadcast transaction has zero confirmations until a block includes it; each later block adds one, and each makes reversal harder. bitcoin.org notes that every receiver decides how many it wants. The route data this site is built from waits for 2 on a BTC deposit, the same for every swap from BTC. Two blocks at the 10-minute average plus about a minute of processing gives 21–44 minutes — blocks on schedule at the low end, slow ones at the high end. A run of slow blocks can exceed it.

The fee market, in four sentences

Block space is limited — BIP 141 caps a block at 4,000,000 weight units, about a million virtual bytes — so each transaction bids for it with a fee in satoshis per virtual byte (sat/vB), and miners fill blocks from the highest rate down. The sender sets the fee: the wallet proposes a rate from the current mempool, and almost every wallet lets you change it before signing. Replace-by-fee (BIP 125) lets the sender rebroadcast an unconfirmed transaction with a higher fee, and since Bitcoin Core 28.0 nodes relay such replacements by default even when the original did not signal for it. Child-pays-for-parent is the receiver's version: a new transaction spends the unconfirmed output with a fee high enough that a miner takes both together.

Why a cheap deposit can sit for hours

mempool.space describes the mempool as each node's queue of unconfirmed transactions. A transaction priced below what others pay stays in the queue until demand falls, and a node whose mempool is full drops the lowest-rate transactions altogether. bitcoin.org says the same from the sender's side: below the rate the network is prioritising, the first confirmation may take considerably longer.

This is the most common "deposit not arrived". The transaction exists, the explorer shows it, and it is waiting for a block. It still belongs to the swap and is processed at its second confirmation. The cost is time: the rate is fixed only then, so the market has longer to move between estimate and payout. Your wallet's normal or fast setting is the whole fix.

Four formats are in use, all on the same chain and all holding the same coin. They were checked against BIP 13, BIP 173 and BIP 350 at github.com/bitcoin/bips on 14 October 2026. The long version, with encodings and worked examples, is Bitcoin address types as a payout address.

1… and 3… are Base58Check: case-sensitive, a four-byte checksum, an alphabet without 0, O, I and l. bc1q… and bc1p… are Bech32 and Bech32m: lowercase, or all uppercase for QR codes, never mixed — BIP 173 requires decoders to reject mixed case — at most 90 characters, with a six-character checksum. BIP 350 changed one constant in that checksum for witness version 1 and up, so a bc1p… string with the old checksum is rejected rather than quietly accepted.

What the form accepts

For a BTC payout the form takes a mainnet address in any of the four formats and checks its checksum. Testnet addresses (m…, n…, 2…, tb1…) fail, and so does anything from another network: 0x… is Ethereum or a relative, T… is TRON, and a BTC-pegged token at such an address is not bitcoin. The deposit address the form shows you is an ordinary mainnet address that any wallet or exchange withdrawal can pay.

Which one to give, and who may not take bc1p…

1. Your own wallet: the address from its Receive screen. bc1q… is the default of most wallets made since 2018 and the cheapest to spend from later; bc1p… if offered.
2. An exchange: the address from its BTC deposit page, exactly as shown. You do not choose the format; it does.
3. Another person: ask for the address and read the first and last characters back.

Taproot addresses have existed since November 2021, and services added support one by one. Kraken's list of supported withdrawal formats includes bc1p for Bitcoin (checked at support.kraken.com on 14 October 2026); other services still name only 1…, 3… and bc1q…, and their withdrawal forms report bc1p… as invalid rather than sending. A payout from this site to bc1p… always goes through; whether the service behind the address credits it is that service's rule, written on its deposit page.

Every Bitcoin transaction has a 64-character hash, and anyone with the hash can look it up. The status page links the BTC side of a swap to blockchain.com; mempool.space shows the same transaction and is better at explaining why one is waiting. Both were read on 14 October 2026.

blockchain.com opens a transaction with the amount, the fee, the sending and receiving addresses, and a line saying whether it is confirmed, in which block, and with how many confirmations. Below are the hash, block ID, time, the inputs and outputs with their totals, the fee per byte and per virtual byte, size, weight, and whether replace-by-fee was signalled. For an unconfirmed transaction the block fields are empty and the count is zero.

mempool.space lists the timestamp, the features used (SegWit, Taproot, RBF), the fee and the fee rate in sat/vB, inputs and outputs, then size, virtual size, weight, version and locktime. For a transaction still in the mempool it shows where it sits against the fee rates being mined now — the quickest way to see whether a deposit is about to confirm or has hours ahead of it.

A deposit you sent

1. Copy the hash from your wallet's transaction list — the hash, not the address.
2. Open it on either explorer. Not found means the wallet has not broadcast it; a wallet that was offline when you pressed Send is the usual reason.
3. Check the output: the deposit address from the form, with the exact amount.
4. Compare the fee rate with the rates in the blocks being mined now. Below them, the deposit is waiting.
5. Watch the count. The status page updates on its own at 1 and at 2.

A payout you received

The status page shows the payout hash as soon as the payout is broadcast; "Done" means exactly that. A receiver verifies from the other end:

1. Open the hash from the status page on the explorer.
2. Find your address among the outputs. The amount next to it is "You get" from the form — the payout network fee was already taken out.
3. Count the confirmations. Your wallet shows the coins as pending at zero and spendable after its own number; an exchange credits them after its own count, commonly several blocks.
4. Keep the hash. It is the evidence that the payout happened and the one thing support on either side will ask for.

What a block explorer shows about a swap does the same for other networks; Reading a swap status page explains each stage.

Bitcoin's mistakes are rarely dramatic: nothing lands on the wrong chain, because the form rejects foreign address formats. What goes wrong is slower and smaller — a deposit that waits, an amount that arrives short, a payout the receiver cannot see.

Fee too low

The deposit is the only part of a swap whose fee you choose, and the only part that can be slow by your own choice. A wallet's lowest setting is for a transfer where time does not matter. Here it does: the rate is set at the second confirmation, and every extra hour is an hour for the estimate to drift. The difference between the lowest and the normal setting is a small fraction of any amount worth swapping.

Less arrives than the form expects

Most exchanges take their withdrawal fee out of the amount you type. Type the swap amount and the deposit arrives short by that fee; the swap runs on what arrived, so the payout is smaller than the estimate — and if the shortfall takes the deposit under the route's minimum, it cannot be processed as a swap at all. The withdrawal screen shows the amount the exchange will actually send. Make that match the form.

Dust and the minimum

Bitcoin has a floor under how small an output may be. Bitcoin Core's relay policy (src/policy/policy.cpp on github.com, checked 14 October 2026) treats an output as dust when spending it would cost more than it is worth: 546 satoshis for a legacy output and 294 for a native SegWit one at the default dust fee rate, and a transaction creating a smaller output is not relayed. The swap's minimum is far above that. It is shown under the amount field and moves with Bitcoin's fee level, because the payout fee has to fit inside the amount; Minimums, maximums and network fees on small swaps shows how to read it.

The format check is strict because a confirmed Bitcoin transaction cannot be reversed — bitcoin.org puts it in one sentence: once confirmed, it can only be refunded by the person receiving the funds.

Bitcoin changes rarely and by soft fork, so a wallet from years ago still works. Three changes since 2017 matter to someone sending or receiving BTC, and each has a block height and a date that can be checked. Heights come from Bitcoin Core's chain parameters and the Bitcoin Wiki; the block timestamps were read on mempool.space on 14 October 2026.

SegWit, August 2017. Bitcoin Core records SegwitHeight as 481,824; mempool.space timestamps the block at 01:57 UTC on 24 August 2017. BIP 141 defines the new limit — block weight no more than 4,000,000, where weight is three times the non-witness size plus the total size — and the virtual byte as weight divided by four. That is why fees are quoted in sat/vB and why a native SegWit input is cheaper than a legacy one: its signature data counts at a quarter.

Taproot, November 2021. The Bitcoin Wiki records activation at block 709,632 on 14 November 2021 after the Speedy Trial signalling period; mempool.space timestamps it at 05:15 UTC. The visible result is the bc1p… address, and BIP 350's Bech32m checksum is the detail behind every "Taproot not supported" notice: a parser written before it cannot validate a bc1p… string.

The halving, April 2024. The subsidy halves every 210,000 blocks. Block 840,000 was mined at 00:09 UTC on 20 April 2024 and took it from 6.25 to 3.125 BTC; the Bitcoin Wiki's supply table lists the earlier halvings at blocks 210,000, 420,000 and 630,000. A halving changes what miners earn and nothing about how a transfer is made or confirmed. The next is at block 1,050,000; the date depends on how fast blocks come.

Replace-by-fee by default. A policy change rather than a consensus change: Bitcoin Core 28.0 changed the default of mempoolfullrbf from 0 to 1 (release notes on github.com), so a node on that default relays a higher-fee replacement whether or not the original signalled for it. A stuck deposit can be bumped more often than before — if the wallet that sent it offers the option.

What has not changed. Ten-minute blocks, a 21-million cap, irreversible transactions, and a fee chosen by the sender. A 1… address made in 2012 still receives coins today, and the 2 confirmations this site waits for mean what they meant then.

Litecoin was built from the Bitcoin code in 2011, and for a transfer the two behave the same way with different numbers. The table uses each project's Core chain parameters on github.com (checked 14 October 2026) and the confirmation counts the site waits for.

Time. Five Litecoin confirmations take less time than two Bitcoin ones, because the block target is a quarter of Bitcoin's. If you hold both and want the swap to finish sooner, send the LTC.

Fees. Litecoin blocks are rarely full, so its fee market seldom has the queue Bitcoin's has in a busy week; the wallet's default is normally enough. On Bitcoin the fee is a decision — the Network section above is about making it.

Addresses. Litecoin's prefixes map onto Bitcoin's: L… legacy (version byte 48), M… script (version byte 50), ltc1… native SegWit. The trap is the shared 3…: Litecoin originally used version byte 5 for script addresses, the same as Bitcoin, and Litecoin Core still accepts it, so a 3… address does not say which chain it belongs to. The form accepts 3… only for a BTC payout and asks for L…, M… or ltc1… for an LTC one; when a person gives you a 3… address, ask which coin it is for.

Routes. BTC has the wider set of pages, including BTC → XMR with a step-by-step post. LTC has one route page, into USDT on TRON, and appears as a receiving coin in the form.