Personal security: phishing, address poisoning, approvals

Most individual losses in this asset class do not involve a broken cryptographic system. They involve a person being persuaded to reveal a secret, to approve a transaction they misread, or to send funds to an address that looks correct and is not. The attacker needs one of exactly two things: the key itself, or a valid signature from it. Every practical defense is aimed at one of those two paths.

The recovery phrase is the asset

A seed phrase reconstructs the private key and therefore the ability to move everything derived from it, on every chain, permanently. Two consequences follow with no exceptions. Anyone who reads it has full control, which is why it does not belong in a photograph, a cloud note, an email draft, a screenshot or a message to anybody, including support staff, who never need it. And nobody can restore it, which is why a single copy in a single location is a common route to key loss through fire, flood, disposal or forgetting. Legitimate wallet software asks for the phrase only when restoring a wallet on a device, and never to validate, verify, migrate, unlock or claim anything.

Phishing has moved to convincing infrastructure

Contemporary phishing is not a badly written email. The common patterns are a paid search result above the real one, a lookalike domain differing by a character, a support account that replies within seconds of a public complaint, a fake application in an app store, and a claim page for an airdrop that appears in a wallet's own transaction history. In each case the destination is a functioning interface that asks for a signature. The most damaging outcome is not a transfer but an approval, because that grants continuing access rather than moving a fixed amount once. Structural habits work better than vigilance: reaching interfaces through saved bookmarks rather than search, verifying the exact domain string before signing anything, treating unsolicited tokens and unexpected claim pages as hostile by default, and remembering that no genuine support process begins in a direct message.

Address poisoning and dusting

Address poisoning exploits how people copy addresses. The attacker generates an address whose first and last characters match one that has already been used, then sends a zero-value or trivial transfer so that this near-identical string appears in the transaction history. Later, an address copied from history rather than from the original source sends funds to the attacker, and because the visible portions match, a quick check passes. A dusting attack uses similar tiny transfers for a different goal, namely linking addresses to a common owner through subsequent spending. Three habits defeat the first, and the first two also limit exposure to the second: keeping frequently used destinations in a saved address book rather than in history, verifying the entire string rather than the visible ends, and sending a small test transaction before a large transfer to a new destination. Human-readable names help only if the name itself is verified, since lookalike names are also registrable.

Approvals are standing permissions, not one-time actions

Interacting with most applications requires granting a contract permission to move tokens on a holder's behalf. Under the ERC-20 pattern this is an allowance, and interfaces have commonly requested an unlimited one to avoid asking again later. That approval persists after the interaction ends, so a contract that is later upgraded, compromised or malicious from the start can move the approved tokens at any point in the future without any new interaction. The equivalent for a non-fungible token collection grants access to an entire collection at once. Signature-based permissions add a further wrinkle: they are signed off-chain, cost nothing, produce no on-chain record until used, and therefore do not appear in a wallet's history as something granted. The practical hygiene is to review outstanding approvals periodically, revoke those no longer needed, prefer a bounded amount where an interface offers one, and treat any request to approve an unfamiliar contract as the most consequential click in the process. Revoking costs a transaction fee, which is why median transaction fee and average transaction fee are worth checking before a cleanup session on a congested network.

Reading what is actually being signed

A digital signature authorizes a specific message, and the risk lies in the gap between what the interface says and what the message contains. Hardware wallets reduce key theft substantially because the key never leaves the device, and they do not prevent a holder from signing a harmful message on a screen too small to display it fully, a situation usually described as blind signing. Structured signing formats that show a human-readable summary bound to a specific application help, and transaction simulation that previews balance changes before signing helps more. Where a signature request cannot be understood, declining it costs nothing.

Structure rather than constant vigilance

Attention fails eventually, so the durable defenses are structural. Separating funds across purposes limits what any single compromised signature can reach: a dedicated address for experimentation, another for routine activity, and long-term holdings in cold storage that never touches an unfamiliar interface. A multisignature arrangement makes a single compromised key insufficient for larger balances. Backups stored in separate physical locations address loss, and a documented recovery procedure addresses succession. If a compromise is suspected, the ordering matters: assets are moved to a new address generated on a clean device first, because revoking approvals from a key that may already be controlled by an attacker does not secure anything, and a key believed to be exposed is best treated as permanently unusable rather than cleaned up.

That closes this track. The glossary defines each attack pattern named above, incidents records how these techniques have appeared at scale, and the risk section collects the structural exposures covered in the preceding articles.