Original topic illustration: ChainView BTC866 original topic diagram · ChainView BTC866 Editorial · CC BY 4.0
Identify the source of risk
Address poisoning can place similar-looking addresses, zero-value records, tiny transfers, or fake-token entries into a wallet's history. The objective is to make a recent address appear to be a familiar recipient. Transaction history is an observation log rather than an authenticated contact book. Use an independently confirmed recipient record instead of copying from the latest entry, and verify the asset and network as part of the destination.
Token names, icons, and memos in history can also be fabricated. An unsolicited zero-value verification entry is not an authentication mechanism. Separating confirmed contacts from unexpected incoming records can reduce copying mistakes, but it does not replace review before signing. Treat the history's labels as data supplied by participants or software, not as a certification of the sender's identity.
Inspect each relevant field
Clipboard malware can replace an address after copying, while a QR code can encode a destination different from the nearby text. Check the source, the complete pasted value, and the final signing display. Where a hardware device has its own screen, inspect the fields there as well as on the computer. Matching only a few opening and closing characters is vulnerable to deliberate resemblance. A screenshot showing the same shortened label does not prove that full addresses match.
If a hardware screen truncates the address, use its supported scrolling or verification workflow to inspect the complete value. A small display is not a reason to accept an unchecked destination. When device and computer values conflict, stop and investigate rather than choosing whichever looks more familiar. The discrepancy is itself evidence that the signing context needs to be re-established.
Understand the limits
A small test transfer verifies one route at one moment and should include confirmation from the intended recipient. It cannot guarantee that later clipboard content, resolver records, or device state remains unchanged. Recheck the next transfer rather than copying blindly from the test history. For platform deposits, confirm account-specific addresses, tags or memos, minimums, and supported networks. Another user's successful deposit does not establish that a different account or network uses the same route.
A test amount must respect minimum deposits and any required tag. An amount below a platform minimum may not be credited, which does not automatically prove the network or address is invalid. Platform instructions and recipient confirmation determine whether the test is meaningful. A poorly designed test can create a separate loss and should not be treated as a mandatory ritual regardless of the service's rules.
Respond safely
If the destination unexpectedly changes, cancel any unsigned request and stop transferring. Recheck from a trusted environment and preserve screenshots, complete addresses, and times. After broadcast, retain the hash and contact verified platform channels, without assuming that recovery is possible. Do not pay a stranger promising certain recovery or enter recovery words into a diagnostic website. Importing a production seed into several unknown tools can turn one suspected problem into multiple exposures.
Useful evidence can include the original copy source, pasted value, and device display, while hiding unrelated balances and identity details. A confirmed transfer generally cannot be undone locally. Whether a platform can assist depends on destination and process, so educational reporting should not promise unconditional recovery. Preserve the trail and use independent official contacts rather than turning urgency into another payment to an unknown helper.
Maintain controls
Maintain a recipient book containing provenance, confirmation date, and network, and independently verify later changes. Use supported withdrawal allowlists and delays where appropriate. Update devices and assess malware through trusted official tools rather than advertised cleanup downloads. The central habit is to check the complete destination every time. Prior success, a familiar displayed name, or the presence of a large balance does not authenticate the next address or make a compromised clipboard safe.
Protect changes to allowlists as well as their initial creation. Check notifications, waiting periods, and account-security requirements for new destinations. If an attacker can edit contacts or the allowlist, one setup event is not a permanent solution. Periodic review and per-transaction confirmation work together. Neither should be presented as a reason to skip the other when the value or recipient context has changed.
