Most airdrop safety advice reduces to “be careful” — which helps nobody at the moment a countdown timer is running. What actually survives contact with a real claim window is a workflow: fixed steps, decided in advance, executed the same way every time.

This is that workflow. It assumes you have already read enough of the threat model — how fake claim sites work, how they reach you, what signatures can do — and now want the operational version. Five stages, in order of execution.

Stage 1: verify the airdrop exists — from two independent sources

Before any wallet is involved, establish that the airdrop is real, using sources you navigated to yourself:

  • Official documentation. Type the project’s domain yourself. Look for claim mechanics, snapshot dates, eligibility rules.
  • GitHub / governance. Real programs leave engineering and governance traces: contract deployments, snapshot proposals, merkle root publications. See what a merkle tree is and why claim programs publish them.

The two sources must agree independently. A random blog repeating an announcement is not a second source — it is an echo, and echoes are cheap to fake. If documentation and on-chain/governance records do not corroborate each other, stop here; there is nothing to claim.

Anti-signal at this stage: any “airdrop” that exists only as an announcement in your DMs, a reply thread, or an ad. The channels that deliver fake airdrops are precisely the places real ones are never exclusively announced.

Stage 2: fix the URL before the frenzy

Once verified, decide the destination now — before claim day, before urgency exists.

  • Bookmark the official claim URL from the documentation page.
  • Note the official claim contract address alongside it, if published.
  • On claim day, navigate only via that bookmark.

This one habit deletes the entire distribution layer of the attack: paid search ads on branded keywords, lookalike domains, reply phishing, fake eligibility checkers. All of them depend on you navigating from a channel at the moment of maximum hurry. A bookmark has no channel. Related rule from fake eligibility checker phishing: if you find yourself searching for the claim site, you have already left the safe path.

Stage 3: the dedicated claim wallet

The single highest-leverage habit in this entire guide.

Setup:

  1. Generate a fresh wallet from a new seed phrase — not a derived account of your main phrase, a separate phrase entirely.
  2. Store the phrase exactly as seriously as your main one (hardware wallet backup or equivalent paper/metal practice — see cold wallet).
  3. Fund it with only the gas the claim needs, on the chain the claim happens.

Usage rules:

  • This wallet claims. It does not hold. Airdropped tokens either stay here (if small) or get swept out to your holding setup (if meaningful).
  • Your main wallet — savings, positions, non-custodial long-term holdings — never connects to a claim site. Not once, not “just to check.”

Why this works: drainers exploit approvals, and approvals can only take what the approving wallet holds. An empty wallet is not a smaller loss; it is a rounding error for the attacker and a non-event for you. The same logic applies to testnet farming, as covered in testnet airdrop safety.

Stage 4: claim — and read the signature as a contract

At the moment of signing, slow down and read three fields, in this order:

  1. Function. A genuine claim usually is a simple call to the distributor contract. approve, permit, permit2, increaseAllowance, or an unrecognizable function on a claim page means you are granting, not receiving. The taxonomy lives in airdrop signature scams; the EIP-7702 delegation variant — one signature that can hand an EOA to attacker code — is in EIP-7702 airdrop phishing.
  2. Spender / contract. Paste it into a block explorer. Contract deployed days ago? No verified source? Deployer address with a history of drainer patterns? Walk away. The deeper checks — holder distribution, deployer history — are in airdrop scam checking in 5 steps and how to spot wallet drainers.
  3. Allowance. Anything unlimited on an unfamiliar contract is an automatic decline. See infinite approvals explained.

If your wallet shows raw, undecoded data, you are blind signing — decline by default and use a wallet/tool that decodes or simulates before confirming. If you use a hardware wallet, remember: it guards your keys, not your judgment; the screen confirms what you are about to authorize, so read it the same way.

Stage 5: after the claim — close the loop

Claiming is not the end of the workflow.

  1. Revoke what you granted. Approvals persist after the transaction that created them. Sweep your claim wallet’s approval list — token approval safety covers tools and cadence.
  2. Move the tokens if they matter. If the airdrop has real value, send it out of the claim wallet to your holding setup. Keep the claim wallet near-zero by policy.
  3. Audit periodically. A quick approval-and-balance review of the claim wallet before each new claim season — the mechanics are in how to audit your wallet activity.
  4. Expect the follow-up wave. A real claim on-chain is public. After any major distribution, fake “phase 2 claim” and checker sites bloom; treat them exactly as the first wave — verify via the bookmark path, not via announcements that find you.

The workflow, compressed

For the fridge door:

  1. Airdrop verified from two independent official sources? No → stop.
  2. Claim URL bookmarked from documentation, contract address noted? No → do it now.
  3. Dedicated claim wallet funded with gas only? No → make one.
  4. Signature read: function, spender, allowance all sane and decodable? No → decline.
  5. After: revoke approvals, sweep value, audit.

All twelve pre-claim checks in one printable page: the airdrop safety checklist. This article is part of our Airdrop Safety series.

Frequently Asked Questions

Should I claim airdrops with my main wallet?

No. Use a dedicated wallet that holds only the gas needed and nothing else worth stealing. If the claim site turns out to be a drainer, the attacker gets an empty wallet. Generate it from a separate seed phrase, store that phrase the same way as your main one, and never mix roles — claiming wallets claim, holding wallets hold.

How do I find the real airdrop claim URL?

From the project's official documentation and GitHub, reached by typing the domain yourself — then cross-check that two independent official sources agree. Never reach a claim page through search results (paid ads on branded keywords are a documented drainer channel), social replies, DMs, or QR codes. Bookmark the verified URL before claim day so the frenzy cannot redirect you.

What should I check before connecting a wallet to a claim site?

Run the claim contract through a block explorer: how old is it, who deployed it, is the source verified, how are holdings distributed? A contract deployed days before the claim with no history and concentrated holdings fits the wallet drainer profile. The full five-step workflow is in our airdrop scam checker guide.

What do I do after claiming an airdrop?

Three things: revoke the approvals you granted during the claim ( approvals are spending permissions that persist after the transaction ), sweep the airdropped tokens to your holding setup if the value justifies it, and audit your wallet's approval list periodically. We cover the exact steps in token approval safety and how to audit your wallet activity.

Is a hardware wallet enough protection for claiming?

A hardware wallet protects your keys, not your signatures. If you blindly approve a drainer contract on your hardware wallet's companion interface, the transaction is just as draining — the device did exactly what you told it. Hardware wallets shine when combined with the same workflow: read what you are signing, and keep claim interactions on a separate, low-value account.