UNDERSTAND · CHECK · PRACTISE
Address poisoning: spot the lookalike address trap
You want to send crypto to someone again. An address in your history starts and ends like theirs. That is exactly the shortcut this scam tries to exploit.
Useful first: Wallet address, private key and recovery phrase explained
THE SHORT ANSWER
Address poisoning tries to make you copy an address resembling your intended recipient’s. Obtain it from its source, then compare the whole address before sending. An unsolicited incoming transfer alone does not prove your keys were stolen.
Three words before we start
- Public address
- An account identifier. Visual similarity does not prove that two addresses identify the same account.
- History
- The displayed activity list. It is not a list of approved contacts.
- Address poisoning
- An attempt to place a misleading address in your history and influence a later copy-and-paste.
A tiny transfer, a lookalike address
The mechanism documented by MetaMask and Trezor involves activity linked to a lookalike address. On a later transfer, the recipient may copy that address, believing they recognise their usual contact.
In the exercise below, “71c4 · 12ab · f2a8” and “71c4 · 88cd · f2a8” share the same ends. Their middles differ. These are invented, incomplete fragments, never addresses to use.
Check in two places
First, obtain the address at its source: the relevant account’s receiving screen, or recipient instructions obtained through an already trusted channel. Do not choose it simply because it appears in a recent history entry.
Then compare that reference with the full address on the confirmation screen. If you use a hardware wallet, check the device display too. An address copied from the wrong source can be reproduced accurately everywhere.
A small test transfer can supplement these checks, but the intended recipient must confirm receipt on the correct network. “Success” in an explorer means the transaction succeeded, not that the intended person received the funds.
Unsolicited receipt and stolen keys are different findings
An unsolicited incoming entry does not by itself prove someone can sign for you. An actual outgoing transfer you did not authorise warrants a separate review: account, network, asset, amount and existing permissions.
Wallet alerts can help, but the absence of an alert is not a substitute for your reference. Do not follow links or “cleanup” offers associated with unknown activity.
02 · PRACTISE, THEN UNDERSTAND THE ANSWER
3 situations to work through
Each answer has an explanation. Use a hint if you need one; there is no timer.
MADE-UP SITUATION · NO REAL ACTION
The ends match
Compare two fictional fragments. They are deliberately shortened and cannot be used to send funds. The reference comes from the recipient; the other line comes from history.
- Recipient reference
- 71c4 · 12ab · f2a8
- Copied from history
- 71c4 · 88cd · f2a8
I need a hint
Read the middle group.
Read all explanations at my own pace
The ends match
Compare two fictional fragments. They are deliberately shortened and cannot be used to send funds. The reference comes from the recipient; the other line comes from history.
Reasoning: One difference in these characters establishes that the references are not identical. A real transfer needs the entire address and a trusted source, not merely more confidence in copy-and-paste.
Resemblance does not prove identity.
A receipt you did not request
A zero-amount incoming entry appears in history. You have signed no new request and no actual debit has been verified in this scenario.
Reasoning: The exercise does not declare the account “safe”: it only shows that this evidence is insufficient to conclude key theft. Do not turn unknown history entries into a trusted address source.
Describe the observed fact before drawing a diagnosis.
The test transfer says “Success”
You made a small fictional transfer to test the recipient. The explorer shows “Success”, but the intended person has not confirmed receipt yet.
Reasoning: A test becomes useful when you check that it arrived in the right place. Technical success is one fact; the expected account and receipt confirmation are others. No additional amount is needed to reason about these facts.
Network success and the right recipient are not synonyms.
Two more useful questions
Is checking only the start and end enough?
No: the exercise specifically shows two fragments sharing those characters. Obtain a trusted reference and compare the whole address.
Does an explorer prove the recipient’s identity?
An address and transaction status do not by themselves establish a person’s identity. They help verify network activity; confirmation by the intended recipient is a separate check.
Sources and further reading
- MetaMask — Address poisoning · in English
- Trezor — Avoid address poisoning · in English
- MetaMask — Check activity in an explorer · in English
- MetaMask — Sending tokens · in English
Page updated on
Documentation checked on · WhyTheBlockchain · Editorial approach