By CrowdSent Blog Team
Address poisoning is a deception that makes an unfamiliar address look like a familiar recipient in transaction history. The risk arises when someone later treats that history entry as a trusted source for a destination.
An unexpected zero-value or tiny-value entry, by itself, does not establish that private keys were stolen. It does deserve careful interpretation. The useful question is what the entry actually shows and whether there is independent evidence connecting an address to the intended recipient.
Understand what a familiar history entry can hide
MetaMask’s address poisoning guidance describes look-alike addresses appearing through negligible or zero-token transfers. A shortened display can conceal differences in the middle of an address. The resulting familiarity can make the wrong entry seem suitable for copying.
The important distinction is between a recorded event and a verified recipient. A history display can help you locate something to investigate. It cannot, simply by containing a name or familiar characters, establish who controls the destination or whether it is the destination you intended.
This is an evidence problem as well as a visual one. Reading more characters helps detect a mismatch. It still requires a trustworthy reference against which those characters can be checked.
Address poisoning: inspect a fictional history
Every identifier below is deliberately invalid and non-payable. They contain teaching words and separators, and must never be entered into a wallet. No real account, address or victim is represented.
- Earlier reference note: the fictional recipient was recorded as DEMO-AB12-RIVER-77-ZZ89 after a separate identity check. This note is the example’s reference; a transaction-history row alone would not give it that status.
- Later unexpected entry: the display shows a zero amount alongside DEMO-AB12-STONE-42-ZZ89. Its relationship to the intended recipient is unverified.
- Shortened view: both identifiers could be rendered as DEMO-AB12…ZZ89. That view removes the exact section where they differ.
- Full comparison: RIVER-77 differs from STONE-42. The second identifier fails the match with the reference even though the visible beginning and ending agree.
The defensible observation is narrow: two different full identifiers can produce the same abbreviated display. The amount and visual resemblance do not explain who created the later entry, why it exists or who controls it.
Suppose a researcher instead writes, “My usual recipient sent this because the ends match.” That sentence adds identity and intent without evidence. A better note says, “Unexpected zero-value entry; middle characters differ from the independently checked reference; recipient identity unresolved.”
Now consider a second mistake: copying the later identifier into a saved contact and giving it the usual recipient’s name. The friendly label would preserve the original mistake. Naming an item does not verify the information underneath it.
Address poisoning: verify the full recipient address
Trezor’s address poisoning guidance also emphasizes avoiding history as the source of a copied destination and checking the full address. The following checklist turns those principles into a read-only review.
- State the intended recipient. Write down who or which account the destination is supposed to represent. “The familiar row” is not an identity.
- Obtain a separate reference. Use a previously verified recipient channel or the appropriate authenticated account interface reached independently. Do not use a link supplied by the unexpected entry.
- Check the complete identifier. Compare every part with that reference. A prefix, suffix, nickname or abbreviated preview is insufficient.
- Record the intended network context. Ask the recipient to clarify an unresolved network or account mismatch through the verified channel.
- Stop at any discrepancy or warning. Keep the mismatch visible in your notes rather than trying to explain it away with familiarity.
- Separate observation from conclusion. Save what differs and what still needs confirmation. Do not label an unknown entry “trusted” merely because it has appeared more than once.
This checklist does not require a deposit, test transfer, token interaction or signature. Its output is either a documented match to a separately verified reference or an unresolved question. A match to a reference is only as reliable as the reference itself.
Keep an unexpected entry from becoming a second scam
A confusing history entry can lead to a search for help. Be cautious about unsolicited messages offering to clean, validate or recover a wallet. Do not follow token-name links or submit recovery material to a page presented as a remedy.
The Ethereum security guide warns against sharing recovery phrases or private keys and explains how fake support offers exploit misunderstandings. A person who claims they need those secrets to investigate a public history entry has not provided a safe support process.
Keep any incident record minimal: the network, public transaction identifier, relevant time and a description of the unexplained event. Redact unrelated balances and personal details from screenshots. Reach your wallet provider through its independently verified official channel; public posts can attract additional impersonators.
If there is an outgoing transaction you do not recognize, treat that as a separate unresolved incident. The limited reassurance about receiving a spam entry does not settle evidence of possible unauthorized activity.
Read warnings without treating them as verdicts
A warning is a reason to pause and check the destination. Avoid treating it as an obstacle to dismiss. Equally, the absence of a warning does not establish that a recipient has been verified. Protection behavior can depend on the wallet and version.
Keep your conclusion proportionate: “This differs from my reference” is stronger than guessing a motive, and “I have not established a mismatch” is weaker than proving safety. This distinction is useful whenever an interface makes incomplete information feel familiar.
For broader context, see CrowdSent’s introduction to Ethereum and account activity. Its guide to verifying evidence before acting applies the same habit of checking a claim against its original source.
Frequently asked questions
Does receiving a zero-value entry prove my keys were compromised?
No. The entry alone does not establish that. Other evidence, such as an unexplained outgoing transaction or a known disclosure of secrets, needs separate investigation.
Does a familiar token ticker prove the history entry is genuine?
No. Trezor’s guidance describes imitation tokens in these scenarios. A familiar label or displayed amount cannot substitute for checking the underlying evidence and recipient.
How many matching beginning and ending characters are enough?
There is no shortcut in this workflow. The fictional example shows the failure of abbreviated comparison. Use the full identifier and an independently verified reference.
Can I trust a destination because I found it in older history?
Age alone does not verify identity. Ask how that particular destination was originally confirmed. An old, unresolved assumption remains unresolved when copied again.
Is a saved contact automatically safe to reuse?
A saved label can contain an earlier copying mistake. Establish how the address was verified and resolve any change communicated through a trusted recipient channel.
Does a wallet warning prove the address is malicious?
A warning calls for verification; it is not enough to identify someone’s intent. Keep the action paused while checking the discrepancy rather than overriding the warning.
Does the absence of a warning prove the address is safe?
No. Detection coverage is not recipient confirmation. Continue the full-reference check even when the interface presents no alert.
Will hiding the suspicious entry verify my contacts?
No. Reducing visual clutter and checking contact identity are different tasks. A hidden entry does not correct an address previously copied into another record.
Can hardware signing establish who controls a recipient?
Reviewing a device’s destination display is an additional checkpoint. It still needs a verified recipient reference; the display alone cannot supply the missing identity evidence.
What if I already used the wrong destination?
Preserve the public transaction details and seek guidance through the relevant provider’s official support channel. Do not share secrets or rely on recovery guarantees from strangers.
Source documentation checked 12 October 2026. Educational explanation from the CrowdSent Blog Team. Numerical examples and identifiers are fictional unless stated otherwise. This article does not provide investment recommendations.