Address poisoning and look-alike recipient strings
Address poisoning exploits familiar-looking address fragments in account history. Verify the destination against the recipient’s trusted receive instructions, not a recent-history entry.
Worked example
| Pattern | Why it misleads | Better check |
|---|---|---|
| Matching first/last characters | Truncated displays hide the middle | Compare the full address |
| Unsolicited token activity | History entry looks familiar | Use an independently saved recipient |
| Checksum-valid look-alike | Checksum checks spelling, not identity | Verify source and network |
Worked history trap
A wallet abbreviates both a real recipient and a look-alike as the same beginning and ending fragments. Copying the most recent entry can select a different middle section. Expand the full address and compare it with a trusted record before using it.
Keep source and syntax checks separate
A checksum can catch an accidental case error, but an attacker can generate a correctly checksummed address they control. A token logo, explorer name tag or small unsolicited transfer does not authenticate the sender or turn history into an address book.
Common pitfalls
- Do not send a reply transfer to “test” an unsolicited entry.
- A copied address needs a recipient and network context.
Related references
Primary sources
Examples explain identifiers. They are not investment recommendations.