Bitcoin address types: 1…, 3…, bc1q…, bc1p… as a payout address

A Bitcoin wallet made in 2014 shows an address starting with 1. One made in 2018 shows 3 or bc1q. One made last year may show bc1p. All four are addresses on the same network and all four receive a BTC payout here, but they are not interchangeable everywhere else. The formats were checked against the Bitcoin Improvement Proposals that define them — BIP 13 for 3…, BIP 173 for bc1q…, BIP 350 for bc1p… — at github.com/bitcoin/bips on 12 October 2026, and the block-timing facts against bitcoin.org the same day.

The four formats

1… and 3… are the older pair. Both are Base58Check: a version byte, a 20-byte hash and a 4-byte checksum, 25 bytes in all, written in the base58 alphabet, which leaves out 0, O, I and l. The version byte is what you see as the first character: 0 produces a leading 1, and BIP 13 specifies version byte 5 for mainnet P2SH, which produces a leading 3. The lengths follow from the 25-byte structure: a 3… address is always 34 characters, a 1… address 34 or fewer, shorter when the hash happens to begin with zero bytes. Base58 is case-sensitive. A 3… address does not say what is behind it — BIP 13 describes it as the hash of a redeem script revealed when spending, used for multisignature wallets and for "wrapped SegWit" — and for a payout it does not matter which.

bc1q… and bc1p… are the newer pair. BIP 173 defines Bech32: a human-readable part ("bc" on mainnet, "tb" on testnet), the separator "1", then a data part whose first character is the witness version and whose last six characters are a checksum. The data alphabet is lowercase letters and digits without 1, b, i and o, and a Bech32 string is at most 90 characters. Witness version 0 is written as q, and BIP 173 restricts version-0 programs to 20 bytes (a single key, 42 characters in all) or 32 bytes (a script, 62 characters).

BIP 350 changes one thing: the checksum constant. Bech32 could miss one specific error — inserting or deleting q characters just before a final p — so witness versions 1 to 16 use the corrected checksum, Bech32m, while version 0 keeps Bech32. Version 1 is written as p, and a Taproot program is 32 bytes, so a Taproot address is bc1p plus 58 characters, 62 in all. A decoder must check that a version-0 address uses Bech32 and any other version Bech32m, so a bc1p… address with the wrong checksum is rejected, not silently accepted.

Case. BIP 173 says encoders must output lowercase, that a string may be converted to all-uppercase for display or QR codes, and that decoders must reject mixed case. bc1q… and BC1Q… are the same address; bc1Q… is not an address. Legacy 1… and 3… addresses are case-sensitive throughout.

Which one to give as a payout address

Any of the four. On every route that pays out BTC — USDT TRC-20 → BTC, USDT BEP-20 → BTC, ETH → BTC, XMR → BTC and the others on the Bitcoin page — the recipient field accepts a mainnet address in any format. When you have a choice:

1. bc1q… from your own wallet: the default of any wallet made since 2018, smallest to spend from later, accepted almost everywhere.
2. bc1p… if your wallet offers it; the receiving service's support is the only thing to check.
3. 3… if that is what your wallet or multisig shows.
4. 1… if that is all an old wallet shows; works, but the largest to spend from later.

For the payout itself the format barely matters: a 62-character address makes the payout's output about ten bytes larger than a 42-character bc1q… or a 1…, on a transaction of a few hundred bytes, and the form shows the payout network fee in BTC before you send, already subtracted from "You get". The difference that matters is on your side, later, when you spend from the address: a native SegWit input is smaller than a legacy input and a Taproot input smaller still, so a wallet full of bc1q… or bc1p… outputs pays less per spend than one full of 1… outputs. That is the reason to prefer the newer formats, and it is about your next transaction, not this payout.

What the form checks

When you paste a recipient address on a route into BTC, the form asks the service that executes the swap whether the string is a valid Bitcoin mainnet address. The check covers:

• The format. One of the four prefixes with the right alphabet and length.
• The checksum. The four-byte Base58Check checksum for 1… and 3…, the six-character Bech32 or Bech32m checksum for bc1q… and bc1p…, with the version-to-checksum rule from BIP 350.
• The network. A testnet address (m…, n…, 2…, tb1…) fails. So does anything that is not a Bitcoin address: 0x… belongs to the Ethereum family, T… to TRON, and a BTC-pegged token on those networks is not bitcoin.

The check catches typing errors and the wrong network. It does not and cannot check that the address is yours, that you still have the keys, or that the receiving service will credit the format.

Worked example. You paste a 42-character bc1q… address from a wallet's Receive screen: accepted. You paste the wallet's bc1p… address instead: accepted too, 62 characters, Bech32m checksum. You paste the first address with one character mistyped: the checksum fails and the form marks it invalid. None of the three results says whether the wallet is yours — only whether the string is a well-formed destination.

What exchanges and services accept

The service receiving your payout decides which formats it can credit, and you find out from its deposit page, not from this one.

A payout to an address the receiving service cannot credit is the Bitcoin equivalent of USDT on the wrong network: the coins exist, the service does not see them as yours, and recovery depends on it. If the receiver is an exchange, paste the address it shows and nothing else.

What "2 confirmations ≈ 21–44 minutes" means

The figure appears on the routes where BTC is the deposit: BTC → USDT TRC-20 and the other routes from BTC. bitcoin.org puts the block interval at approximately every 10 minutes on average, with no guaranteed minimum or maximum delay. A transaction has its first confirmation when a block includes it, and one more with each later block. The swap from BTC waits for 2. The site's 21–44 minutes is arithmetic on the 10-minute average: two blocks in about 20 minutes plus a minute of processing in the good case, about twice that when blocks come slowly. A run of slow blocks can exceed it, and nothing on the site changes the count per swap.

On the payout side the roles switch: "Done" appears when the payout is broadcast and linked on blockchain.com, and your receiving service then applies its own confirmation rule before crediting — exchanges commonly wait several blocks for BTC.

Worked example. You open XMR → BTC at 14:00. The Monero deposit confirms after 5 blocks, about 11–24 minutes, so the rate is set around 14:15. The payout is broadcast within a couple of minutes and the status page says "Done" at 14:18. Your wallet shows the BTC as unconfirmed at 14:18, with 1 confirmation around 14:25 and 2 around 14:35, give or take the luck of the blocks. An exchange requiring 3 confirmations would credit it around 14:45. The swap's own timing ended at 14:18; everything after is Bitcoin's.

Two fees that are easy to confuse

The fee the sender pays applies when BTC is the deposit. Your wallet builds the transaction and you choose its fee rate; bitcoin.org notes that many wallets let you control how large a fee to pay, and that a low fee can make the first confirmation take considerably longer. For a swap that has a direct consequence: the rate is set at 2 confirmations, so a deposit that sits unconfirmed for hours lengthens the window in which the market can move. Choose the normal or fast setting.

The payout network fee applies when BTC is what you receive. It is paid by the side that sends the payout, quoted in BTC on the form before you commit, and already subtracted from "You get". It covers the payout transaction's fee at the time it is sent, which is why it is one figure for the route rather than a live estimator reading. It is also why a small swap into BTC costs more in percent than a large one: a fixed number of satoshis against whatever amount you chose, and a BTC payout fee is among the larger ones on this site. Floating rate: what changes between the estimate and the payout shows where each number comes from, and Reading a swap status page where the payout hash appears. Neither fee depends on the address format beyond the few bytes noted above.

Checklist before you paste a Bitcoin payout address

• The address starts with 1, 3, bc1q or bc1p and the form accepts it.
• For a bc1… address, it is all lowercase (or all uppercase), never mixed.
• It is a mainnet address: not m…, n…, 2… or tb1….
• If an exchange is receiving, it is the address from that exchange's BTC deposit page, in the format the exchange gave you.
• If your own wallet is receiving, the address came from its Receive screen, and bc1q… or bc1p… was chosen when offered.
• You know that "Done" means the payout is broadcast, and that your wallet or exchange counts its own confirmations after that.
• The status link is saved.

FAQ