A Bitcoin wallet that calls an address “valid” is answering a narrow technical question. It has checked that the string follows the encoding rules for its address type. It has not established that the address belongs to the person, business, or account you meant to pay. Treating those two questions as one is how a correctly formatted address ends up pointing at the wrong recipient.
What the checksum actually proves
Bitcoin’s address standards define encoding rules, not a directory of named recipients. BIP 350 assigns Bech32 to witness version 0 and Bech32m to witness versions 1 through 16, and it requires the decoder to confirm that the encoding matches the witness version and to check the decoded data’s length and version. Those checks catch malformed or mistyped strings, which is genuinely useful. But an attacker does not need to defeat the checksum. A substituted address can be entirely valid on its own terms.
The practical consequence is that a green check mark in a withdrawal form answers a limited question. It can mean the service recognizes the address syntax. It cannot, by itself, prove that the intended recipient sent the instruction or can spend the resulting output.
Where the substitution risk lives
The real danger is rarely a typo; it is an instruction silently changed in transit. The Bitcoin Developer Guide’s payment-processing documentation warns that payment requests should travel over HTTPS or another secure channel to prevent a man-in-the-middle from replacing your Bitcoin address with the attacker’s address. HTTPS protects the connection to the site you opened, not every site that shows a padlock. Start from the genuine service or an established channel, and if a payment request changes unexpectedly, confirm the change through a route you already trust rather than a detail inside the suspicious request.
Four checks that answer different questions
It helps to keep four checks separate. First, confirm the network and asset match, so the payment is prepared for the intended environment. Second, validate the complete address against the applicable encoding rules. Third, independently confirm the exact destination against a trusted instruction from the intended recipient. Fourth, review the signed payment and the receipt that follows. The first two establish that a destination is well formed; only the third establishes why it is the right one. Passing the first two should not cause the third to disappear.
What to do before you send
Before authorizing a transfer, identify which screen supplies the address, which screen authorizes it, and how the recipient will confirm receipt. A QR code supplies payment data; it is not an endorsement of the recipient, and if scanning and copying both come from the same altered page, agreement between them proves nothing. If a signer has its own display, compare the destination shown there against an independently obtained instruction. And a past successful transfer to an old address does not verify a newly generated one, so recheck the exact payment you are about to authorize rather than a familiar-looking prefix.
Adapted from Why a Valid Bitcoin Address Can Still Be the Wrong Destination.