A familiar receiving address? Four checks before sending

Why a familiar-looking address can mislead

MetaMask describes address poisoning as a pattern that aims to place activity involving a lookalike address in a wallet’s history, hoping the user later copies it as a destination. The beginning and ending characters may resemble a familiar address while the middle differs. An abbreviated display can hide that difference.

This is distinct from clipboard replacement, where malicious software changes copied data before or during pasting. Another possibility is simply choosing an old account or opening receiving details for the wrong network. Similar symptoms do not justify assuming one diagnosis.

Your transaction history records activity. It does not automatically certify each participant as a trusted contact. An unsolicited transaction appearing there is not evidence that its sender is your intended recipient, nor does its appearance alone establish that someone has obtained your private keys.

1. Open the correct receiving source

For your own wallet, open Receive from the intended account on the intended network. For a service, use current deposit instructions within your official account. Avoid deriving the destination from a sponsored advertisement, private support message or recent history entry simply because it looks familiar.

When a person sends changed payment instructions, verify the change through an established channel. An urgent message or a familiar contact name is not enough to authenticate a newly supplied address. If you cannot confirm where the instruction came from, do not send a small amount as a substitute for resolving its identity.

Record non-secret payment references where useful. Keep enough information to identify the intended invoice or recipient without copying recovery phrases or private keys into an administrative note. The record should help you check the payment, not become a second place where spending secrets are exposed.

2. Compare the complete address

After pasting, inspect the value actually present in the destination field. Use a view that reveals the full address rather than only an alias or shortened prefix. If your signing device supports address confirmation, follow its official method and compare its display with the trusted receiving information.

Independent confirmation provides another place to review the request; it does not justify reading only a few characters. Avoid manually retyping long addresses from memory as a general solution, because transcription creates its own errors. Transfer the trusted data through the supported method, then verify what the application will use.

A saved contact can help organize known destinations, but changes to that contact still require review. A familiar label can conceal a different underlying value. Treat an address-book update as a change to payment instructions, with a reason and a verified source.

3. Review asset, network and extra fields separately

Some address formats look valid across multiple networks. That does not prove the receiving service supports every network you can select. Compare the withdrawal network with the current deposit network, and check the asset itself. A token name or logo alone is not a reliable identifier for a custom token.

Some services require a destination tag, memo or other account identifier. When the official receiving instructions require one, it is part of the transfer data. A correct address does not repair a missing mandatory field or an unsupported network choice.

Also check deposit minimums and any invoice expiry. A technically valid old address is not proof that an old payment request remains appropriate. Services may require a new request to associate the payment with the correct account or invoice. Follow the receiving workflow rather than inferring acceptance from a successful paste.

4. Read the final confirmation before signing

Review amount, destination, network, fees and any unexpected permission request. Obtaining a receiving address does not normally require granting an unknown party spending rights. If the application asks for something unrelated to the task, pause until you understand its purpose.

A limited test may help in a suitable, already verified workflow after considering fees, minimums and receiving rules. It does not eliminate checks for the next transfer. A changed address, network or deposit instruction creates a new situation that needs its own review.

Do not let time pressure bypass this final check. A large number of successful previous payments does not establish that the current request is correct. Concentrate the review at the points where destination data is obtained, transferred and approved.

Distinguish the possible errors

Example: copying from misleading history

Suppose Basel sees a small incoming activity entry involving an address similar to a regular supplier’s. He selects it from history, then opens the supplier’s verified payment instructions before confirming. The middle characters differ. The issue is destination selection, not the fee or amount.

Basel cancels the unsigned request and rebuilds it from the trusted source. He does not need to reveal his recovery phrase to investigate the misleading entry. In a separate example, a user matches an address correctly but chooses a network the receiving exchange does not support. Address checking succeeded; network checking did not.

QR codes and actions after a mistake

A QR code transports data; it does not certify who created it. After scanning, review the fields the application populated, including any amount and additional parameters. The same source and confirmation checks still apply.

If you notice a discrepancy before sending, stop rather than repeatedly attempting the payment. If clipboard substitution is suspected, resolve the device problem before using it for further sensitive operations. If you already sent, record the transaction identifier, network and destination, check the status, and contact the relevant service through its official channel.

Do not assume a confirmed transfer can be cancelled. Recovery promises delivered by private message, particularly demands for an advance payment or recovery phrase, create another risk. Our transaction reading guide explains how to separate network evidence from an application’s status message.

Continue reading