Skip to content
Financial Context Wiki

Address poisoning

Address poisoning plants a lookalike recipient in transaction history or another trusted-looking interface so that a later payment is copied to the attacker; it exploits recipient verification rather than changing the real address or stealing its key.

Updated

For educational purposes only; not investment advice. A transfer signed to the wrong address may be irreversible, and freezing or recovery is never guaranteed.

Direct answer

Address poisoning is recipient-substitution fraud. An attacker generates a different address whose visible prefix and suffix resemble a trusted recipient, then places it in transaction history or another trusted-looking interface. The attacker hopes a later sender copies that lookalike and signs a valid payment to it. The attack does not alter the legitimate address, break its private key or make consensus misroute the transfer.

The planted record can arise from a real native-asset transaction, a standards-compliant zero-value token transfer, or a log emitted by another token contract. Wallet and explorer activity pages are derived views: a row labelled “sent” may come from event fields rather than an outer transaction signed by the displayed from address. Verify the outer transaction sender and destination, called contract, event-emitting contract, indexed fields and actual balance changes separately.

An ERC-55 checksum helps detect some accidental typing errors, but a different attacker address can itself be syntactically valid and correctly checksummed. Ordinary 20-byte EVM addresses also do not identify the intended chain, asset, recipient role, deposit memo or contract call. A safe payment instruction binds all of those facts to the full destination.

Address poisoning
0 / 5
0 items reviewed; 5 items still unresolved

Completing this review does not prove an asset, transaction, or system is safe.

How it works

The attacker observes a public payment pattern and searches for a vanity address matching characters that the wallet truncates into view. Matching selected hex characters does not clone an account; the unseen bytes remain different and the attacker controls the new key. A tiny transfer can put that real address into history. Separately, ERC-20 requires zero-value transfers to be treated as normal transfers and emit Transfer, so a zero-value record is not by itself proof of forgery, compromise, authorization or economic loss.

A malicious token contract can also emit its own Transfer(victim, lookalike, 0) log. That log is real receipt data attributable to the emitting contract, but it is not an event from the canonical asset contract and does not prove that the victim signed the outer transaction. An indexer that classifies activity from event topics without enough contract and call context can nevertheless present a misleading outbound row.

The decisive control is the final payment intent. It should bind chain and network, native asset or exact token contract, full recipient address, recipient type, amount and raw units, and any calldata, memo, destination tag or validity period. Exchange deposit addresses, bridges, proxies and one-time routes can become stale or require more than an address. Clipboard malware and compromised QR codes are distinct attacks, but the same full-destination verification catches the substitution before signing.

Names and test payments are supporting controls, not identity proofs. Resolve an ENS name for the intended chain and record at signing time; if a reverse name is displayed, forward-resolve it back to the same address. A small test helps only when the recipient independently confirms it and the main payment reuses the same pinned destination. Copying again from history discards that protection.

Use this workflow:

  1. Pin the chain, network, asset and exact token contract, recipient type, address format, amount and any memo, tag, calldata, version or expiry from an authenticated independent source.
  2. Resolve a name or QR once, validate its format and checksum, and bind the full destination bytes to the intended chain; forward-confirm any reverse name rather than treating a label as identity.
  3. Compare the destination with a controlled allowlist, address book or signed invoice, never transaction history; require independent or dual approval for a new or materially changed recipient.
  4. Decode the exact unsigned transaction: distinguish native to from a token or bridge contract, and inspect the calldata recipient, token, raw amount, approval, deadline and destination semantics.
  5. When appropriate, send a small test to that pinned destination and obtain independent recipient confirmation; do not copy an address from history again for the main payment.
  6. Sign the main transfer only from the verified record, compare the full destination and amount on a trusted display, then verify receipt, emitting contract, logs and balance deltas on the correct chain.
  7. If poisoning or a mis-send is suspected, stop later payments, preserve hashes and evidence, and promptly contact the recipient service, issuer or law enforcement where relevant; treat freezing, return and recovery as conditional, never assured.

Examples

  • Truncation hides the difference. Legitimate 0x12ab1111111111111111111111111111111189ef and attacker 0x12ab9999999999999999999999999999999989ef both render as 0x12ab...89ef. They share 4 + 4 = 8 displayed hex characters but differ in all 32 middle characters. Comparing only the rendered ends produces a false match; full-byte comparison does not.
  • Vanity-search work factor. Matching k = 8 chosen hex characters has expected work 16^8 = 4,294,967,296 candidates. At an assumed 50,000,000 candidates/s, expected time is 4,294,967,296 / 50,000,000 = 85.89934592 s. This illustrates a search space, not a promised runtime or wallet-warning threshold.
  • Log versus state. A token contract emits Transfer(victim, lookalike, 0). The victim’s balance moves from 250,000.000000 to 250,000.000000, so delta is 0.000000; an activity index may still render a transfer row. Check the emitting contract and call authorization: the row alone proves neither value movement nor a victim signature.
  • A test must pin the destination. A treasury plans 50,000 USDC, sends 1 USDC to a verified address, receives independent confirmation, and sends 49,999 USDC from the same pinned record: 1 + 49,999 = 50,000 USDC. If staff recopies a lookalike from history for the second leg, the test no longer protects the 49,999 USDC payment.

Risks

  • A sender copies a lookalike from poisoned transaction history.
  • A truncated interface hides the differing middle characters.
  • A vanity prefix or suffix is mistaken for recipient identity.
  • A zero-value ERC-20 transfer creates a misleading history row.
  • A counterfeit token or its log is mistaken for canonical asset activity.
  • An indexer misclassifies event fields or corrects them too late.
  • A spam token name, symbol or icon impersonates a trusted asset.
  • Clipboard malware replaces a verified address before signing.
  • A local or synchronized address book is poisoned or stale.
  • An allowlist binds the wrong chain, asset, role or address version.
  • An invalid or missing checksum warning is ignored.
  • A valid checksum is mistaken for proof of recipient identity.
  • ENS resolution changes, uses the wrong coin type or is stale.
  • A reverse name is displayed without forward confirmation.
  • A test payment is followed by a fresh copy from an untrusted source.
  • An exchange deposit address, network, memo or tag is wrong or expired.
  • A bridge, proxy or contract destination and required calldata are misunderstood.
  • A signer checks only truncated text, even on a hardware device.
  • A wrong-recipient transfer becomes canonical before intervention.
  • The victim relies on discretionary issuer freezing or a recovery scam.

Common misconceptions

  • Address poisoning means the wallet, key or blockchain was hacked. The usual attack exploits recipient selection while valid cryptography and consensus execute the wrong signed intent.
  • A zero-value row must be a fake on-chain transaction. Standards-compliant transfers and real logs can carry zero value; inspect their source and state effect.
  • Matching ends plus a checksum proves the recipient. A different valid address can match visible characters and have its own valid checksum.
  • One successful test automatically protects the next transfer. Protection is lost if the main transfer does not reuse the pinned, confirmed destination.
  • A wallet, validator or token issuer can always reverse the payment. Recovery powers and cooperation are asset-, service-, jurisdiction-, evidence- and timing-specific.

Sources

Navigation

Search the wiki...