Address poisoning: the address you copy-paste may already be swapped
Before a transfer, you habitually open your history and copy the address from the last payment. That completely natural move is exactly the step address poisoning is built to hijack. It doesn't steal from this transaction — it patiently waits for your next copy. Here's how it works, the three ways it slips into your history, and which characters to check before you send.
Picture something most people have done without a second thought: you want to send USDT again to someone you deal with regularly, so you open your wallet's transaction history, find the last payment, copy the address, paste it into the send field, and hit confirm. You never actually looked at the address — it's "the same one as last time." Address poisoning bets on exactly that fluency and trust.
It's really a trick of the eye
A crypto address is a long string of letters and numbers — too long for anyone to memorise in full. Most people only recognise the first few and last few characters and skip the big middle section entirely. Scammers work off that habit: they run tools that generate addresses in bulk until they land one whose first and last characters exactly match an address you use — a twin that differs only in the middle.
Once they have the twin, they push a transaction to your wallet — maybe a tiny transfer, maybe a token that looks like USDT — with one goal: to make that fake address appear in your transaction history, sitting right next to the real one. The next time you go to "copy the address from the last payment," you may well copy the twin. The start matches, the end matches, you glance and approve, and the money goes straight to the scammer. It needs no password, no signed approval — only that you tapped the usual Copy.
Three ways it slips into your history
Same logic, but it lands in these three common shapes. Knowing what each looks like means you'll get suspicious the moment you spot one in your history:
- A tiny or zero-value transfer. You get an odd little deposit, an amount small enough to look like loose change, from an address whose ends look very familiar. You might even be pleased that "someone sent me a bit extra" — but it's there to take a seat, planting the twin address at the top of your history.
- A same-name fake token. The more common one: you receive a "USDT" deposit whose token name and symbol look right, in a non-trivial amount. But it's a same-name knock-off token the scammer minted, worth nothing, whose only job is to leave a look-alike address in your history. This is why tokens that appear in your wallet out of nowhere can't be taken at face value.
- A zero-value approval type (transferFrom). Technically there's also a version where the scammer triggers a zero-amount transfer event involving your address, so your history shows "you had dealings with some address." Again it's about manufacturing familiarity and planting the fake. It doesn't move your coins, but it's the same bait for your next transfer.
Why matching ends is nowhere near enough
Plenty of people think they do check — "I looked: it starts 0x7a, ends 3f9, both match." That's exactly the problem. The start and the end are precisely what the scammer copied. What you thought was verification checked only the parts he deliberately made identical; the middle, the one section he can't control and the only part that differs, is the part you never looked at.
Every character in an address matters. One wrong character and the money goes somewhere completely different — and on-chain, a confirmed transfer cannot be reversed. There's no support desk that can stop it or refund you. This isn't like misdialling a phone number and redialling; it's closer to posting cash through the wrong letterbox. Once it's gone, it's gone. Because the cost is irreversible, checking can't stop at the ends.
The reliable habit is to treat the address like a password: sample a few characters from the middle too, or check the whole string segment by segment. Tedious, yes — far cheaper than the regret afterwards.
Five checks before you send
You don't need to become a security expert. Turn the following into muscle memory and you'll block the vast majority of address poisoning:
- Stop copying addresses from your transaction history. This is the whole attack's weak point. Whoever you're paying, get the address fresh from them directly or from an official channel, or use your wallet's built-in address book (whitelist). Don't scroll history for convenience.
- Save regular addresses to your address book, and name them. Most wallets let you add an address as a contact. Verify it once when you save it, then send by picking the name each time instead of pasting an address — the twin gets no chance to jump the queue.
- Check the middle, not just the ends. Sample a few characters from the middle, or compare segment by segment. Matching ends only means "similar," not "the same."
- Send a small test amount first. Before a large transfer, send a little, wait for the recipient to confirm they actually received it, then send the rest. Note: a test only counts if you've already verified the full address — it doesn't replace verifying.
- Confirm the chain matches. The same coin has different address formats on different chains, and a wrong-chain transfer is just as unrecoverable. If you're unsure which chain an address belongs to, use the USDT network checker to see clearly first.
If you've already sent to the wrong address
Start by accepting an uncomfortable fact: once an on-chain transfer confirms, it can't be reversed, and no official party can "pull" the coins back. What tends to surface at this point — the "I can recover it for you" DM or support account — is almost always a second layer of the scam, taking advantage of your panic to charge you another fee or "deposit." What you should actually do is keep the transaction hash and the other address, preserve the evidence on a block explorer, and report it where reporting is warranted. For the full steps, see Scammed? The first 4 things to do — and don't get taken a second time in the panic.
We lined up a few addresses that share the same first and last characters and differ only in the middle. The most direct takeaway: by eye alone, scanning the ends, the two are genuinely indistinguishable — you have to spread the middle section out and compare character by character before the difference shows. Which is why our own transfer rule is deliberately dull: always pick a name from the address book, never touch the copy button in transaction history.
When you transfer, watch three things: whether the address was copied from history (if so, get it fresh); whether you actually checked a few of the middle characters, not just the ends; and whether you test with a small amount, confirm receipt, then send the large one. Pass all three and address poisoning basically can't reach you.
FAQ
They only sent me 0 coins or a bit of dust, and I lost nothing. Why should I care?
That transaction doesn't take your money. Its purpose isn't to steal from you right then, but to plant a look-alike address in your history so that the next time you copy an address from history, you send to the wrong person. So the real risk is in your next transfer, not in the dust itself. Treat an unexplained small deposit as a warning: don't save that address to your contacts and never copy from it.
I receive with an ENS or domain name. Does that make me immune to address poisoning?
It lowers how often you copy a long address by hand, but it isn't immunity. You still need to confirm your wallet resolves the name to the correct address, and some interfaces can show a similar-looking fake name. The name is only a wrapper; what actually gets sent is still that string, so before sending, read the full address it resolves to.
If I always send a small test amount first, am I safe?
Sending a small amount to confirm receipt is a good habit and catches wrong-chain or typo errors, but it doesn't stop you sending both the small and the large amount to the same wrong address. A test only helps if you first verify the full address character by character and confirm the recipient actually received it, then send the rest. Testing without verifying just splits the same mistake into two transfers.