This is the consolidated checklist for our Airdrop Safety series — every check from the deep dives in one page. It is designed to be run top to bottom, calmly, before claim day whenever possible. The structure: five checks before you connect anything, four at the signature, three after.

One law governs the whole list: a single failed check is a stop, not a caution. Fakes are engineered to pass most checks. Your edge is refusing to trade away the ones they cannot pass.

Part 1 — Before you connect

Check 1: Two independent official sources confirm the airdrop. Documentation you navigated to by typing the domain yourself, plus a second independent trace — GitHub, governance forum, published snapshot or merkle details. An announcement that exists only in DMs, replies, ads, or a single tweet is not verification. Details: fake airdrop distribution channels.

Check 2: The claim URL came from documentation, and you bookmarked it. Not from search results, not from an ad, not from a QR code, not from anything that found you. Bookmark it now, navigate from the bookmark later. If you notice yourself searching for the claim site, you have already left the safe path — eligibility checker phishing is waiting there.

Check 3: The domain itself survives inspection. Look at the domain in the address bar character by character: no hyphen additions, no .app-vs-.io swaps, no homoglyph lookalikes. Check its age if you can — phishing infrastructure is registered before the hype, so “early” is not “authentic.” Urgency framing (“portal closes soon”) counts against the site, not for it.

Check 4: The claim contract survives explorer inspection. Paste the contract address into a block explorer and check: source verified? Deployed how long ago? Who deployed it — any history of drainer patterns? How are holdings distributed? The full workflow: airdrop scam checking in 5 steps and how to spot wallet drainers.

Check 5: Nothing unsolicited is steering you. Tokens or NFTs that appeared in your wallet uninvited, DMs “notifying” you of eligibility, checker sites that insist you connect rather than paste an address — all of it is bait. An unsolicited airdrop is not an asset; it is a delivery mechanism.

Part 2 — At the signature

Check 6: The function is a claim, not a grant. A genuine claim reads as a call to the distributor contract. approve, permit, Permit2 flows, or an unknown function means you are granting something. And any authorization / delegation / upgrade language is the EIP-7702 pattern — account-level takeover, see EIP-7702 airdrop phishing. Full taxonomy: airdrop signature scams.

Check 7: The spender and allowance are sane. Spender = who gains rights. Paste it into the explorer; a days-old unverifiable contract fails check 4’s standard all over again. Allowance = how much they can take; unlimited on an unfamiliar contract is an automatic decline (infinite approvals explained).

Check 8: The prompt is fully decoded — you are not blind signing. Raw hex where a claim should be means your wallet cannot show you what happens next. Decline blind signing by default. If you use a hardware wallet, its screen is showing you exactly what you authorize — read it with the same three checks.

Check 9: The wallet you connected is the dedicated claim wallet. Separate seed phrase, gas-only balance, holds nothing you would grieve. This is the check that makes all the others survivable — a perfect fake reaching an empty wallet is a non-event. Setup details: how to claim airdrops safely. Your main wallet never connects to claim pages. Not once.

Part 3 — After the claim

Check 10: Revoke what the flow granted. Approvals persist after the transaction — they are standing permissions. Sweep the claim wallet’s approval list immediately after claiming. Tools and cadence: token approval safety.

Check 11: Sweep value out and keep the claim wallet near-zero. Airdropped tokens with real value move to your holding setup. The claim wallet stays a burner by policy, ready for the next season’s mistakes-not-yet-made.

Check 12: Audit before the next season. A quick approval-and-balance review of the claim wallet before every new claim wave — mechanics in how to audit your wallet activity. Expect the follow-up wave too: after any real distribution, “phase 2” fakes bloom, and the list starts again at check 1.

The list, compressed

  1. Airdrop confirmed by two independent official sources
  2. Claim URL bookmarked from documentation
  3. Domain inspected character by character
  4. Claim contract passes explorer checks (age, source, deployer, holders)
  5. Nothing unsolicited steered you here
  6. Signature is a claim, not an approval/permit/delegation
  7. Spender verified, allowance finite
  8. Prompt fully decoded
  9. Connected wallet is the dedicated burner
  10. Approvals revoked after claiming
  11. Value swept out of the claim wallet
  12. Wallet audited before next season

Nine of the twelve are judgment; check 9 is insurance. If you build only one habit from the series, build that one.

The series continues at the hub: Airdrop Safety — the complete guide.

Frequently Asked Questions

What is the single most important airdrop safety check?

Using a dedicated claim wallet that holds nothing you cannot lose. Every other check depends on judgment and can fail under time pressure; wallet isolation caps the blast radius of any mistake at roughly zero. Generate it from a separate seed phrase, fund it with gas only, and never let your main wallet touch a claim site.

How do I verify an airdrop claim site is real?

Confirm the airdrop exists from two independent official sources you navigated to yourself (documentation and GitHub/governance), take the claim URL from that documentation — never from search, ads, replies, or DMs — and then inspect the claim contract on a block explorer: age, verified source, deployer history, holder distribution. A contract deployed days before the claim with no history fits the drainer profile.

What are the red flags in a wallet signature prompt?

Five patterns: an approve/permit/permit2 function on a claim page, an unlimited allowance, a spender contract you cannot verify, raw undecoded data (blind signing), and any authorization/delegation/upgrade language — the EIP-7702 pattern that hands account-level control to attacker code. A legitimate claim is a read of the distributor contract; it does not grant spending rights or delegate your account.

Should I revoke approvals after claiming an airdrop?

Yes. Approvals persist after the transaction that created them — they are standing permissions, not one-time actions. After any claim, review and revoke the approvals the flow created, sweep any valuable tokens out of the claim wallet, and re-audit the wallet's approval list before each new claim season.

Can I just check the site's design to spot fakes?

No — design is the weakest signal there is. Drainer kits ship pixel-perfect clones of real projects, and rented kits update faster than most official sites. Verify infrastructure (domain age, contract history, source code) and mechanics (what the signature does), never aesthetics. The checks that work are all in this checklist.