Your transaction history is not a contact list.
Address poisoning works because people often treat it like one.
The attacker does not need your seed phrase. They do not need malware on your device. They need one later moment when a familiar-looking address in recent history feels trustworthy enough to copy.
Replay the scam from the victim’s screen
Suppose you regularly send USDC to a treasury address ending in 7A3F.
- You make a legitimate transfer to the real treasury address.
- An attacker watching public blockchain activity sees the relationship.
- The attacker generates a different address with a similar visible prefix and suffix.
- A tiny, zero-value or counterfeit-token transaction places that lookalike in your activity history.
- Days later, you open the wallet, recognise the shortened address and copy it for the next payment.
- You sign a perfectly valid transaction—to the attacker.
The wallet did not necessarily malfunction. The blockchain did exactly what the signed transaction requested. The failure happened earlier, when transaction history was promoted from record of past activity to source of recipient identity.
Why the first and last characters are the trap
Long crypto addresses are usually abbreviated because humans cannot comfortably recognise the full string. That creates a visual shortcut: people remember the beginning and end.
Attackers can search for vanity addresses that imitate those visible groups while the middle differs.
MetaMask’s current guidance explicitly warns users to inspect middle characters rather than relying only on the start and end. MetaMask also says it now shows blocking warnings when a destination closely resembles one previously used but differs in the middle.
Those warnings help. They do not turn a shortened address into an identity system.
The test transaction can become part of the attack
A small test transfer is normally a good control. It proves that a route works and that the intended recipient can receive the asset.
The mistake is copying the destination for the larger payment from history after the test.
An attacker can poison the history between the small transfer and the large one. The safer sequence is:
- Obtain the destination from the recipient, a verified address book or your own receiving hardware wallet.
- Verify the network and the full address, or multiple separated groups including the middle.
- Send the small test.
- Confirm receipt through the same authenticated channel.
- Return to the original verified destination source for the larger payment.
- Reverify on the signing screen before approval.
The test proves delivery. It does not certify every later address shown in the activity feed.
A hardware wallet can sign the poisoned address correctly
This attack exposes an important limit of trusted displays.
A hardware wallet can show the exact destination that will be signed. It cannot know which person or treasury you intended to pay.
If you copy the attacker’s address and then carefully confirm the same attacker address on the hardware screen, the device has done its job. Your destination-verification process has not.
The hardware screen is a second checkpoint, not a substitute for an authenticated source of recipient identity.
Four things that look similar but require different responses
| What you see | What may be happening | Primary response |
|---|---|---|
| Lookalike address appears in history | Address poisoning | Ignore history as destination source; verify independently |
| Unexpected tiny UTXO or transfer | Dusting or spam activity | Privacy awareness; do not infer key compromise |
| Copied address changes before signing | Clipboard malware | Stop; clean the host and verify on trusted display |
| Website asks for seed or suspicious approval | Phishing or wallet-drain attempt | Do not sign or reveal recovery material |
A poisoned history entry normally does not mean the private key has leaked. Moving every asset to a new seed is unnecessary unless there is separate evidence of key compromise.
For recurring payments, replace memory with a controlled address record
The strongest defence is to stop reconstructing recipient identity from recent activity.
For a personal wallet, use a verified address book or retrieve your own receive address from the receiving wallet and confirm it on the hardware device.
For a business or treasury, record the recipient, chain, asset or token contract and destination together. Require a fresh verification step before changing the destination. High-value workflows can add two-person approval and exchange withdrawal allowlists.
An allowlist is only as good as its initial enrolment. Saving a poisoned address permanently would turn a temporary deception into a durable one.
If a poisoned transaction appears, you usually do not need to “clean” the wallet
You cannot stop strangers from sending transactions to a public blockchain address. Hiding a spam entry in the interface can reduce clutter but does not remove it from the chain.
Do not send another transaction merely to push the correct address back to the top of history. That creates more activity without fixing the trust model.
Instead:
- mark or hide suspicious entries where the wallet supports it;
- check saved contacts and allowlists;
- warn other authorised operators;
- preserve the transaction hash if the campaign may need reporting;
- use an external verified source for the next destination.
If you already sent to the lookalike
Record the transaction hash, network, asset, amount and destination immediately. Check whether the address is associated with a centralised service, preserve the intended-recipient evidence and report the scam through relevant wallet, exchange or law-enforcement channels.
Confirmed blockchain transfers generally cannot simply be reversed. MetaMask likewise states that it cannot retrieve funds from an irreversible self-custody transaction.
Do not let the first loss create a second one through a private “recovery expert” promising guaranteed retrieval.
The habit to remove
Address poisoning is not mainly a lesson about vanity-address generators. It is a lesson about a bad interface habit:
Recent history tells you what address was involved before. It does not tell you who that address belongs to now—or whether it was ever the recipient you meant to trust.
For every material transfer, derive recipient identity from an authenticated source, then use the wallet history only as evidence of what happened.
For exchange withdrawals, use the withdrawal checklist. If the problem is an exposed root secret rather than a poisoned address, use the seed phrase incident runbook.
Primary sources
- MetaMask: address poisoning scams
- MetaMask: reporting scams and irreversible transactions
- Trezor: address poisoning guidance
No affiliate link is used in this article.
