Address poisoning is a scam where an attacker sends a dust transaction from a lookalike address: the same first and last characters as one you have paid before, different in the middle where nobody looks. The poisoned entry then sits in your transaction history, waiting to be copy-pasted.
The defense is mechanical, not vigilance-based: never copy addresses from history, verify from the source (an invoice, a web3 name), and prefer names over hex entirely. The scam works because humans pattern-match beginnings and endings; removing the hex from the workflow removes the attack.
Address poisoning is a scam pattern that works on copy-paste behavior: an attacker watches the chain for transfers to a victim's address, then sends a dust transaction from a lookalike address engineered to match the victim's, differing in a few characters at the start or end. The fake entry lands in the victim's history, and the next time they copy an address from the recent list, they take the poison one.
The exploit's whole leverage is that addresses are unverifiable by eye. A hex string agrees with another for the few characters a human actually reads, and wallets often display exactly those, the leading and trailing ones, which is the surface the attack forges.
The defenses are mechanical and few. Verify against a full-character comparison, ideally from a source you control rather than your own history. Use name resolution so the human-readable layer carries the verification. And treat the recent-transactions list as history to audit, never as an address book to copy from. Wallets that display more characters raise the cost of forgery; the discipline closes the rest of the gap.
A treasurer copying a recurring counterparty's address from the wallet's recent list takes a lookalike that arrived last week with a small transfer. The payment settles to the scammer, finally, with no reversal path. The same copy made from the counterparty's invoice, or via their verified name, had no failure mode.
U.CASH checkouts display the payment address per invoice and support web3 names everywhere an address can appear, so payers verify against the source instead of scavenging history.
Any business that pays by copied addresses carries this risk at scale, and payout operations formalize the defense: destinations live in a validated list, never in history, and full-address comparison is a system property rather than a person's patience. U.CASH batch tooling validates destinations at entry, which is where this class of loss goes to die.
Every term behind the rails, the assets, and the settlement.