NexFlow › Address poisoning scams

Address poisoning scams — the lookalike that hijacks your copy-paste

An attacker sends you dust from an address that looks almost identical to one you use — then waits for you to copy the wrong one from your history. Real incidents have cost seven figures. The full mechanics.

Updated 2026-10-06 · ~7 min read · every claim sourced and dated

Address poisoning is the scam that needs no signature, no approval, and no malware — it exploits the single habit every crypto user has: copying a recent address out of transaction history instead of re-verifying it. Documented losses run into the millions, from a trap that costs the attacker a few cents.

Every claim below names its source and date.

The mechanism, exactly

Crypto addresses are long — on Ethereum, 42 hex characters; on Solana, 44 base58. Nobody reads the whole string; everyone checks the first few and last few characters. The scammer exploits exactly that check: they generate an address that shares the first ~4-6 and last ~4-6 characters with an address the victim uses — computationally cheap with vanity-address tools — then send the victim a tiny transaction (a dust amount, or a zero-value token transfer, or a spoofed-looking “transfer” in the token history) FROM or TO that lookalike address.

The lookalike now sits in the victim’s transaction history. When the victim later sends real funds — copying “their own” address out of history to avoid retyping — they paste the lookalike instead. The funds go to the scammer. The transaction is final; there is no complaint desk for a correctly-signed send to a wrong address.

The documented incidents are seven figures

This is not a theoretical risk. In May 2024 a single victim sent ~$68M in wrapped BTC to a poisoned address — the largest single poisoning loss documented (the funds were later returned in that exceptional case, an outcome nobody should expect). Security researchers tracking the pattern logged tens of millions more in cumulative losses through 2023-25 — it is among the most reliable theft-per-dollar-spent attack patterns in crypto because the bait costs the scammer only the dust transaction’s fee.

The pattern also mutates: some campaigns spam lookalike transfers that appear as fake “USDT received” entries in wallet history (the transfers are real dust or zero-value events that render as plausible history lines), and some target exchange-deposit workflows where the user copies a counterparty address.

Why people fall for it — the check that isn’t one

The defense most users think they have — “I always check the first and last characters” — is precisely the assumption the attack is built on. Vanity generation makes matching 4-6 leading and trailing characters cheap; matching the whole string is computationally impossible for an attacker, which is the same fact that makes full verification the actual defense. The visual check feels like verification and functions as a guess.

Honest note on wallet UX: most wallets show history entries without flagging lookalike-first/last-character matches to your own addresses — the burden of catching it sits on the user, and wallets are only starting to surface “this address looks like but is not one you’ve used before” warnings.

The defense is one habit

The fix is embarrassingly simple, which is why it works: verify the whole address, not the ends. Practically: compare the middle characters the eye skips (or use the address-book feature — a saved, verified address can’t be spoofed by a lookalike in history). For large sends, the test-transaction habit is the gold standard — send a small amount, confirm receipt, then send the balance; a poisoned address fails the test transfer because the lookalike isn’t the real counterparty’s address and the recipient never sees the dust.

And the history rule: never copy an address out of transaction history for a real send. Copy it from the recipient’s verified source — their invoice, their saved entry, an address book entry you created — not from anything the chain rendered for you, because history is exactly where the trap lives.

Where it hits hardest

The pattern scales with transaction size and frequency. Routine small sends mean the copy-from-history habit fires most often exactly where users trust it — sending to "my own exchange deposit address", "the same OTC counterparty as last week", "the multisig I funded yesterday". Those are also the highest-value transfers. The attacker doesn't need to know which history entry you'll copy — they poison several of your recent counterparties with lookalikes and let your own convenience pick one.

Power users aren't immune — the largest documented victims were experienced traders moving seven figures, because the habit attack doesn't care about your technical sophistication, only about whether a particular send reused an address from history. If anything, high-frequency wallet use makes the trap cheaper to bait: more history entries means more candidates worth generating lookalikes for.

What wallets could do — and mostly haven't

The structural fix exists and a few wallets have shipped versions of it: flag history entries whose first+last characters match one of your known addresses but whose full string differs; distinguish "address you've sent to before" from "address that merely appears in your history"; render the dust entries as suspicious rather than as normal counterparties. Where it's deployed, poisoning effectiveness drops — the trap only works if history looks trustworthy.

Until that's universal, the defense stays behavioral: address-book for repeat counterparties, full-string verification for anything new, and a small test send before any large amount. The May 2024 victim's funds were returned only because the attacker chose to return them — nothing in the chain itself offers that remedy.

The verdict, precisely

Address poisoning converts your copy-paste habit into the exploit — a lookalike entry in your own history, waiting for the send. It costs the attacker cents and has taken eight figures. The defense is free: verify the whole string or verify with a test send. There is no version of partial verification that survives contact with a vanity generator.

Frequently asked