A Bitcoin address can be structurally valid and still belong to the wrong person, the wrong exchange order, or the wrong network. Before sending BTC, you need to verify more than a few matching characters. The practical goal is to build an unbroken chain between your exchange request, the displayed Bitcoin network, the destination address, the amount, and the transaction record.
This route covers the most common scenario: sending on-chain BTC from a wallet to an address supplied for an exchange. If your task is to receive BTC instead, apply the same checks in reverse and verify that the receiving wallet supports the address type and Bitcoin network shown in the request.
The operation state map
Use this map as both a checklist and a decision tree. Do not advance because an address merely “looks like Bitcoin.” Move forward only when the evidence at the current state matches the original task.
- Task: exchange BTC using an on-chain Bitcoin transfer
- Transition condition: BTC is the asset you intend to send, not a token representing Bitcoin on another blockchain.
- Check: the exchange direction names BTC, and the deposit instructions explicitly identify the Bitcoin network or an on-chain Bitcoin deposit.
- Observable success: the asset, direction, and payment rail all describe the same BTC transfer.
- If it does not match, stop: a Lightning invoice, wrapped-Bitcoin token, or address on another network is not interchangeable with a standard Bitcoin address.
- Input data: obtain the address from the active request
- Transition condition: the exchange request has generated or displayed the destination details.
- Check: copy the address directly from the active request rather than from an old message, screenshot, browser history entry, or previous transaction.
- Observable success: the address remains visible in the current request and the request has not expired, changed, or been cancelled.
- If it does not match, stop: deposit addresses may be tied to a specific account, request, asset, or processing procedure.
- Verification: validate the address and its source
- Transition condition: the address has been copied into your wallet but the transaction has not been authorized.
- Check: confirm that the wallet accepts it as a Bitcoin address, then compare the complete address or several separated sections against the request. Recheck after pasting.
- Observable success: the wallet reports a valid destination and the pasted value is identical to the value displayed by the exchange request.
- If it does not match, stop: an altered clipboard value, invalid checksum, unexpected prefix, or unexplained address replacement requires a fresh copy from a trusted session.
- Final review: reconcile network, amount, fee, and extra fields
- Transition condition: the wallet has built a transaction preview.
- Check: review the BTC amount, destination address, network fee, total wallet deduction, and any minimum or exact-payment instruction shown in the request.
- Observable success: the intended recipient amount and the wallet’s final debit are understood, and no unexplained Memo or Tag is being added.
- If it does not match, stop: a fee deducted from the transfer amount, an outdated quote, or an unexpected extra field can make the payment inconsistent with the request.
- Action: authorize the irreversible transfer
- Transition condition: all earlier checks pass in the wallet’s final confirmation screen.
- Check: make one last comparison of the address and amount on the device that will sign the transaction, especially when a hardware wallet is used.
- Observable success: the signing screen shows the same destination and value that you approved in the request.
- If it does not match, stop: do not rely on the computer screen if the signing device shows different transaction data.
- Waiting: track the transaction by its identifier
- Transition condition: the wallet has broadcast the transaction and produced a transaction ID, or TXID.
- Check: use a reputable Bitcoin block explorer or your own node to verify the destination output, amount, status, and confirmation count.
- Observable success: the TXID appears on the Bitcoin network with the expected output and begins accumulating confirmations.
- If it does not match, stop escalating the exchange: first determine whether the wallet broadcast the transaction, whether the TXID is valid, and whether the expected address appears among its outputs.
- Result: the exchange recognizes the confirmed deposit
- Transition condition: the required network and service-side checks have been completed.
- Check: the request status links the payment to the correct order and shows that the deposit has been detected or credited.
- Observable success: the blockchain record and the exchange request refer to the same transaction, asset, network, and destination.
- If it does not match, enter the recovery route: preserve the request identifier, TXID, address, timestamps, wallet records, and screenshots of the displayed instructions before contacting support.
What a valid Bitcoin address actually proves
Bitcoin addresses contain error-detection data. Legacy Base58Check addresses include a checksum, while native SegWit formats use Bech32 or Bech32m checksums. Bitcoin Core also provides a validateaddress command that can report whether an address is valid and return technical information about it. [1]
That validation has a narrow purpose. It can detect many malformed or mistyped strings, but it cannot prove that the address belongs to the intended exchange, that the current request is genuine, or that malware did not replace one valid address with another. Recipient identity must be verified separately through the active request and, for higher-risk transfers, through a second trusted channel.
Common mainnet forms include legacy addresses beginning with 1, script addresses beginning with 3, and native SegWit addresses beginning with bc1. A bc1 address may use Bech32 for witness version 0 or Bech32m for later witness versions, including Taproot. Prefix recognition is useful for spotting an obvious mismatch, but it is not enough to approve payment. BIP 321 recognizes Base58, Bech32, and Bech32m forms in Bitcoin payment instructions. [2]
Confirm the asset and network before inspecting characters
Start with the label above the address. It should identify BTC and the intended Bitcoin payment rail. Do not assume that every option containing the word “Bitcoin” leads to the Bitcoin blockchain. Tokenized versions of BTC can exist on other networks, while Lightning uses invoices and payment channels rather than a standard on-chain deposit flow.
The sending wallet and the exchange request must describe the same route. If the request expects an on-chain Bitcoin transaction, choose BTC on the Bitcoin network in the sending wallet. If the interface presents several network choices and you cannot establish which one the request requires, do not select the cheapest-looking option. Network availability and supported exchange directions can change, so check the current request before sending.
A route has drifted away from the original task if the interface changes BTC to another asset, shows a non-Bitcoin network, replaces an address with an invoice, or asks you to bridge or convert funds elsewhere. Return to the beginning instead of trying to reinterpret the destination data.
Compare the address without trusting the clipboard
Copying is safer than typing a Bitcoin address manually, but clipboard replacement malware makes copying alone insufficient. After pasting, compare the destination shown by the wallet with the address in the request. Checking only the first and last few characters is quick, yet it can miss sophisticated substitution attempts. Compare additional groups from the middle or use a QR workflow that still gives you a readable confirmation screen.
If a hardware wallet signs the transaction, its display is the decisive checkpoint. Confirm the destination and amount there. A compromised computer can show one address while asking the signing device to authorize another.
Also inspect the source of the address. Warning signs include a request to use a replacement address sent through an unsolicited message, a page reached through an advertisement or misspelled domain, a sudden login prompt, or instructions that differ from the active order. Phishing can deliver a perfectly valid Bitcoin address controlled by an attacker.
Should you send a test transaction?
A small test can reduce the risk of sending the full amount to an unverified destination, but it does not fit every exchange request. The service may expect one exact payment, apply minimum-deposit rules, issue a time-sensitive quote, or treat multiple transactions separately. Check whether split payments are accepted before using this method. Never assume that a successful test authorizes a second payment if the request has expired or generated new deposit details.
Memo, Tag, amount, and fee checks
A normal on-chain BTC payment is routed by its Bitcoin address and does not use the destination tags commonly associated with some other cryptocurrencies. If the flow unexpectedly requires a Memo or Tag, verify that you have not selected the wrong asset or network. A platform may display internal reference information, but it should not be treated as a Bitcoin protocol field unless the service clearly explains how it applies to that deposit.
Next, separate three figures in the wallet preview:
- The requested amount: the BTC value the exchange expects to receive.
- The recipient output: the value actually assigned to the destination address.
- The total wallet debit: the recipient output plus any network fee and other wallet-side effects.
Wallets do not always present these figures in the same way. Confirm whether the network fee is added on top of the amount or subtracted from it. If subtraction would leave the exchange with less BTC than requested, revise the transaction before signing. Do not guess current fees, limits, or quote validity; use the values and conditions displayed for the active operation.
Once the asset, network, address, amount, fee treatment, and applicable request conditions all agree, you can create and review the BTC exchange request. Requirements may depend on the exchange direction and compliance results, so check the current conditions before submitting or funding the request.
After broadcast: confirmations and exchange recognition
A wallet may show “sent” as soon as it broadcasts a transaction. That does not mean the transaction is confirmed or credited by the exchange. A confirmation begins when the transaction is included in a Bitcoin block; later blocks add further confirmations. Block timing is probabilistic, and a transaction paying a fee below current network priority may wait longer for its first confirmation. [3]
Use the TXID to inspect the transaction. Verify that the destination address appears in the outputs and that its output value matches the intended payment. A transaction can contain more than one output because wallets commonly create a recipient output and a change output. Do not identify the payment by looking at the transaction’s total value alone.
The number of confirmations required for processing is a service-side condition, not a universal constant. Read the current request status rather than assuming that one particular count always completes every operation.
If the transaction is delayed or appears wrong
The wallet shows pending and a TXID exists
Check whether a Bitcoin explorer or node can find the TXID. If it is visible but unconfirmed, compare its fee conditions and status without creating a second payment. A replacement or duplicate attempt can complicate the order. Some wallets offer fee-management mechanisms, but their availability depends on how the original transaction was constructed; follow the wallet’s documented process rather than improvising.
The wallet says sent, but no explorer finds the TXID
The transaction may not have propagated, the wallet may be disconnected or unsynchronized, or the displayed identifier may have been copied incorrectly. Reopen the wallet’s transaction details and verify the complete TXID. Do not send the same amount again until the first transaction’s state is understood.
The blockchain confirms payment, but the exchange does not recognize it
Compare the confirmed output with the exact address and amount from the request. Then check whether the correct asset and network were used, whether the order was active when payment was made, and whether additional compliance review is pending. Provide support with the TXID and request identifier, but do not disclose a seed phrase, private key, wallet password, or remote access to your device.
The transaction went to the wrong address or network
Confirmed Bitcoin transactions cannot be reversed by the sender. A refund is possible only if the recipient controls the destination and agrees and is able to return the funds. There is no guaranteed recovery procedure. [3]
If BTC was sent through an unsupported route or to an address supplied for another operation, preserve all evidence and contact the relevant wallet or exchange support channel. Do not pay an unsolicited “recovery specialist” or reveal wallet secrets. Recovery feasibility depends on who controls the destination keys, the technology used, and the platform’s policies.
The verifiable finish line
The route is complete when the Bitcoin network shows the intended transaction and output, the required confirmations have accumulated, and the active exchange request recognizes that same deposit and reports its completed result. A wallet’s “sent” label by itself is not the finish line.
Some uncertainty can remain while confirmations, compliance checks, or internal processing are pending. Volatility may also change the fiat value of BTC during the route, while rules and reporting obligations differ between countries. Those uncertainties do not change the core safety test: asset, network, destination address, amount, transaction ID, and request status must form one consistent and independently checkable record.
