Address poisoning: why transaction history is not an address book

The idea in plain English

Address poisoning places misleading entries in a visible transaction history so that a user copies a lookalike destination later. Attackers may exploit the way interfaces shorten addresses to a few leading and trailing characters. Receiving an unexpected tiny transfer does not make the sender your intended recipient.

The distinction that matters

Use receiving details from a trusted, independently checked source. Compare the full destination and the network, ideally on the trusted signing display where applicable. Store verified recipients deliberately instead of promoting any recent address into an address book. Recheck details even after a previous successful transfer.

A practical example

Your history contains a small incoming transaction whose shortened sender resembles a supplier’s wallet. Copying that sender for the next payment would send to the attacker. The history entry proves only that a transaction happened, not that the address belongs to the supplier.

Try this without moving money

• Compare two invented long identifiers character by character.
• Explain why a recent transfer is not proof of recipient identity.
• Use the intended recipient’s verified instructions and confirm changed details through a separate channel.

A mistake to avoid

Do not rely only on the first and last characters, a familiar label or a past test. Clipboard changes and poisoned entries can affect later transfers.

Before you act

A checklist lowers some risks but cannot certify a person, link or wallet as safe. When uncertain, stop signing and return through a destination you independently verified. Keep evidence without sharing secrets. If money or credentials are already exposed, use the incident-response guidance and official support rather than a stranger offering a guaranteed recovery.