Address poisoning is a scam in which an attacker generates a lookalike address whose first and last characters match one you already use, then plants it in your transaction history with a dust or zero-value transfer, hoping you will one day copy it instead of the real address. The planted transfer steals nothing by itself: it creates no approval, touches no key and gives the attacker no control over your wallet — the entire attack is a bet on a future copy-paste mistake. The defence is therefore behavioural: never source an address from transaction history, verify the middle of an address rather than only the truncated ends, and send a small test transfer before a large one. No wallet can reverse a transfer you approved, so in a fully non-custodial wallet such as WATS, where the user holds the keys and WATS never holds one, that check before you sign is genuinely the last line of defence.
The scam that exploits copy-paste
Most crypto scams attack your keys or your signatures. Address poisoning attacks something softer: your habits. The attacker never touches your wallet and never asks you to sign anything. They simply arrange for a lookalike address to appear in your transaction history — and wait for the day you copy it instead of the real one. One inattentive paste, and a transfer meant for your own address or a regular counterparty goes to the attacker, irreversibly.
How the poisoning actually works
The attack starts with generation. Crypto addresses are long enough that attackers can cheaply grind out vanity addresses matching the first and last few characters of yours or of someone you transact with — the exact characters wallet interfaces display. Then comes seeding. Sometimes it is a tiny "dust" transfer of a few cents sent to your address from the lookalike. On EVM chains it is more often a zero-value token transfer: the ERC-20 standard permits transferring an amount of zero, so an attacker can call transferFrom referencing your address without holding any allowance and still emit a perfectly valid Transfer event — which explorers and wallet activity feeds render as an ordinary transaction between you and the fake address. Cheaper still per victim are throwaway token contracts that emit fabricated Transfer events, in batches, for tokens nobody ever held. Whichever method is used, the attacker's cost is a little gas, and the result is identical: a convincing decoy now sits in your history, patiently waiting.
Why it works: truncation and trust in history
Two interface conventions make the trap effective. First, wallets and explorers almost universally truncate addresses to something like 0x1a2b…9f8e, so a lookalike engineered to match those visible characters is indistinguishable at a glance. Address checksums do not rescue you here — a poisoned address is a valid, correctly checksummed address that simply belongs to someone else, so there is no malformed input for software to reject. Second, people treat their own transaction history as a trusted address book: "the address I sent to last week" feels safe to reuse. Poisoning weaponises exactly that trust. Nothing about the fake entry looks anomalous; it sits beside legitimate transactions, formatted identically, often mirroring a real counterparty's truncated form.
What poisoning can and cannot do
Worth stating plainly: a poisoning transaction, by itself, takes nothing. Receiving dust does not compromise your keys; a zero-value transfer does not grant any approval; the attacker gains no power over your wallet. The entire attack is a bet on a future mistake by you. That is good news — it means the defence is entirely behavioural, and unlike a key compromise there is nothing to remediate. Ignore the dust (interacting with unknown "gift" tokens is a separate scam family) and the decoy stays harmless forever.
Why hardware and authentication do not stop it
This is the part people misjudge. Every layer that protects a key — a hardware device, a passkey, a tap-to-authenticate card — answers one question: is the right person approving this transaction? Address poisoning never disputes that. The signature is genuine, the approval is deliberate, the key is uncompromised; only the destination is wrong. The WATS NFC Metal Card is a clean illustration of the distinction: it stores no private key at all, it taps to authenticate to keys living in the WATS apps, and it is closer to a physical security key than to a cold-storage vault. That makes it strong protection against someone else moving your funds, and no protection whatsoever against you sending funds to an address you copied from the wrong row of your history. The destination check has to happen on screen, by you, before you approve — which is why blind-signing anything you have not read is the one habit worth abandoning first.
The habits that make you immune
Four habits close the door. Never copy addresses from transaction history — take them from the destination's own interface, an official page, or a saved contact. Verify more than the ends: before signing, check a mid-section of the address too, since lookalikes are ground to match precisely the ends that interfaces display. Use a saved contact or a human-readable name service for recurring counterparties, so routine sends never involve copying at all. And for large or first-time transfers, send a small test amount and confirm arrival before committing the rest. Combine these with the broader hygiene in wallet security best practices — and remember that the moment of signing is always the last line of defence, the same principle that governs connecting a wallet to a dApp safely.
Where a wallet like WATS fits in
No wallet can undo a transfer you approved, so the practical question is whether your wallet keeps the decision in your hands and removes the friction that makes people rush. WATS is fully non-custodial: the user holds the keys, WATS never holds one, across Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana and TON. On the friction side, WATS charges network fees in one token, ATS, instead of each chain's native gas token — using ERC-4337 account abstraction on EVM and LayerZero OFT so a single ATS balance works omnichain. That is not a discount; it changes which token pays, not what the transaction costs. What it does change is behaviour: the small test send that would otherwise be skipped because you hold no gas token on that particular chain becomes something you can always do. ATS collected as fees feeds a burn that takes supply from 100M down to 30M, and WATS is the first and only wallet to combine ERC-4337 and OFT single-token fees with that burn; the mechanics are on the ATS fee page. If you take one concrete step after reading this, make it this one: stop sourcing addresses from your history, and the next time you pay a new address in WATS, send a small test amount first and verify the middle of the address, not just its ends, before you approve the rest.
Frequently asked questions
What is an address poisoning attack?
It is a scam in which an attacker generates a lookalike address matching the visible first and last characters of one you use, then plants it in your transaction history via a dust or zero-value transfer. The attack takes nothing by itself — it waits for you to later copy the fake address from your history and send funds to it. The defence is behavioural: never source addresses from history, and verify beyond the truncated ends.
I received dust or a strange token from an unknown address — am I compromised?
No. Incoming transfers cannot steal keys, create approvals or control your wallet — anyone can send anything to a public address. The risk arises only if you later copy the attacker's address by mistake, or if you interact with an unknown token's contract (a separate scam pattern — simply do not touch it). Ignore the dust and your funds remain exactly as safe as before.
Does a hardware device or an NFC card protect me from address poisoning?
No, and WATS is explicit about why. The WATS NFC Metal Card stores no private key; it taps to authenticate to keys living in the WATS apps, closer to a physical security key than to a cold-storage vault. Authentication proves who is approving a transaction, not where the funds are going — and in address poisoning the approval is genuine and the destination is wrong. Only reading the destination address before you approve defeats this attack.
How should I verify an address before sending?
Check more than the ends: lookalikes are generated specifically to match the first and last characters that interfaces display, so compare a middle section as well. Better still, avoid manual comparison for routine payments by using saved contacts, and for large or first-time transfers send a small test amount and confirm it arrived before sending the remainder. In WATS, network fees are charged in ATS rather than each chain's native gas token, so that test send is possible on any supported chain without first sourcing a separate gas asset.