Address Poisoning Scams: When Wallet History Misleads

The attack is a copy-paste trap

Address poisoning is a social attack on a technical convention. Wallets shorten addresses because 42 hexadecimal characters do not fit on a phone screen. Users learn to check the first few and last few characters. The attacker builds an address that satisfies that check.

MetaMask’s description is specific: the scammer generates a “vanity” address resembling one the victim has used, “matching the first four and last four characters”, then sends a “tiny ‘dust’ transaction from that lookalike address, planting it in your activity history”. Later, when the victim copies what looks familiar, the middle differs and the funds go to the scammer.

The example MetaMask publishes makes the point:

• Real: 0xEdf89FdA047F28…C6341a8ff7ED
• Poison: 0xEdf89Ac910Bb52…99x2b8ff7ED

At a glance the two are indistinguishable in the shortened form. Expanded, they share a prefix and a suffix and nothing else that matters.

Why the history entry is persuasive

A wallet’s transaction history is treated as a record of things that happened to you. Poisoning borrows that trust.

The attacker’s dust transfer costs almost nothing, and on some chains it can be a zero-value token transfer that still creates a visible row. The row shows the lookalike address, often with the same token symbol or a fake token designed to look official. Some interfaces label the row as a transfer you received; others include the address in an autocomplete or “recent” list.

None of that means the address is yours or the token is real. It means the attacker paid a small fee to place a line in your interface. The line is data, not a relationship.

Who is exposed

Anyone who sends to an address more than once and checks only the shortened form. The risk is higher for:

• Treasury and operations wallets that make recurring payments to the same counterparty.
• Users who copy from history because it is faster than opening an address book.
• Wallets that show only the first and last four characters at the confirmation step.
• Users who approve a transfer without reading the full destination on a hardware wallet screen.

It is not limited to large balances. A single mistaken transfer can empty a wallet regardless of size.

The defences that actually work

Address poisoning is defeated by procedure, not by antivirus software.

1. Compare the full address at signing time. On a hardware wallet, the device screen is the authoritative display; confirm every character group, not just the ends.
2. Do not copy from transaction history. Open the address book or the counterparty’s verified channel and copy from there.
3. Use a saved address book. A saved entry with a label is a reference you can check against, and it removes the “copy the last one” habit.
4. Verify the first transaction with a small amount. For a new counterparty, send a test amount and confirm receipt before sending the balance.
5. Treat unsolicited tokens as noise. A token you did not buy is not a gift; interacting with its contract can be the attack.
6. Read the wallet’s warning. MetaMask’s detection compares a pasted address against prior interactions and warns when the ends match but the middle differs. A warning is a reason to stop, not a prompt to tap through.

Ethereum.org’s general guidance points the same way: a transaction sent on Ethereum is irreversible, so confirm that the address “exactly matches the desired recipient’s address” before sending, and read the transaction message before signing a contract interaction.

What detection can and cannot do

MetaMask’s feature is a useful layer because it targets the exact moment of paste. It compares the pasted string with addresses the wallet has seen, and shows a blocking warning when the pattern matches a known address at the ends but not in the middle. It also warns on a first-time send to an unfamiliar address.

The limits are inherent:

• It only sees what the wallet knows. An address you have never interacted with has no baseline to compare against.
• It warns; it does not rewrite the destination. The user still decides.
• It does not cover every wallet or every chain. A user with several wallets has several different histories.

The vendor-reported scale is a reminder that the attack is industrial, not opportunistic. MetaMask’s article states that Blockaid flagged 65.4 million address-poisoning transactions between January 2025 and February 2026. That is a count of flagged events by one security vendor, not a count of losses, and it should be read as evidence of volume rather than as a loss estimate.

If a transfer has already gone wrong

The first step is to check the transaction hash and the destination. If the funds went to a lookalike address controlled by an attacker, the transfer is final. There is no protocol-level reversal and no central support line that can claw it back.

What can still be done:

• Report the address to the wallet provider, the block explorer and, if the destination is a deposit address at an exchange, to that exchange’s support. An exchange can freeze an internal account if the deposit lands there, but it cannot reverse a self-custody transfer.
• Revoke any approvals connected to the incident, in case the same session also granted a token allowance.
• Move remaining funds to a fresh wallet if the affected wallet’s address or history is being actively targeted.
• Preserve the evidence: transaction hashes, timestamps, addresses and screenshots. Reports to law enforcement are more useful with the full trail.

The uncomfortable part is that the loss usually happens at the moment of a routine action, not at the moment of a dramatic hack. The defence is equally routine: read the whole address, every time, and never let a history row decide where money goes.