What Is Address Poisoning?

In brief

The attack combines three things:

1. public transaction activity that reveals addresses a target uses;
2. an attacker-controlled address chosen for visual similarity;
3. a wallet, explorer, or human workflow that treats recent history as an address book.

The attacker then creates activity that puts the look-alike near a legitimate counterparty. On Ethereum and similar account-based systems, this may be a small native-asset transfer, a zero-value transfer involving a real token, or an event from a spoofed token contract. The user later copies the attacker’s address from history and signs a real transfer to it.

Address poisoning is primarily a transaction-history, interface, and social-engineering attack. It is distinct from seed theft, clipboard malware, malicious approvals, and wallet drainers, although a campaign can combine techniques.

Why shortened addresses are vulnerable

An Ethereum address contains 20 bytes, normally shown as 40 hexadecimal characters after 0x. Interfaces often abbreviate it to something like 0x12ab…90ef. Attackers can search for a key whose address shares selected visible characters with a known destination. Matching an entire 160-bit address is not the goal; matching the small prefix and suffix a person glances at may be enough.

Mixed-case ERC-55 checksum encoding helps software detect many mistyped Ethereum addresses. It does not prove that a correctly checksummed address belongs to the intended recipient. An attacker can generate a different valid address with its own valid checksum. Name systems and contact labels can reduce repeated raw-address copying, but look-alike names, compromised records, and bad initial enrollment remain possible.

Academic work on clipboard substitution found that visual similarity can cause users to approve modified destinations even when a hardware device displays the address. Address poisoning uses a different insertion path—history rather than necessarily the clipboard—but exploits the same weak human comparison of long strings.

How poisoned activity appears

A common sequence is:

1. A user previously sends to a legitimate address.
2. An attacker observes the public transaction and creates a visually similar address they control.
3. The attacker causes a small, zero-value, or spoofed-token entry involving the target to appear in indexed activity.
4. A wallet or explorer displays both real and attacker-controlled addresses, often in shortened form.
5. On a later payment, the user copies the look-alike from history and signs a valid transaction to the attacker.

There are important technical variants. ERC-20 requires compliant implementations to treat zero-value transfers as normal transfers and emit a Transfer event. That behavior enables cheap history clutter with real tokens in some flows. Separately, a malicious token contract can emit event fields that resemble another activity pattern; a log’s from field is data produced by that contract, not proof that the claimed address signed the transaction. Explorers and wallets decide how to index, label, hide, or warn about these records.

Etherscan documents dust transfers, zero-value token transfers, and spoofed-token events as poisoning surfaces. It also notes that not every dust transfer is malicious. An unexpected tiny transfer is a reason not to trust the entry—not proof of attribution.

What the attack does not prove

Poisoned history by itself does not show that:

• the private key or seed phrase was exposed;
• a token allowance was granted;
• the wallet software was compromised;
• a hardware wallet failed;
• the legitimate recipient was hacked;
• an explorer changed blockchain data;
• every small or zero-value transfer came from an attacker.

The signature on the eventual mistaken payment can be fully valid. A hardware wallet may correctly sign it because the displayed attacker address is the exact destination in the transaction. Key isolation cannot infer the address the user meant to choose.

Defensive workflow

The strongest practical change is to stop treating transaction history as a source of recipient identity.

• Retrieve the destination from a verified source. Use a previously enrolled address book or allowlist, an authenticated account page, or direct confirmation with the recipient over an independent channel.
• Protect enrollment. Confirm a new saved address through a second channel and review it before adding it. An address book preserves mistakes as efficiently as it preserves correct entries.
• Verify on the signing device. Check the network and full destination where practical. Do not rely only on the same abbreviated prefix and suffix that the attacker targeted.
• Use multiple representations when available. Wallet labels, checksum validation, address highlighting, and recognizable-name systems add evidence, but none independently establishes ownership.
• Treat unexplained history as untrusted input. Do not reply to, return funds to, or copy a destination from an unsolicited dust, zero-value, NFT, or token entry.
• Use wallet and explorer warnings. Filtering and similarity alerts reduce exposure, but newly generated addresses and false negatives remain possible.
• For organizations, enforce policy. Recipient allowlists, change control, dual review, amount limits, and delayed approval for new destinations reduce reliance on one operator’s visual check.

Test transfers: useful only with confirmation

A small test transfer can limit the amount lost to an incorrect destination, but it is not a stand-alone defense. The recipient must independently confirm receiving it at the expected address before the main transfer. Checking only that a transaction appears “successful” proves the chosen address accepted value, not that the intended person controlled it.

Security-team reporting now documents attackers that watch for tests and quickly inject a new look-alike entry before the larger follow-up. Re-copying from history after a successful test can therefore undo the benefit. Keep using the already verified destination, and confirm receipt through a separate communication path.

Even then, a test is risk reduction, not a guarantee. Deposit addresses can expire or require tags and memos; token contracts and networks can differ; malware can substitute a destination after the test; and the independent communication channel can itself be compromised.

Cross-chain scope

Address poisoning is widely documented on Ethereum and other account-based networks because public account histories and token event logs create convenient injection surfaces. Similar visual-deception risk exists anywhere users copy long identifiers from prior activity, including Bitcoin and Solana, but the mechanics and wallet presentation differ.

Bitcoin’s UTXO model does not provide the same simple “from account” history semantics as Ethereum. Solana programs and token accounts create their own indexing patterns. Avoid assuming that an Ethereum zero-transfer explanation applies unchanged to every chain; the shared risk is trusting attacker-influenced history and abbreviated identifiers.