A Bitcoin address prefix describes aspects of receiving format, not who owns it or whether a particular service supports it. Before sending to an address beginning with 1, 3 or bc1, check the network and both products’ support, then compare the entire value with verified receiving instructions.
Accepting an address technically does not authenticate its owner.
BTKWIN.COM · EDUCATIONAL EXAMPLEWhat the common mainnet prefixes describe
An address encodes information used to construct a transaction output. It is not a central account username or a security rating for the person receiving the payment. A valid address can belong to either the intended recipient or someone else.
Common Bitcoin mainnet examples include legacy P2PKH addresses beginning with 1, P2SH addresses beginning with 3, version-zero SegWit addresses beginning bc1q and version-one addresses beginning bc1p, used with Taproot.
You do not need to memorize implementation details to use a wallet, but bc1 alone is not a complete description of every supported witness version. Likewise, a 3 prefix does not by itself prove that an address uses multisignature.
Read prefix information within its scope
| Mainnet beginning | Short description | Not established |
|---|---|---|
| 1 | Legacy P2PKH format | Owner identity or device security |
| 3 | P2SH representation of spending conditions | Multisig in every case |
| bc1q | Version-zero SegWit address | Support by every product route |
| bc1p | Version-one witness address, including Taproot | Compatibility of both actual services |
Encoding support can differ between products
BIP173 describes Bech32, while BIP350 specifies Bech32m for later witness versions. Older software or a particular service route can support one format without interpreting another.
A technically valid address can therefore be rejected by an interface lacking the required support. That does not automatically prove the receiving wallet is fake or that Bitcoin cannot be received there.
Do not fix a compatibility error by editing the prefix or copying a segment into another address. A valid alternative must be generated through the receiving wallet’s documented supported process, not manually rewritten.
Investigate an invalid-address message precisely
Check selected asset and network, supported address formats, correct destination field and copying errors such as unintended whitespace. The error may occur before the network is involved at all.
If the receiving wallet offers another supported format, review that option within the wallet and verify the generated address from the beginning. Do not substitute an address from an unsolicited helper just because the sending interface accepts it.
Keep sanitized error text, product route and address-type information for official support. Diagnosing format support does not require recovery words or a private key. Those disclose spending authority rather than proving that a withdrawal form supports a format.
Check the network before treating the prefix as enough
Services displaying BTC can offer native Bitcoin, Lightning and representations on other networks. Match the receiving method the destination actually supports. A product name containing Bitcoin does not certify native-network BTC delivery.
Test networks use different address conventions and do not serve as a source of real-mainnet receiving instructions. A Lightning invoice is also not just another bc1 address: it belongs to a different payment route and can have amount or expiry conditions.
Put asset, network, receiving method and address or invoice side by side. Do not choose an incompatible network solely for a lower fee. Our withdrawal route guide explains that comparison.
Example: platform withdrawal to your wallet
Open Receive in the intended wallet account, choose the actual asset and route and copy from that verified screen. If using a signing device, follow its official address-confirmation method before relying on the value.
After pasting into the platform, compare the full address, including the middle, and review the final confirmation again. Source verification does not automatically prove the pasted value remained unchanged.
Then inspect fee, minimum and net recipient quantity. A test can incur its own fee or fall below a receiving service’s minimum. Even a successful test does not replace review of the next request if address, network or input source changes.
Technical validity leaves recipient identity unresolved
A maliciously supplied address can be perfectly valid and accepted by software. The wallet does not know the agreement behind an invoice. Confirm changed payment instructions through an established channel rather than a new number embedded in the change request.
Similarly, your own valid address can still be incompatible with a service’s particular supported deposit or withdrawal route. Format, control and receiving conditions are three questions whose answers do not automatically substitute for one another.
A QR code transports data rather than authenticating its source. Review the decoded destination, amount and network as you would after text paste. Our receiving address guide explains the full comparison.
Address type does not give a fixed fee quote
Different transaction types can have different data efficiency, but actual cost also depends on inputs, outputs, rate and service policy. No prefix guarantees one fixed charge for every payment.
A platform withdrawal charge is also not necessarily a personalized share of one network transaction. The service may batch requests or apply a fee schedule. Compare user cost and net receipt under current terms rather than declaring one estimate wrong from an example size.
Our transfer cost tool organizes those values; it does not validate addresses or current network demand. Keep arithmetic distinct from compatibility and destination checks.
A new receive address and old instructions
A wallet may display another receiving address while continuing to control earlier ones. That does not automatically mean a new wallet was created or old funds moved. Review account, network, recovery and known addresses if uncertain.
Custodial deposit instructions have another layer: a service can announce updated addresses or crediting rules. Use its current account page rather than assuming an old valid address remains an accepted deposit instruction forever.
Before confirming, verify current receiving source, asset, network, format support, full destination and net amount. If rejected, preserve the error and investigate rather than rewriting the address. Acceptance is a technical observation, not a promise of reversibility after a mistake.
Preserve the exact rejection context
Record whether the error occurred during address entry, network selection or final submission. Those stages can indicate different compatibility questions. Include the product and route when asking official support, without sharing private recovery data or manually changing the destination to silence the message.
Continue reading
English content and examples reviewed: 27 October 2026. Read the Arabic edition.
