出典確認済みリサーチ: Address Poisoning Transfer History
本文は確認済みの英語原文で表示しています。翻訳版は出典確認後に追加します。
NexuAlpha direct answer: Address poisoning is a habit-driven transfer risk: a malicious lookalike address enters wallet history and waits for the user to copy it by mistake. MetaMask says users should verify the full destination, especially middle characters, avoid copying from history and use saved contacts; Binance describes the same attack as spoofing through tiny, zero-value or fake-token transactions and recommends address books, test transfers and careful paste verification. The radar decision is whether the next transfer should proceed, not whether a wallet warning proves the address is safe.
閉じる
Decision outcome: Before any high-value transfer, treat transaction history as untrusted, select from a verified address book where possible, compare beginning, middle and ending characters, check the address on the signing device, send a small test transaction when the route is new or material, and stop if a warning, newly seen address, clipboard mismatch or support-channel pressure appears.
Evidence snapshot. This article was researched at 2026-09-22T02:44:00.289Z using MetaMask Help Center, Binance Blog, Binance Academy. A local queue, old draft, search snippet, social repost, price chart or AI summary was not treated as proof. Those surfaces can suggest a question, but every material claim below is tied to the cited source list and claim map.
記事の表：横にスクロールするか、表の領域にフォーカスして矢印キーを使ってください。
| Decision checkpoint | Evidence to read | Stop condition |
|---|---|---|
| Official object | address poisoning, transfer history, wallet warnings | the source cannot name the exact product, setting, route, policy, date or account surface |
| User boundary | account, jurisdiction, device, wallet, API key, bot, route or verification state | the user's state differs from the public source |
| Failure handling | recovery path, cancellation path, warning, test transfer, support channel or rollback note | the next step is irreversible or secret-dependent |
| Evidence log | URL, access time, selected setting and non-secret stop rule | proof would expose credentials, identity documents, private keys, balances or positions |
Verified facts. Claim c1: MetaMask describes address poisoning as attackers sending tiny or zero-value transactions from lookalike addresses so users may copy the wrong address later. Claim c2: MetaMask says users should pay attention to middle characters, avoid copying from transaction history, add frequently used addresses to contacts and use hardware-wallet confirmation. Claim c3: MetaMask security-alert guidance says warnings should lead users to double-check URLs or contract addresses, and malicious classifications mean users should not connect, sign or proceed. Claim c4: Binance materials describe spoofed address generation, transaction-history poisoning, full-address verification, address-book use and small test transfers as mitigation controls. These facts are intentionally narrow. They do not prove account eligibility, future availability, execution quality, legal status beyond the cited wording, tax treatment, account approval, support outcome, redemption success, price direction, liquidity depth or platform solvency.
Decision discipline for address poisoning transfer history wallet warning stop rules. The useful answer is not a universal winner. It is a source-bound scorecard: which official source answers the immediate question, which control is blank, which blank changes user risk, which test is reversible and which condition reopens the decision. An honest blank is safer than an invented advantage.
FAQ. What is the short answer? Address poisoning is a habit-driven transfer risk: a malicious lookalike address enters wallet history and waits for the user to copy it by mistake. What should be verified first? Verify the official source and the exact control surface. What should not be inferred? Do not infer eligibility, future support, legal treatment, tax treatment, recovery, execution quality, liquidity, redemption, consumer protection or account approval. When should the user stop? Stop when source, object, user state, permission, route, issuer, jurisdiction or failure handling is unclear.