Scam patterns
Address-poisoning transfers
An attacker creates history entries using addresses that resemble trusted counterparties.
In this article
The attack targets the address you copy
Address poisoning places a misleading entry in a wallet’s transaction history. The attacker uses an address that resembles a genuine counterparty, hoping the owner will copy it when making a later payment. An unsolicited incoming transfer does not, by itself, authorise spending from the receiving wallet. The loss occurs when a subsequent outgoing payment is approved with the wrong destination. MetaMask explains the transfer-history mechanism.
The deception exploits how people read addresses. A wallet may display only a prefix and suffix, while the characters in between are hidden. Two different addresses can consequently look identical in the compact interface. A recognisable abbreviation is a display convenience, not a verified identity. The same problem applies when an address is copied from an exchange withdrawal history or a screenshot instead of the wallet itself.
Reconstruct the sequence before describing the loss
Consider a hypothetical business that previously paid supplier A. Its bookkeeper later sees a small transfer associated with address B, which shares the visible beginning and ending of A. The bookkeeper copies B into the next payment. There are now at least 3 relevant records: the genuine earlier payment, the misleading history entry and the later transfer to B. Looking only at the final transaction cannot explain how the destination was selected.
Preserve those records separately. Record the chain, full addresses, transaction identifiers, token contract and timestamps. A token’s displayed name is insufficient: an attacker can choose a familiar label for an unrelated asset. A tiny amount also does not make an entry trustworthy. In the example, the small transfer was useful to the attacker because of its position in the interface, not its economic value.
Check the destination independently
Retrieve a recipient’s address from a previously verified address book or confirm it through an established contact channel. Compare the entire value, including the middle characters, on the final confirmation screen. MetaMask’s guidance explicitly warns against treating copied history as a reliable address book. A warning about an unfamiliar or similar address deserves an independent check; dismissing it because the shortened text looks familiar repeats the original mistake.
A test payment can establish that a recipient received a small amount, but only if that recipient independently confirms it. Sending a test and checking that the transaction succeeded merely proves that the entered address received the test. It does not prove that the address belongs to the intended person. The destination used for the larger payment must also remain the same verified destination.
What the records establish
A close visual match and a transfer pattern may support an address-poisoning explanation. They do not automatically identify the person controlling the receiving address. Reports should distinguish the observed sequence, the user’s account of how the address was copied and any further attribution evidence. That separation makes the finding usable without pretending that a blockchain label provides an identity.