Address poisoning

The theft is the later send

Address poisoning puts a lookalike into the history you copy from. Someone sends a tiny amount, or a zero-value transfer, from an address that matches the first and last characters of one you use. Your wallet now shows two similar rows. The next time you copy from history instead of from the recipient, you can paste the attacker's address and send a real balance there. The dust is not the theft. The theft is that later send. Nothing on this site needs you to touch the dust.

The lookalike is possible because people compare the ends. Generating an address that matches a few characters at each end is a search over keys, and attackers automate it. This page does not describe how to run that search, which tools to use, or how many characters are 'enough' to fool a particular wallet. The defense does not require those details. Compare the whole string, or do not copy from history.

What the row looks like

On an Ethereum-style account the transfer can be a normal token transfer of a worthless amount, or a zero-value call that still appears in an activity list. The attacker's address often shares the opening 0x and four or more hex characters, and the same number at the end. The middle is different. A shortened display, the kind that shows 0x12ab…89ef, hides the only part that would save you. If your wallet shortens addresses in the history list, that list is the wrong place to copy from.

Solana addresses are a different alphabet and the same habit. People glance at the start and the end of a base58 string. A dust transfer of a junk mint, or a tiny amount of SOL, can sit next to a real counterparty. The mint in the dust row may also carry a name that looks like a claim. That second hook is the fake-airdrop page. Poisoning only needs you to reuse the address. It does not need you to sign anything to receive the dust. Receiving is passive. Sending is the mistake.

Copy from the original, at the moment you send

When you pay a person or an exchange, go back to the place that first gave you the address: the invoice, the exchange deposit screen you just opened, the receive screen on the device. Copy it then. Paste it. Compare it to the source, character by character, or in blocks of four if the string is long, including the middle. Do this even when you have paid the same party before. The previous payment is exactly the row an attacker will imitate.

An address book inside a wallet you trust is safer than scrolling recent activity, once you have checked the entry at the time you saved it. A book that was filled by tapping a history row inherits the poison. Save from the original source. Name the entry in your own words. A hardware wallet helps because the full address can be shown on the device screen, which the poisoned history on the computer cannot rewrite. You still have to look at that screen. A device you click through is not a check.

Networks and the wrong kind of match

An Ethereum-style address is a valid string on Ethereum, Base, Arbitrum, Polygon, and BNB Chain. Matching the characters does not tell you which ledger the exchange is about to use. Poisoning and a wrong network are different failures with the same feeling: the funds are not where you expected. Read the network on the withdrawal screen and on the receive screen. If you cannot name it, do not send the full amount.

A contract address and a wallet address are also different jobs. The token checker wants the token's contract so it can ask GoPlus and the other sources. A payment wants the recipient. Pasting a token contract into a withdraw field, or pasting a recipient into the checker and treating a confused error as a safety result, mixes the two. The checker does not bless a recipient. It has nothing to say about whether your friend's address was poisoned. That comparison is yours.

Do not clean the dust

Hiding the row in the wallet, if the wallet allows it, is enough. Selling the dust, approving it, or visiting the site in its name is how a second scam starts. A page that offers to 'clean' poisoned history by connecting a wallet is asking for a signature. The signature is the drainer. The dust was only the advertisement. Decline it. Do not reply to the sender. There is no refund desk for a dust transfer, and the sender is not waiting to explain.

If a token you do not recognise arrived, leave it. You do not have to interact with an asset for it to sit in the account. A real payment from a person you know will be an amount and an asset you were told about, on the address you gave them, and they can tell you the transaction id by a channel you already use. A surprise is not that.

If a real amount already went to the lookalike

If the transaction has confirmed, the coins are in the attacker's wallet. There is no chargeback on the chain. The exchange you withdrew from cannot pull them back. A stranger who offers to recover them for a fee is a second theft. Report it to the exchange if the withdrawal left their account, so they have a record, and do not expect the record to reverse the chain. Preserve the transaction id. It is the evidence. It is not a lever.

If the transaction is still pending, use the wallet's own pending screen, from a bookmark, and only the controls that wallet already shows you. Do not install a 'canceller' from a search ad made of the word pending. Do not type a seed phrase into a site that says it can bump the fee. If you do not understand the pending screen, leaving it alone is safer than handing the keys to a helper. After any send you did not intend, assume the history list is hostile and stop copying from it.

A comparison, using made-up strings

Suppose the address you meant to pay is 0x91c4e0aa11bb22cc33dd44ee55ff6677889900ab. A history row from an hour ago shows 0x91c4f00399aa88ee77bb66cc55dd44ff001100ab. The first four hex characters after 0x match. The last four match. A shortened wallet that prints 0x91c4…00ab will show you the same caption for both. The middle, f00399aa versus e0aa11bb, is the entire difference, and it is the attacker's address if you copied the history row. These strings are an illustration. They are not a live poisoned pair, and they are not a recipe for producing one.

Read in blocks. 91c4 matches. Then stop treating the ends as sufficient and keep going. When a block differs, you are not paying the party you think you are paying. Cancel the form and copy again from the invoice or the deposit screen, not from the row you just rejected. Doing it once takes a minute. Doing it from muscle memory, on a large withdrawal, is the point of the trick.

Exchanges sometimes let you save a withdrawal address after a waiting period. Use that for the addresses you pay often, and still compare the full string the first time you save it. The book is only as good as the check you did when you created the entry. A saved lookalike is a faster mistake, not a safer one.

The same exercise works on a Solana string. You do not need a tool that highlights differences, though a wallet that shows the full address on a device screen is doing that job for you if you look. A tool that offers to 'scan your history for poison' and asks you to connect is a different product. It can be honest. It can also be the signature. This site does not operate one, and it does not tell you to connect to one from a link in the dust token.

Questions

Is the dust dangerous by itself? Not as a balance. It is dangerous as a row you might copy, and as bait toward a site. Ignore it. Do not pay a cleaner.

How many characters should I compare? All of them. A rule like 'first four and last four' is the rule the attacker is counting on. The middle is the part they did not match.

Does a hardware wallet stop this? It shows the address it will pay, if you read the device. It does not choose the address. If you copied the lookalike into the send form, the device will faithfully show you the lookalike. That is still your chance to reject it. It is not an automatic filter.

Should I check the attacker's address in the token checker? Only if you pasted a token contract by mistake. A wallet address is not a token report. The useful check is the string comparison before you confirm.