Read the network before reading the amount
| Prefix in the specification | Network context | Use in a real exchange |
|---|---|---|
| bitcoincash: | Bitcoin Cash mainnet | Obtain the complete current instruction from your intended recipient |
| bchtest: | Bitcoin Cash testnet | A testing-network instruction is not a mainnet payout recipient |
| bchreg: | Bitcoin Cash regtest | A development context does not establish a real receiving account |
| No visible prefix | Some interfaces omit it in the display | Confirm the asset and network rather than adding guessed text |
A checksum cannot tell you who controls the recipient
CashAddr includes error-detection information. That helps distinguish malformed input from a correctly encoded address, but a valid address can still belong to the wrong person or account. Compare the complete receiving instruction using a trusted view of your wallet or the recipient platform. Do not stop after the first few characters, and do not assume that a form accepting the text proves ownership. The check must establish both technical validity and the intended destination.
The Bitcoin Cash specification permits the prefix to be omitted in user presentation because it participates in the checksum calculation. This is not an instruction to strip it whenever a form rejects the address. If the source and destination interfaces display different forms, confirm the supported representation through their documentation or support. Do not manufacture a new recipient by replacing characters. Keep the original receiving instruction so a later review can establish what was supplied, rather than only seeing your edited version.
Resolve the BCH address before committing BTC
- Open the intended receiving account
Choose Bitcoin Cash explicitly. For a personal wallet, use its current receive screen; for a hosted account, read the BCH deposit network and conditions. Do not substitute a generic token address or a development-network example from a technical guide. A documentation sample illustrates encoding and should never be treated as your payout destination.
- Handle a format rejection as a compatibility question
If the current form does not accept the walletโs instruction, check which representation and address type the actual sender supports. Do not infer support from a general CashAddr specification alone. Avoid an improvised conversion website or a manually shortened string. The right next action is to clarify the receiving instruction while no funds have been sent.
- Keep the Bitcoin funding side separate
After the recipient has been verified, read the orderโs BTC payment instruction and current amount. Neither the BCH address nor its prefix belongs in the BTC deposit field. Preserve the order number with both records. When a payout is issued, its own transaction reference can be checked against the verified BCH recipient; the BTC funding record describes a different stage.
Checking the BCH recipient
- Does an accepted CashAddr guarantee it is my wallet?
- No. Format validation and a checksum do not establish ownership. Compare the full destination with the receiving instruction from the wallet or account you actually intend to credit.
- Can I remove the prefix to force a rejected address through?
- Do not force acceptance by editing. Some interfaces display a prefixless form, but the actual sending service must support the intended representation and address type. Clarify its instructions first.
CashAddr specifications and receiving references
- CashAddr network and checksum specification
- CashAddr encoding reference
- Bitcoin Cash receiving wallets
Reviewed: