Address Poisoning: The Attack That Uses Your Own History

This attack is elegant in a way that most are not. It requires no access to your wallet, no malware, and no interaction from you at all. It works by making your own transaction history unreliable.

How it works

Step one. The attacker watches the chain for addresses that transact regularly. Yours appears.

Step two. They generate an address whose first and last characters match one you frequently send to. Generating a vanity address with matching ends is computationally cheap.

Step three. They send you a transaction from that address. Usually a zero-value transfer or a dust amount of some token. It costs them a fraction of a cent.

Step four. Nothing else. They wait.

Step five. At some point you want to send funds to the address you regularly use. You scroll your transaction history, find what looks like the right address, copy it, and send.

The funds go to the attacker.

Why it works

Almost nobody reads a full address. Wallets display them truncated, showing the first six characters and the last four, precisely because the middle is unreadable. Users have been trained by their tools to verify exactly the part the attacker has copied.

The transaction also appears in your own history, which carries an implicit trust that a pasted string from a chat message does not. It is your record, of your activity, on your device.

The variants

Zero-value transfers. A transaction of zero tokens that still appears in history. Costs almost nothing to send at scale.

Dust with a token contract. A small amount of a worthless token, which appears in your balance list as well as your history.

Fake token names. The dust token is named to resemble something you hold, so the entry looks like part of your real activity.

Automated campaigns run these against millions of addresses continuously. The economics work because a single success pays for enormous volume.

The defences that actually work

Never copy an address from transaction history. This is the whole attack. Use a saved address book entry, or get the address from the recipient through a channel you trust.

Verify the middle of the address. If you must check visually, check characters from the centre, not the ends.

Verify on a hardware wallet screen. The device shows the destination independently of the computer, which also defeats clipboard-hijacking malware.

Send a test transaction. Small amount first, confirm receipt with the recipient, then send the rest. This catches every version of this attack.

Use address book entries with labels. Most wallets support them. A saved, labelled entry cannot be poisoned by an incoming transaction.

Why test transactions keep appearing in this advice

Because they defeat an entire category of attack rather than one specific technique.

Address poisoning, clipboard hijacking, a typo that happens to produce a valid address, the wrong network, a recipient who has changed wallets: all of them are caught by sending a small amount first and confirming it arrived.

The cost is one network fee. On a layer 2 or a low-fee chain, that is cents.

If it has already happened

The funds are gone. The receiving address belongs to the attacker and no mechanism reverses a valid transaction.

What is worth doing: report the address to the chain analysis databases, check whether the destination is a labelled exchange deposit address on an explorer, and if it is, contact that exchange immediately with the transaction hash. Venues with a real compliance function, such as platforms with a real complaints process, can sometimes freeze a deposit if contacted quickly enough.

Then clean up your own history habits, because the poisoned entry is still sitting there and will look just as convincing next month.