# Checking a Bitcoin address: format, network and recipient A valid Bitcoin address is a correctly encoded destination supported by the relevant network and wallet. Validation can detect format or checksum errors; it cannot tell you who controls the destination or whether it is the address you intended. Check the complete request against a trusted source and use the correct network context before authorizing payment. Evidence: [validateaddress RPC](https://bitcoincore.org/en/doc/29.0.0/rpc/util/validateaddress/); [Base32 address format for native v0-16 witness outputs](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0173.mediawiki); [Bech32m format for v1+ witness addresses](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0350.mediawiki); [Trezor’s Trusted Display](https://trezor.io/guides/trezor-devices/trezor-fundamentals/trezor-s-trusted-display-verify-every-address-on-your-device) Canonical: https://degreesofsatoshi.com/encyclopedia/bitcoin-address-validation/ Published: 2026-10-02 Substantively modified: 2026-10-02 Independently verified by an automated reviewer: 2026-10-02T19:29:20.637Z Data current through: 2026-10-02 AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied. ## Key facts - **Format check:** Valid encoding is not recipient identity ([validateaddress RPC](https://bitcoincore.org/en/doc/29.0.0/rpc/util/validateaddress/)) - **Witness version:** Bech32 and Bech32m apply to different versions ([Bech32m format for v1+ witness addresses](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0350.mediawiki)) - **Final check:** Compare the full intended destination ([Trezor’s Trusted Display](https://trezor.io/guides/trezor-devices/trezor-fundamentals/trezor-s-trusted-display-verify-every-address-on-your-device)) ## Understand the scope of a validation result Core’s validateaddress can return validity and the resulting output script, with error-location information where available. That result answers an encoding question. An attacker can provide a perfectly valid destination under their own control. Witness version 0 uses Bech32; version 1 and later use Bech32m under BIP-350. The appropriate decoder must validate the version and checksum pairing rather than accept any string with a familiar beginning. Evidence: [validateaddress RPC](https://bitcoincore.org/en/doc/29.0.0/rpc/util/validateaddress/); [Base32 address format for native v0-16 witness outputs](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0173.mediawiki); [Bech32m format for v1+ witness addresses](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0350.mediawiki) ## Check more than a recognizable prefix Mainnet and test environments use different conventions. Confirm the wallet’s selected chain and the recipient’s intended route as well as checking the address text. A familiar-looking prefix is not a substitute for checking those settings. A Lightning invoice is not a normal Bitcoin address. An interface rejecting it may expect a different payment method, rather than detecting a typo in an on-chain destination. Evidence: [Base32 address format for native v0-16 witness outputs](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0173.mediawiki); [getblockchaininfo RPC](https://bitcoincore.org/en/doc/29.0.0/rpc/blockchain/getblockchaininfo/); [BOLT 11: Invoice Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/11-payment-encoding.md) ## A valid address can still be the wrong one Imagine that a malicious clipboard replacement swaps one valid destination for another. Both pass a checksum check. Comparing only the first and last few characters is weaker than checking the complete destination through the supported display or a trusted request. If an address fails validation, obtain it again from the intended recipient. Guessing which character to alter can produce a different destination; a checksum is an error detector, not permission to improvise a correction. Evidence: [Trezor’s Trusted Display](https://trezor.io/guides/trezor-devices/trezor-fundamentals/trezor-s-trusted-display-verify-every-address-on-your-device) ## Questions ### Does a checksum prove that an address belongs to the recipient? No. It checks consistency of the encoded text. A different person can supply a valid address with a valid checksum, so recipient authentication must come from the surrounding relationship or request. Evidence: [Base32 address format for native v0-16 witness outputs](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0173.mediawiki); [Trezor’s Trusted Display](https://trezor.io/guides/trezor-devices/trezor-fundamentals/trezor-s-trusted-display-verify-every-address-on-your-device) ### Can all Bitcoin wallets send to every valid address type? No. Format and feature support depend on the wallet version and the type of output. A destination can be valid under a specification while an older interface does not support sending to it. Evidence: [Bech32m format for v1+ witness addresses](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0350.mediawiki) ## Claims and scope ### bitcoin-address-validation-quick-answer A valid Bitcoin address is a correctly encoded destination supported by the relevant network and wallet. Validation can detect format or checksum errors; it cannot tell you who controls the destination or whether it is the address you intended. Check the complete request against a trusted source and use the correct network context before authorizing payment. Educational explanation. Product-specific behavior is scoped to the cited documentation, checked 2026-10-02. Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ### bitcoin-address-validation-fact-format-check Format check: Valid encoding is not recipient identity Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ### bitcoin-address-validation-fact-witness-version Witness version: Bech32 and Bech32m apply to different versions Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ### bitcoin-address-validation-fact-final-check Final check: Compare the full intended destination Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ## Sources - [validateaddress RPC](https://bitcoincore.org/en/doc/29.0.0/rpc/util/validateaddress/) — Bitcoin Core. Address syntax validation does not authenticate a payee. Locator: Result: isvalid, address, scriptPubKey, error. Retrieved: 2026-10-02T18:53:55.094Z. - [Base32 address format for native v0-16 witness outputs](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0173.mediawiki) — Bitcoin Improvement Proposals. Bech32 network prefixes and error detection; v1+ rules subsequently changed by BIP-350. Locator: Bech32; Segwit address format; Checksum design. Retrieved: 2026-10-02T18:53:54.081Z. - [Bech32m format for v1+ witness addresses](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0350.mediawiki) — Bitcoin Improvement Proposals. Version-specific checksum validation and compatibility limits. Locator: Specification; Compatibility. Retrieved: 2026-10-02T18:53:54.129Z. - [Trezor’s Trusted Display](https://trezor.io/guides/trezor-devices/trezor-fundamentals/trezor-s-trusted-display-verify-every-address-on-your-device) — Trezor. Manufacturer explanation of device display checks and the limits of a host-computer screen. Locator: Trusted display article: on-device verification steps and limits of what the device verifies. Retrieved: 2026-10-02T18:53:56.900Z. - [getblockchaininfo RPC](https://bitcoincore.org/en/doc/29.0.0/rpc/blockchain/getblockchaininfo/) — Bitcoin Core. Network identity and sync-status fields; progress is an estimate. Locator: Result: chain, blocks, headers, verificationprogress, initialblockdownload. Retrieved: 2026-10-02T18:53:55.851Z. - [BOLT 11: Invoice Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/11-payment-encoding.md) — Lightning specification contributors. Invoice amounts, payment hashes, expiry, signing and feature constraints. Locator: Human-Readable Part; Data Part; Tagged Fields; Payer / Payee Interactions; Payer / Payee Requirements. Retrieved: 2026-10-02T18:53:57.096Z. ## Revision history - 2026-10-02: First publication after primary-source research and separate automated verification. ## Cite this entry Degrees of Satoshi editorial project. “Checking a Bitcoin address: format, network and recipient.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/bitcoin-address-validation/