Address poisoning: the address in your history is not the one you paid

Address poisoning is one of the few attacks that requires no exploit, no signature from you, and no interaction with a malicious site. It works entirely on how wallet software displays addresses.

The mechanism

An address on most EVM chains is 20 bytes, shown as 40 hexadecimal characters. Almost no interface shows all 40. They show something like 0x7a2f...9c41 — the first four or six characters, an ellipsis, and the last four.

That abbreviation is the whole attack surface.

Generating a private key whose address matches a target's first and last characters is cheap. Tools that do it are ordinary vanity-address generators, and matching eight or ten characters takes seconds on a laptop.

The attacker then does one of two things:

1. Zero-value transfer. A crafted transferFrom call moving zero tokens, which many token contracts permit, from the lookalike address to yours.
2. Dust transfer. A trivial amount of a token, sent from the lookalike address.

Either way the lookalike address is now sitting in your transaction history, immediately adjacent to the real one, and abbreviated to look identical.

Later, you go to send funds to a counterparty you have paid before. You scroll your history, find what looks like the right address, copy it, and pay the attacker.

Why "just check carefully" fails

The usual advice is to verify the address. In practice:

• The two addresses match at exactly the characters your interface displays.
• The transaction sits next to a genuine one, at roughly the plausible time.
• Nothing about the poisoned entry is visually flagged, because nothing about it is technically invalid.

Vigilance is being asked to compensate for an interface that hides the information needed to be vigilant. That is not a strategy — it is a single point of failure with a human in it.

What actually works

Use an address book. Every major wallet has one. Save a counterparty once, verified against the original source, and select the saved entry thereafter. This removes the history from the loop entirely.

Copy from the source, never from history. The invoice, the message, the exchange's withdrawal page. Your own transaction history is not a source of truth about who you meant to pay; it is a record of who you did pay, which is a different claim.

Verify the middle, not the ends. If you must check an address visually, check characters from the middle of the string. Attackers optimise for what is displayed, and the middle is what is hidden.

Send a test transaction for large transfers. A small amount first, confirmed received by the counterparty out of band, then the rest. The cost is one extra fee.

Use ENS or a name service where available — but confirm the name resolves to the address you expect, once, and save it. Name services move the problem rather than removing it if you never verify the resolution.

What wallets should do, and some now do

A number of wallets have added defences worth looking for when you choose one:

• Hiding or collapsing zero-value transfers by default.
• Warning when a recipient address closely resembles one you have used before.
• Showing more of the address, or displaying it in coloured character groups so mismatches are visible.

The vulnerability is not in the chain. It is in the decision to abbreviate a 40-character identifier down to eight and expect people to treat the result as unique.

If you have already sent to a poisoned address

There is no recovery mechanism. A confirmed transaction on a public chain is final, and the recipient is not obliged to return anything. What you can do:

1. Record the transaction hash and the attacker's address.
2. Report it to the chain's explorer, which may label the address and warn others.
3. Check whether the funds move to a service with know-your-customer requirements, in which case a report to that service and to law enforcement has some chance.

None of that is likely to return the funds. The realistic outcome is that the address book habit is worth adopting before you need it rather than after.

What is address poisoning?

Address poisoning is an attack that places an address resembling one you already use into your own transaction history, so that you copy it later by mistake. Nothing is stolen at the moment of poisoning; the loss happens when you pay, from your own wallet, entirely voluntarily.

It works because interfaces abbreviate a 40-character identifier to about 8, and matching 8 characters is cheap.

Which defences actually work?

Rows 4 and 5 are the whole answer. The first row is the advice most people are given, and it asks you to compensate for an interface that hides what you would need.

What should you do about the poisoned entries?

Nothing can remove them — the chain is append-only. What you can do is stop them being reachable:

• Hide zero-value transfers if your wallet offers the setting.
• Save every counterparty the first time, verified against the original source.
• Never re-derive an address from your history, which is a record of who you did pay, not who you meant to.

Further reading in wallet risk, risk analysis for addresses you have already touched, and transaction safety for the send itself. The MetaMask guidance on address poisoning covers the wallet-side settings.

The variant worth knowing about

A related trick sends you a token whose name is a web address, sometimes showing a large fictional balance. Receiving it is harmless. The attack is that you visit the address in its name, or try to swap it and approve a hostile contract in the process.

Treat any token you did not acquire deliberately as decoration. Hide it, do not price it, do not interact with it, and above all do not follow a URL that arrived inside your wallet — address poisoning and this variant both rely on your own interface presenting hostile data as though it were yours. Save the counterparty once, verified against the original source, and address poisoning stops being something you have to notice at all. The address book habit is worth adopting before you need it rather than after, because after is when the funds are already gone and no recovery exists.

What to do if you have already sent to a poisoned address

There is no recovery mechanism, and anyone who tells you otherwise is running the second scam. What you can still do:

• Record the transaction hash and the receiving address before anything else.
• Report the address to the chain's block explorer, which can label it and warn the next person.
• Watch whether the funds reach a service with identity requirements, in which case a report to that service and to law enforcement has some chance of mattering.
• Fix the habit that allowed it — an address book entry for that counterparty, verified once against the original source.

The last point is the only one that changes anything for you. The first three change things for whoever is targeted next.