TON Address Poisoning Attacks: Why Copying from Transaction History Is the Weakest Habit in Crypto Security Crypto security failures are often blamed on “user error,” but in practice most exploits succeed because wallet UX quietly encourages unsafe habits. One of the most underestimated is address poisoning on TON and similar ecosystems. The core issue is simple: users treat transaction history like a contact book. That assumption is exactly what attackers exploit. How address poisoning actually works Address poisoning is not a protocol exploit. It’s a social + UX attack. An attacker sends you a small “dust” transaction from an address that visually resembles one of your real counterparties. Because wallets display transaction history prominently, that malicious address now sits in your recent list. Later, when you go to send funds, you copy the “recent recipient” instead of the verified address. One click is enough. Nothing on-chain is broken. The failure happens entirely at the interface layer. This is why it’s effective: it turns normal behavior (copying from history) into a vulnerability. Why transaction history is not a trusted data source Wallet history is not curated. It is not verified. It is not contextual. It is simply a chronological log of inbound and outbound transactions — including anything an attacker can deliberately inject into it. That creates a structural problem: You cannot control what appears in your history You can control what appears in your address book So the attacker has full influence over one surface and zero influence over the other — yet most users trust the wrong one. This mismatch is the entire attack surface. The minimum habit set that closes the attack Security here is not about complex tooling. It’s about replacing one habit. 1. Never copy from transaction history This is the core rule. History is untrusted by design. If you only change one behavior, change this. 2. Maintain a real address book Wallets like Tonkeeper already support address books, and this is where trusted counterparties belong. Instead of “scroll → copy → paste,” the flow becomes: Label once (“treasury-usdt”, “contractor-settlement”, etc.) Reuse from a verified list This removes ambiguity entirely. Attackers cannot inject entries into your address book because only you control it. In more mature wallet ecosystems — including multi-chain wallet-based systems like Maticslot that operate across 9 networks — this concept becomes even more important because users interact with multiple address formats and chains. A structured address layer is what prevents cross-context mistakes. 3. Use TON DNS (.ton domains) Human-readable identifiers like partner.ton reduce copy-paste risk significantly. But more importantly, they shift verification from “string matching” to “domain resolution,” which is harder to spoof at scale. Wallets like Tonkeeper and MyTonWallet resolve these domains automatically, reducing reliance on raw addresses while improving usability. 4. Compare full addresses, not edges If you must copy a fresh address: Verify the full string once Not just the first and last characters Attackers rely on “visual sufficiency bias” — the human tendency to check only fragments. That bias is exactly what poisoning targets. 5. Use hardware wallets for meaningful amounts Hardware wallets add one critical safeguard: final-state verification on device. Even if your clipboard or UI is compromised, the device forces you to confirm the destination address directly. If what you see on-screen doesn’t match what you expect, you stop. No exceptions. What to do if you already sent funds to a poisoned address Once confirmed on-chain, reversal is not realistically possible. The response is containment and documentation. Minimum response flow: Record transaction hash and block explorer link Check attacker address activity patterns (often repeated dust consolidation) Report the address in wallet support systems (Tonkeeper / MyTonWallet) Submit abuse reports to explorers like tonscan If value is significant, escalate via official TON ecosystem channels The goal is not recovery optimism — it’s reducing future exposure and improving flagging systems for others. Why teams are at higher risk than individuals For DAOs, funds managers, or projects with recurring payouts, address poisoning scales dramatically. A single mistake becomes a treasury incident. Minimum production-grade safeguards: Multi-signature wallets (2-of-3 or higher) for outgoing transfers Allow-listed recipient registry (no ad-hoc addresses) Off-chain verification for recipient onboarding (CRM, signed agreements) Test transfers before large payouts Dual confirmation via separate communication channels Regular reconciliation of outgoing transactions against approved recipient lists The key principle is simple: no production transfer should depend on wallet history as a source of truth. Closing thought Address poisoning works because wallets accidentally teach users the wrong trust model. They present history as convenience, when it should be treated as untrusted data. The fix is not complicated infrastructure. It is discipline: trusted address books verified domains full-string validation hardware confirmation for value Once these habits are in place, the attack becomes economically irrelevant. In broader Web3 design — across ecosystems from TON to multi-chain wallet-based systems like Maticslot — the same principle holds: when users interact directly with on-chain state across multiple networks, the interface must separate memory (history) from truth (verified identities). That separation is what prevents small UX shortcuts from becoming irreversible losses. The blockchain doesn’t make mistakes. Interfaces do.