Crypto address poisoning: verify the full destination

Crypto address poisoning places a lookalike address in your transaction history so you may copy it for a later transfer. Receiving an unsolicited entry does not by itself show that your private key was stolen. Before sending, obtain the destination from the intended recipient's verified source, compare the entire address, and keep the network and any deposit memo attached to that check.

A recent-history row can feel like a convenient address book. It is also a place where strangers can introduce an address you never chose. The practical defense starts before the next payment: establish where the destination came from, then keep that source connected to what you approve.

Why a familiar-looking history entry can mislead

The FBI describes impersonation tokens arriving from addresses that resemble previous counterparties. A shortened display can hide differences in the middle while showing matching characters at both ends. Its guidance is to check the entire destination before sending. FBI address-poisoning warning.

An entry may involve a tiny amount, a zero-value transfer or a fake token. A familiar token symbol and a plausible displayed quantity therefore need separate scrutiny. Trezor documents fake tokens that imitate a popular asset and even mimic a previous transfer's quantity. Neither the symbol nor that amount establishes the intended payment recipient. Trezor explanation of address poisoning.

Distinguish an unexpected entry from an unexplained loss of real assets. Trezor explains that address poisoning cannot drain a wallet on its own. An actual unauthorized debit needs investigation; calling every strange row “just spam” could conceal a different incident. Trezor poisoning scope.

Likewise, a request to connect a wallet or sign an approval is a separate decision about authority. The wallet connection versus token approval guide explains that boundary. A history row should never become a reason to approve an unfamiliar contract that claims to clean up the wallet.

A worked comparison: matching ends leave most digits unchecked

Ethereum-style addresses contain 40 hexadecimal digits after the 0x prefix. The following hypothetical specimens are divided into five groups of eight digits for reading. They are teaching material, not payment destinations. The ERC-55 specification describes the 40-character address representation and its mixed-case checksum encoding.

Both shorten to 0x7a4c…6f2e when only four digits at each end are displayed. That checks 8 of 40 digits: 20% of the address, leaving 32 digits unseen. In this constructed example, every one of those 32 middle digits differs. All five complete groups fail comparison.

This percentage measures how many characters were inspected. It is not a probability of theft or a claim that any particular number of matching digits establishes safety. Even one different address digit is sufficient to stop the transfer and obtain the intended destination again.

For a real transfer, preserve the address representation provided by the recipient and supported by the wallet. ERC-55 uses letter case for error detection; a different address can also have a valid checksum. A case-only difference may be formatting rather than a different underlying address. Resolve it through the wallet's validation and verified source. The inference is limited: checksum validation can help identify a typing error, but cannot authenticate the person controlling an otherwise valid address. Resolve a validation error from the original source instead of editing characters until the wallet accepts them. ERC-55 checksum specification.

Establish the destination before filling in Send

Start with a source the recipient controls

For a wallet you own, use its receiving flow and any device verification it provides. For an exchange deposit, open the official exchange app or a known saved site and select the correct receiving account, asset and network. For another person, obtain the destination through an established contact route. Confirm an unexpected address change using a previously established channel.

Two matching copies of the same unverified history entry provide no additional provenance. Copying it into a spreadsheet and then comparing the wallet against the spreadsheet preserves the initial mistake. The reference must originate outside the suspicious entry.

MetaMask explicitly advises avoiding addresses copied from transaction history and saving verified recipients in an address book. Its guidance applies when finding your own address for a withdrawal, too. MetaMask destination-verification guidance.

If someone supplied the destination as part of a trading-bot offer, also verify the operator and the purpose of the payment. The crypto trading bot scam checklist provides that broader money-route check. A correctly copied address can still belong to an operator you have never verified.

Keep network and deposit instructions beside the address

Write down the asset, receiving service or wallet, exact network, complete address and any required memo or destination tag. Record where and when you obtained them. Keep the record private as appropriate; it should contain no seed phrase, private key or login credentials.

An exact address match cannot tell you whether the receiving provider accepts that asset on the selected network. For example, XRP Ledger destination tags let a receiving business identify which customer to credit. XRP Ledger tag documentation. Use the deposit memo and destination tag checklist to verify any required separate field against current recipient instructions.

Compare the complete destination at approval

Compare all characters against the original reference after pasting, then inspect the final transaction review. Work through consecutive chunks so the middle is covered deliberately. Do not reconstruct a real destination by manually joining this article's example groups.

For a hardware wallet, compare the address shown on the device against the verified recipient source before confirming. Trezor's guidance specifically calls for checking every character at device confirmation. Reading the same shortened suffix on two screens leaves the same middle unchecked. Trezor confirmation guidance.

Only then save a recurring destination with a meaningful recipient, network, verification date and source. If its source is missing, verify it again. An address-book label records your choice; it cannot repair a choice originally copied from a poisoned row.

Carry verification through a test transfer

A test transfer checks a particular destination and receiving process. It does not validate whichever address you choose next.

Consider a hypothetical plan to send 1,000 token units. Assume the receiving provider accepts a 10-unit test, credits the full token amount and charges no receiving deduction. Network fees are funded separately in the required fee asset. After the intended recipient confirms receipt of 10 units, the remaining planned amount is 1,000 − 10 = 990 units. These amounts illustrate the handoff; actual minimums and fees must come from the provider.

Keep the same verified destination record for both transfers. Before sending the 990 units, compare the complete destination again. If a new history row supplies lookalike address B while the successful test went to address A, the test supplies no evidence that B belongs to the recipient.

Confirm receipt at the intended receiving wallet or account. A successful transaction status establishes a different fact from a deposit credited to the intended exchange account. If the test is missing, hold the larger send and resolve the asset, network, memo, minimum and destination with the provider.

Use warnings and a worksheet without outsourcing the decision

MetaMask's current help describes a blocking warning for destinations resembling a previously used address and a warning for a new destination. Trezor Suite describes filtering suspicious history entries. These are documented provider features, with different roles and coverage. A clean-looking row or an absent warning cannot establish recipient ownership. MetaMask warning behavior, Trezor history filtering.

Use this worksheet before each transfer or when updating a saved recipient:

Kraken documents clipboard malware as another way a copied destination can change. If the pasted value differs from the source, stop using that transfer flow and investigate the device through trusted support. Repeatedly pasting until something looks familiar leaves the cause unresolved. Kraken guidance on dust and address substitution.

If a suspicious entry arrived, or funds already left

For an unsolicited token or history entry, avoid interacting with unfamiliar contracts or following embedded links. Use the wallet's supported spam or hiding controls where available. Kraken advises against claiming, swapping, sending or approving unknown tokens. Sending a “cleanup” transaction is unnecessary for verifying your next recipient. Kraken guidance for unsolicited assets.

If you already sent real assets to the wrong destination, stop further payments. Preserve the transaction hash, network, asset, amount, time, exact destination and the source you copied. Contact relevant exchanges or providers through their official channels promptly, and use appropriate reporting channels for your location. The FBI directs U.S. victims to IC3. FBI reporting guidance.

Ethereum's security guidance explains that transfers are irreversible and that return may depend on the recipient cooperating. Do not assume a wallet vendor can reverse a confirmed transfer. Never provide a recovery phrase or private key to someone promising recovery. Ethereum transaction and support-scam guidance.

If an exchange API credential was also exposed while seeking assistance, follow the separate credential incident-response procedure. That access problem requires containment in addition to documenting the misdirected transfer.

Before the next send, complete one recipient record with the original source, entire address, network and deposit instructions. Carry that same record into the final approval. Whenever a field changes, repeat the verification before signing.