Token & on-chain safety

A hot wallet — a browser extension or mobile app — keeps its private key on the device, encrypted, and connected to the internet through the browser or app it runs in. That connectivity is what makes it convenient and also what makes it the attack surface: a compromised browser, a malicious extension, or a phishing page with a fake "Connect Wallet" button can request a signature the moment the wallet is unlocked.

A hardware wallet generates and stores its private key inside a separate physical device; the browser only ever sees a signed transaction, never the key. That isolation depends on actually reading the device's own screen before approving — a compromised computer can ask a hardware wallet to sign something different from what the browser tab displays, and the device's screen is the only place that discrepancy shows up.

A burner wallet holds a small, deliberately limited balance and is used to interact with an unfamiliar or unaudited contract before any larger balance touches it. The point is blast radius: a drained burner is a bounded loss, not an emergency.

These tiers exist to match exposure to use: a fresh contract interaction on a small burner, everyday balances on a hardware wallet, and nothing significant sitting in a hot wallet that stays connected to sites all day.

An ERC-20 `approve` call grants a contract permission to move up to a specified amount of a token, independent of any single swap. Many interfaces request an unlimited approval by default, purely to avoid asking again on the next trade — which also means a contract that is later exploited, or later turns malicious through an upgrade, can move the entire approved balance in one transaction with no new signature involved.

Approvals don't expire on their own. A years-old approval to a project that shut down, or was quietly upgraded behind a proxy, stays live until it is explicitly revoked. Revocation sets the allowance back to zero and is a normal on-chain transaction — and every outstanding approval for an address is publicly readable, typically through a block explorer's dedicated token-approval page for that address.

Checking the list costs nothing but a look. Revoking an unused approval costs one ordinary transaction fee.

A seed phrase — usually 12 or 24 words — reconstructs every key derived from it. Whoever holds the phrase has permanent, total control of the wallet: there is no password reset and no support channel that can reverse it.

No legitimate wallet, exchange, or support agent ever asks for it, regardless of how the request is framed — a "wallet verification," a "sync error," a "security check" ahead of a promised airdrop. It is typed exactly once, into the wallet software itself, at setup or recovery, and never into a website, a form, a chat window, or a "seed phrase checker" tool.

A cloned wallet app or a lookalike site differing from the real one by a single character in its domain is only the delivery mechanism — the actual target is always the same 12 to 24 words.

Address poisoning exploits how addresses actually get checked in practice: a glance at the first and last few characters of a long string, not a read of the whole thing. An attacker generates a lookalike address that shares those characters and sends it a tiny or zero-value transfer, which then shows up in the wallet's own transaction history.

The next time a payment is meant to go to the real recipient, copying "the address last sent to" from history — a shortcut most wallets actively offer with a single tap — pastes the lookalike instead.

The only reliable check is comparing the complete address, not just its ends, ideally copied fresh from the original source each time rather than pulled back out of history.

A real airdrop either deposits tokens directly into a wallet or makes an on-chain claim available with no unusual signature required. A fake one uses the promise of free tokens to get a wallet connected to a malicious site, where the "claim" step is actually an approval or a signed message handing over control of assets already held.

A common sequence: an unfamiliar token matching a well-known project's name shows up unprompted in a wallet, followed by an invitation to visit a site and "claim" more of it. A project that already allocated tokens to an address has no technical reason to need that wallet to visit an external site and sign anything.

Interacting with a received token at all — even opening a swap interface to check its price — can surface a permission request before a single word about a claim appears.

A drainer is off-the-shelf malicious code, rented rather than purpose-built, deployed behind a convincing front end — a fake mint page, a fake exchange listing, a cloned marketplace. Once a wallet connects, the kit walks it through a sequence of signatures dressed up as ordinary steps (mint, verify, claim) that actually authorize moving its most valuable assets.

Because the kit is a shared commercial product, its request patterns are recognizable, and several current wallets flag them at the signature prompt itself — a warning worth reading in full rather than dismissed as routine friction.

A `Permit` or `permit2` signature looks like a free, gas-less approval, and functions exactly like one: it authorizes a transfer without a separate on-chain transaction, which is also why it never shows up in a gas estimate the way a suspicious contract call would.

Every wallet action — a balance, a transaction, a contract call — passes through an RPC endpoint, the node the wallet actually talks to. A wallet pointed at a malicious or compromised endpoint can be shown a fabricated balance, a fake transaction confirmation, or a manipulated gas estimate, independent of what happened on the real network.

This is the mechanism behind an unfamiliar "add this network" prompt on a sketchy site, or a browser extension offering a "faster" RPC: the endpoint itself becomes the thing lying to the wallet, which has no built-in way to catch that without cross-checking against a different node.

A wallet's own default, well-known RPC is a safer baseline than one pasted in from an unfamiliar link, and switching back to it is a single settings change.

Impersonation targets the channel, not the wallet: a support account, a project's name, or a familiar face reproduced closely enough — a near-identical handle, a copied profile photo, a reply posted directly under a project's own real announcement — to borrow trust it didn't earn.

The pattern repeats across platforms: contact arrives first — a direct message, a comment reply, an account claiming to be support — and resolves to one of two requests: the seed phrase itself, or a link to a site asking for a wallet connection and a signature.

A project's real support channel does not message first, and a link received in a message is unverifiable by definition — it has to be checked against a tab opened independently, never the link that arrived with the message.