How to spot address poisoning before you send crypto

Address poisoning is a lookalike address scam that turns your wallet history into a trap, so you copy a familiar-looking address and send real funds to an attacker. Spotting it comes down to recognizing poisoned history artifacts like a zero value transfer or fake tokens, then forcing a full-address verification workflow before every meaningful send.

Key Takeaways

• Address poisoning works by planting a lookalike address into your wallet or block explorer history so you later copy it and mis-send funds.
• The two most common artifacts are fake tokens that mimic majors (USDC/USDT) and zero value transfer entries that create convincing “sent” records without moving value.
• “First 4 / last 4” checks are not a real control because vanity addresses can be generated to match those visible segments.
• For transfers above your pain threshold, a small test send to the exact same verified address is cheap insurance even if it means paying gas twice.

How address poisoning tricks you

Address poisoning is not a private-key compromise story. The chain is doing what it always does, and the attacker is exploiting a workflow mistake: treating a public transaction feed as if it were a trusted address book. That is why this sits inside the broader bucket of crypto wallet scams and how to avoid them, even though nothing “hacks” the wallet.

The mechanic is simple. An attacker creates a vanity address that visually resembles a legitimate destination you have used before. Then they get that lookalike address to show up in places people copy from, especially the transaction history view in a wallet app or a block explorer tab left open from earlier. When the user later does a repeat payment or an exchange withdrawal and copy-pastes from history, the attacker’s address is sitting there waiting.

Trezor’s support guidance is explicit about the threat model: there is no need to worry about private keys leaking in a basic address poisoning scenario. The loss happens when funds are sent to the wrong recipient because the user copied the wrong line item or verified too little of the wallet address.

The scam scales because attackers can write to your history cheaply. Trezor calls out Ethereum and other EVM networks as common targets, and notes low-fee chains like Polygon, Avalanche, and BNB Chain are attractive because spamming many addresses is inexpensive. That is the mindset shift: your wallet history is an untrusted tape that anyone can try to “print” on.

Common poisoning patterns to recognize

Two patterns show up again and again on EVM chains because they create the exact UI artifact the attacker wants: a plausible-looking entry that can be copied later.

Pattern one is the fake-token route. The attacker deploys a worthless token contract that uses a familiar ticker or name, like USDC or USDT, then sends transfers that resemble real activity. Trezor describes a common tell: after a legitimate transfer (for example, 5,300 USDC), the attacker sends a fake token transfer that displays the same amount so the history looks like a repeat of something the user already did. Revoke.cash frames the same idea as “make it seem like you sent tokens to a certain address when you actually didn’t,” so the recipient line becomes the bait.

Pattern two is the zero value transfer route. This is not a “failed” transaction. It is often a deliberately valid event that exists to poison your UI. Revoke.cash explains why it can succeed without you approving anything meaningful: on EVM tokens using transferFrom logic, the check is amount ≤ allowance, and 0 passes even when allowance is 0. The result is a clean-looking “sent” entry with a recipient address that is close to a real one, but the value is zero.

These patterns can overlap with a dusting attack in the sense that both are cheap spam that lands in your history. The difference is intent. Dusting is often used to track or cluster addresses, while address poisoning is engineered to get you to copy-paste the wrong destination.

Address checks that actually work

A usable defense has to survive the exact moment people get clipped: the copy paste address scam during a routine send. That means the check cannot be “glance at the first and last few characters.” Revoke.cash is blunt that first/last 4 characters are not sufficient because scammers can generate addresses that match those segments. Trezor’s guidance goes further: the only way to be sure is to check every character.

A practical workflow looks like an ops checklist, not a vibe check. The goal is to force a source-of-truth address, then verify it end-to-end before signing.

1. Identify whether the address came from history. If the destination was copied from a transaction list, treat it as suspect by default and restart the flow from a clean source. 2. Pull the destination from the source of truth. For an exchange deposit, that is the exchange’s deposit page opened fresh for this send. For a person, that is a fresh message from the recipient or an ENS name if both sides use it. 3. Compare the full address, not a snippet. Do the comparison in a place that is hard to spoof, ideally the hardware wallet confirmation screen if using one. 4. Scan the recent history for poisoning artifacts before sending. Look specifically for a zero value transfer “sent” entry or a token transfer involving a suspicious lookalike token name around the last time you paid that counterparty. 5. Use a size rule. If the amount is meaningful, send a small test transaction to the exact same verified address, then send the full amount only after the test arrives.

This is also where “how to verify a transaction before signing” matters. The verification step is not just the recipient. It is the network, the asset, and the final confirmation screen that shows where funds actually go.

Safer ways to reuse addresses

Most losses happen on the boring transfers, not the exotic ones. The user is moving stablecoins to an exchange, paying the same counterparty again, or sweeping funds between wallets. The fix is to stop treating transaction history as a contacts list.

For exchange deposits and withdrawals, the safest habit is repetitive and slightly annoying: open the exchange deposit page each time and copy the address from there, instead of reusing an old one from your wallet history. Revoke.cash explicitly recommends this “never use your wallet history or block explorer as a source of truth” posture for deposits.

For repeat payments to the same person, the cleanest workflow is to store the address somewhere that is not writable by random third parties. Some wallets support address books or whitelists, and some exchanges support withdrawal address allowlists. The key is that the record is created by you, not by whatever shows up on-chain.

For self-transfers between your own wallets, the same rule applies. Trezor specifically warns against copying even your own address from transaction history when moving funds from a centralized exchange to a Trezor device. Use the receive screen for the destination wallet and verify it on the device.

This is also where UI flags matter. Trezor Suite includes a filtering mechanism that blurs suspected poisoning transactions in history and marks them as unverified. Those labels should be treated as a hard stop, not a suggestion, because the entire point of the scam is to get you to trust what the UI shows.

Damage control and prevention habits

A poisoned history entry is not a reason to panic about key theft. Trezor’s guidance is clear that address poisoning does not require private key leakage. The immediate job is to prevent a workflow slip on the next send.

1. Stop using history as an address source. If a suspicious entry appears, assume the attacker is trying to seed your next copy-paste. 2. Ignore flagged or unexplained transfers. Trezor recommends disregarding transactions flagged as suspicious by Trezor Suite and ignoring transactions you cannot explain. 3. Rebuild your “known good” destinations. For exchanges, re-copy deposit addresses from the exchange UI. For people, re-confirm the address out of band. 4. Apply two-step execution for size. Trezor recommends a small test transaction before a large amount, with the explicit trade-off that you may pay gas twice. 5. Treat low-fee chains as higher-noise environments. Trezor notes Polygon, Avalanche, and BNB Chain are often targeted because it is cheap to spam many addresses at scale.

The trader-angle reality is that this is high-frequency spam, not an edge case. Ledger cites over 270 million zero-value transfer attempts across Ethereum and BNB Chain and $83 million in confirmed losses. The methodology behind those aggregates is not provided in the supplied excerpt, but the directional point holds: the attack is cheap to run and only needs a small fraction of victims to mis-send.

Near the end of any wallet-security checklist, the same umbrella topic comes back: crypto wallet scams and how to avoid them. Address poisoning is the version that punishes sloppy execution, so the prevention habit is to make “verify full address, then test send for size” as automatic as checking size and venue before a trade.

Sources

• Trezor
• Revoke.cash
• Ledger