Presale phishing defense — four attack windows you're vulnerable in

Most retail losses connected to presales don’t come from bad presales. They come from getting phished during one of four moments where the buyer is reaching for something they want and not paying attention to what they’re signing.

Here are the four windows, in order of frequency.

Window 1: TGE morning (highest-frequency)

What happens: the project announces TGE. Email lists, X posts, and Telegram are flooded with “claim is live” announcements. Among these, attackers post identical-looking announcements with malicious links to clones of the claim page.

Why it works:

• You’ve been waiting weeks. Your guard is down.
• The clone is pixel-perfect — the only difference is the URL.
• The clone’s wallet-connect signs a malicious transaction (often setApprovalForAll on your most valuable token holdings) that drains everything when you click “claim”.

Defense:

• Bookmark the real claim URL well before TGE, from the project’s original domain (whatever you’ve been on since the presale itself).
• On TGE morning, navigate to the bookmark. Never click a link in an email, X post, or Telegram.
• Use a fresh, empty claim wallet — not your main holdings wallet. Transfer ETH for gas only.
• Read every wallet-connect transaction. If the contract’s permissions look weird (asking for approval on tokens unrelated to the claim), reject.

Window 2: Airdrop announcements (medium-frequency)

What happens: weeks or months after TGE, the project airdrops to early holders. Attackers know this and send fake “you’re eligible” emails or DMs with links to a “claim” page that requires “verifying” your wallet (usually by signing a malicious message).

Why it works:

• Real airdrops use a similar UX flow.
• “Verify your wallet” sounds harmless but the signed message is sometimes a permit for token transfer.
• Telegram DMs from “support” or “team members” feel personal.

Defense:

• The official project never DMs you first.
• Real airdrops never require you to sign a message that mentions token amounts or addresses you don’t recognize.
• Always check the message you’re signing. Wallet UI shows the contents — read it. If it includes an approve or permit for a token, reject.

Window 3: Token migrations (medium-frequency)

What happens: a project announces a “token migration” (usually V1 → V2). You’re asked to send your V1 tokens to a “swap contract” to receive V2 tokens. Attackers spin up fake migration sites in parallel.

Why it works:

• Real migrations do happen.
• The legitimate migration is rare enough that retail isn’t sure what the right process looks like.
• Sending V1 tokens to a malicious contract is irreversible and looks identical to a legitimate transaction.

Defense:

• Migrations are announced through the project’s official channels with at least 30 days notice. There is no “urgent” migration.
• Verify the migration contract address from at least two sources (project blog + project Twitter + announcement on the original presale platform).
• Do a small test transaction first. If V2 doesn’t appear within the documented time, stop.
• If a “team member” DMs you about a migration, it’s fake.

Window 4: Address poisoning (low-frequency, high-impact)

What happens: an attacker monitors your wallet’s transaction history and creates a wallet address whose first 4 and last 4 characters match an address you’ve sent to recently. They send you a tiny “dust” transaction from that address. Later, when you copy-paste an address from your wallet history, you might pick the attacker’s address by accident.

Why it works:

• Wallets show truncated addresses (0x4a7f...82bc) — only the first 4 and last 4 characters.
• Attackers generate vanity addresses that match.
• Copy-paste from history feels safer than typing.

Defense:

• Use the address book / labels feature in your wallet. Don’t copy from transaction history.
• Always verify the full address, character by character, before signing.
• For large transfers, use ENS names if available, or verify the address by sending a small test amount first.

A general rule that prevents 90% of presale phishing

Use a separate wallet for claims, with no other holdings on it. Transfer to your main wallet via an explicit, small-test-first transaction.

This single discipline isolates the claim contract risk. Even if you’re phished during the claim, the only thing that can be drained is the empty claim wallet plus the gas you funded it with — not your portfolio.

It feels like extra friction. It is. The friction is the point.

The hardware wallet rule

A hardware wallet doesn’t prevent you from signing a malicious transaction. It prevents the key from leaking. Both matter.

Always:

• Read the transaction on the device’s own screen, not on the computer.
• Reject if you don’t understand what you’re signing.
• Update firmware promptly.

What to do if you’re phished

If you signed a malicious transaction:

1. Move everything else immediately — drained wallets often get re-drained from approvals you forgot about.
2. Use a tool like revoke.cash to see what approvals exist on your wallet, and revoke them.
3. Report to the chain’s anti-fraud channels — sometimes the attacker’s funds get frozen at exchanges.
4. Don’t pay anyone who claims they can “recover” your funds — they’re a second-stage scam.

The honest summary

Phishing is the #1 source of retail losses around presales, and the attacks are predictable: TGE morning, airdrops, migrations, address poisoning. Use a dedicated claim wallet. Bookmark the real URL. Read every transaction. Don’t click links in emails or DMs.

If you build these four habits, you’ve eliminated 90% of how presale buyers actually lose money.