Address poisoning: Four checks before copying from transaction history

How history can become a misleading reference

An attacker may use small or zero-value activity or token-history presentation to place a lookalike address in a wallet’s activity list. The aim is for the user to copy a recent familiar-looking entry instead of returning to the intended recipient’s instructions.

This scenario does not necessarily require the attacker to know your private key. The point of influence is destination selection for a later transfer. Unrequested activity alone therefore does not establish account takeover, but it demonstrates why activity history is not automatically a trusted address book.

Interfaces differ in what they show: abbreviated addresses, token names, events or ordered rows. A recent entry or familiar icon should not bypass the central question of who controls the address you plan to pay.

1. Visual similarity does not establish identity

A shortened display may reveal only the beginning and end of an address. A lookalike can exploit that habit while differing in the hidden middle. Open the full value and compare it with verified receiving information.

A syntactically valid address can still belong to the wrong person. Format checks may detect some input mistakes but do not authenticate the relationship between an address and the person or service requesting payment.

MetaMask’s address poisoning explanation highlights the importance of the middle characters. Use the complete value, not a remembered visual outline.

2. The receiving source matters more than row position

Open the official receiving page or instructions confirmed through an established recipient channel. An unexpected change request needs independent verification appropriate to that relationship. Do not let a similar account name authenticate itself.

If you save a contact, verify the value at the time of saving and record its network and intended use. An address book populated from poisoned history preserves the mistake rather than resolving it. The trusted input is what makes the record useful.

For a service deposit, refresh current instructions when returning. A previously used address can be genuine while a particular old invoice, network route or asset instruction is no longer appropriate for the new payment.

3. Distinguish wrong selection from clipboard replacement

With poisoned history, the pasted text may exactly match what you copied. The mistake occurred when choosing a misleading source. Clipboard replacement instead changes the value during transfer between source and destination field. Both checks matter, but they investigate different points.

Comparing the destination field only with the misleading row can prove you copied the wrong address accurately. Use an independent recipient reference, then verify that the value remains the same after pasting and at final confirmation.

If the pasted text differs from the trusted source, stop to investigate that additional problem. Do not assume every discrepancy is poisoning or every familiar-looking wrong address proves malware. Record what was selected and where the first mismatch appeared.

4. Review the final request, not just the initial selection

Check the full destination, network, asset, amount and any required extra information. If a signing device supports independent display, use its documented confirmation process and read the relevant details. A familiar account label is not a substitute for the actual destination.

Product warnings may help recognize similarities with previous addresses, but absence of a warning does not certify your intended recipient. Use available protection while retaining an independently established receiving source.

A changed request after a successful test is still a new request. If you copy again, select another account or change networks, repeat the appropriate review instead of assuming the earlier result covers those changes.

Locate the missing verification

Example: paying a previous supplier again

Marwan plans a hypothetical 250-unit payment to a supplier he paid before. A newer history entry has an address with similar beginning and ending characters. He copies it, then compares the complete value with the approved invoice instructions before signing.

The middle differs. No experimental payment is needed to establish the mismatch. Marwan confirms the correct receiving details through the supplier’s known channel, checks network and asset, and constructs a new request from that source.

The amount is an educational example, not a current price or fee. Its purpose is to show that verification starts before copying. Successful text transfer and matching end characters leave recipient identity unresolved.

What a small test can actually prove

A test can reach an attacker’s valid address successfully. Network execution alone does not prove it reached your intended supplier. If using a test after establishing the source, know how receipt will be confirmed by the real recipient through a trusted channel.

An unsolicited account claiming it received the test is not sufficient confirmation. Consider deposit minimums and fees, and check the later transfer too. The test is one part of a defined verification process, not permanent approval of every address subsequently copied from history.

Organize repeated destinations and team review

Keep a clear name, network, purpose and source of verification. Avoid one vague account label reused for different services or assets. Record the limits of what was verified rather than expanding an old note to a different use case.

In a team, distinguish approval of recipient data from execution of the transfer. Two reviewers comparing against the same poisoned row do not provide independent recipient verification. Both need access to the genuine receiving instruction and controlled records of approved changes.

Unknown activity and mistakes after sending

You can document repeated unsolicited entries and report them through supported official channels. Do not send funds back merely to signal that you noticed. Interface hiding or classification may alter presentation without erasing the public activity.

If you already sent to a wrong destination, preserve the transaction identifier, network, address and amount, then establish whether it remains pending or executed. Use official options appropriate to that state without assuming reversal is possible. Our receiving address guide provides the complete pre-transfer review.

Continue reading