Full article
Scenario: a familiar-looking address needs verification
Imagine paying a regular contractor by copying a destination from recent transfers. MetaMask describes attackers inserting similar-looking addresses into transaction history through tiny or zero-value transfers. Recognizing the beginning and end can then misidentify the recipient. This is a hypothetical workflow, not a reported incident involving this site.
This guide concerns checks before sending. An unfamiliar incoming entry alone does not establish that a private key was exposed. Do not follow unsolicited repair instructions merely because a zero-value transfer appeared.
Preparation: establish a trusted payment record
Record the recipient, purpose, asset, network and channel through which the address was obtained. Confirm unexpected address changes through an established contact method, rather than replying only to the new request. For your own wallet, obtain details from its legitimate receiving interface.
Label verified contacts by purpose and network to reduce confusion. A label helps identification but does not validate an address when first added. Keep recovery phrases, private keys and passwords out of this payment record.
Steps: verify the source, then the pasted result
Copy the complete address from verified payment information, not an unsolicited incoming entry. Expand the pasted destination and compare every segment, including the middle. Check the asset and network, then review the amount and actual destination again at final confirmation.
With a hardware wallet, compare its transaction display against the intended payment. Trezor distinguishes confirming what the device will process from determining whether someone supplied the correct recipient address. Complete both checks separately.
Costs and limits: alerts do not authenticate recipients
Comparing and recording details requires time but no blockchain fee. A separate test transfer has transaction costs and may encounter a platform minimum deposit. Check those conditions first, and verify the subsequent main payment independently.
MetaMask documents similar-address and first-interaction warnings. A new-address warning does not prove malicious intent; an absent warning does not replace verification. This process checks payment information, not every aspect of a device, website or counterparty.
Mismatch: stop approval and locate the discrepancy
If the source record, pasted field or device display differs, cancel the operation and record where the discrepancy appeared. Do not edit a few characters and immediately send, or fund a suspicious address as a test. Reconfirm through a trusted channel and investigate suspected device or clipboard problems through official support.
If already sent, preserve the transaction identifier, network, amount and actual address. Confirm status with the recipient without assuming cancellation or recovery is available. Do not make another payment to activate a refund or disclose recovery secrets to support.
Completion: preserve an auditable payment record
Before sending, confirm address provenance, full-address agreement, asset and network, amount, and final approval details. Record a hardware-display comparison only when actually performed.
Afterward, associate the transaction identifier with the order and wait for recipient confirmation before closing it. Keep address verified, transaction sent and payment received as separate states, so an unresolved transfer never silently becomes a trusted source for the next payment.
