Address Poisoning | Wallets, Custody & Security

Address poisoning is a social-engineering attack against wallet operations. Attackers try to insert a lookalike address into your transaction history so that you later copy the wrong destination without noticing.

Risk first: Blockchain transactions can be irreversible. A correct-looking wallet address is not enough: the network, token contract, destination requirements, permissions and transaction details all matter.

Standalone building blockEducational onlyLast reviewed: 20 August 2026

1. How the attack works
2. Why lookalike addresses are convincing
3. Transaction history is not an address book
4. Defensive operating practices
5. What a test transaction can and cannot do
6. Worked example

1. How the attack works

Blockchain addresses are long and users often compare only the first and last few characters. Attackers can exploit this by creating an address that visually resembles a real counterparty address and then causing it to appear in the victim’s history.

Observe
Attacker sees a public transaction

→

Mimic
Creates a lookalike address

→

Poison
Sends dust/zero-value activity

→

Exploit
Victim copies history entry later

The blockchain is not confused. The attacker is trying to confuse the human reading the history.

2. Why lookalike addresses are convincing

Wallet interfaces often truncate addresses, for example showing only a short prefix and suffix. Attackers can search for an address whose visible characters resemble a known destination.

Trusted: 0x12A4...9F7C
Poison: 0x12A4...9F7C

The truncated display may look identical even though the hidden middle characters differ. This is why checking only the first and last four characters is not a complete verification method for high-value transfers.

3. Transaction history is not an address book

Core rule: do not treat recent transaction history as an authoritative source of destination addresses.

History is a record of on-chain activity, and anyone may be able to send transactions or token events to your public address. An unfamiliar entry can therefore appear without your permission.

Stronger source

Fresh deposit page, verified counterparty communication, whitelisted address or hardware-wallet address book.

Weaker source

Recent transaction history, clipboard memory, truncated explorer display or a search result.

4. Defensive operating practices

Retrieve destination addresses from a trusted source each time, or use verified whitelists.

Compare more than just a few leading and trailing characters for material transfers.

Use wallet labels/address books where available.

Perform a test transaction for new or high-value destinations when practical.

Verify the destination on a hardware-wallet screen when using one.

Be suspicious of unsolicited dust, zero-value transfers or unfamiliar tokens in history.

Best control: change the source of truth. If you never copy destinations from transaction history, the attacker’s poisoned history entry becomes much less useful.

5. What a test transaction can and cannot do

A test transaction can confirm that a particular address received funds. But if the user later copies a poisoned lookalike address from history for the main transfer, the test does not help.

For this reason, the main transfer should be re-verified against the trusted source rather than taken from the test transaction entry itself.

Control	Effective against poisoning?	Condition
Test transaction	Partly	Only if the main transfer uses the same independently verified destination.
Address whitelist	Strong	Whitelist was created from a verified address.
Checking four characters	Weak	Attackers can target visible prefixes/suffixes.
Fresh trusted source	Strong	Source itself is authentic and uncompromised.

6. Worked example

A company treasury regularly sends stablecoins to the same exchange deposit address. An attacker observes one transfer, generates a lookalike address and sends a tiny token event so the fake address appears near the top of the treasury wallet’s history.

Weeks later, an operator searches recent history, sees what appears to be the familiar prefix and suffix, and copies the poisoned address. The transfer is valid on-chain but goes to the attacker.

The procedural fix is to use the exchange’s current deposit page or an independently verified whitelist as the destination source—not prior transaction history.

Knowledge checkpoint

What is the main failure mode this lesson is trying to prevent?
Which detail should be verified independently rather than inferred from a familiar-looking interface?
What small, reversible-looking action can still create a large future risk?
What would make you stop and verify before signing or sending?

Practical standard: treat wallet transactions as operational procedures, not just button clicks. Build a repeatable verification routine and use it even when the amount feels small.

FAQs

❓ Can an attacker change my past transaction history?

They cannot rewrite confirmed history, but they can create new activity involving your public address so misleading entries appear in wallet or explorer history.

❓ Is a zero-value transaction harmless?

It may have no direct economic transfer, but it can be used as a visual lure in an address-poisoning campaign.

❓ Will antivirus software stop address poisoning?

Not reliably. The attack often uses valid blockchain transactions and normal wallet interfaces. Operational verification is the primary control.

❓ Are whitelisted addresses completely safe?

They reduce copying risk if the whitelist was created from a verified destination and the account controlling the whitelist is secure. They are not a substitute for broader account security.

📋 Summary

Address poisoning targets human verification, not blockchain consensus.
Attackers exploit truncated displays and the habit of copying from transaction history.
Use a trusted destination source or verified whitelist rather than history.
For material transfers, compare more of the address and re-verify even after a successful test.

The objective is not to eliminate every risk. It is to reduce preventable losses by making transaction verification deliberate, repeatable and proportionate to the value at risk.