Every airdrop cycle produces the same bloom: hundreds of "check if you qualify" sites appearing within hours of any credible hint that a token is coming. Most are phishing.

The eligibility checker deserves its own treatment — separate from fake claim pages — because the psychology is different. Claiming feels like an action with consequences, so some caution survives. Checking feels like reading, and people read carelessly. Scammers optimized for that gap: the checker format gets wallets connected and signatures signed at a moment when users believe they are doing nothing risky.

This guide covers the three grades of fake checker, the infrastructure timing trick that makes them credible, and the safe verification path. It joins our Airdrop Safety series alongside how fake airdrops reach you and the biggest airdrop scams.

Three properties make it the attacker's favorite:

1. It has a legitimate-sounding reason to exist. Real airdrops do involve eligibility. The format is not inherently absurd, so the surface plausibility is free.

2. It asks for low-friction actions. Connect a wallet, paste an address, click check — all things users do dozens of times per season. Habituation is the vulnerability; see how testnet seasons train users to connect and sign repeatedly.

3. It has a built-in escalation path. "Not eligible yet — verify activity / connect a different wallet / sign to refresh results." Each step deepens engagement right up to the signature that matters.

The mildest variant does nothing visibly malicious. You connect, it shows a spinner, maybe "0 points — try another wallet."

What it actually harvested: a confirmed live wallet address, linked to an IP and a session, operated by a human who connects to unfamiliar sites. That record is an asset. It goes into targeting lists that power follow-up attacks — personalized DMs ("your points from season 2 are ready"), fake support interactions, and address-specific phishing. This is the same playbook described in how fake airdrops reach you, and the reason a "read-only" connection is not free.

The fix that breaks this grade: paste your public address instead of connecting. An address alone reveals nothing you have not already revealed by existing on-chain. A genuine checker can work from a pasted address; if a site insists on connection for a read, that insistence is the red flag.

The checker upgrades the ask: "sign a message to verify you are human / decrypt your results / prove wallet ownership."

Proving wallet ownership with a signature is a real pattern in legitimate contexts (SIWE logins, for example) — which is exactly why it works here. But in the checker context, the signature can be:

• An EIP-2612 permit — an off-chain approval granting the attacker's contract an allowance, submitted later without any further action from you.

• A Permit2 approval — broad spending rights through a router; see Permit2 exploits explained.

• A raw eth_sign blob — potentially a full transaction; see eth_sign phishing explained.

The full signature taxonomy is in airdrop signature scams. The rule specific to checkers: a read never needs a write. Eligibility is a lookup. The instant "checking" produces a signature request, the site has stopped pretending to read.

The crudest and most destructive: the checker's result page says your wallet must be "synced" or "imported" to display eligibility, and the sync form asks for your seed phrase.

There is no legitimate version of this — not for checkers, not for faucets, not for wallet support, not ever. Entering the phrase anywhere outside your wallet software transfers the wallet to the attacker, usually with automated sweep logic watching for incoming funds forever after. If you have already typed it anywhere, treat the wallet as burned: create a fresh one and move assets immediately. (See self-custody for why nobody can reverse this for you.)

Fake checkers are rarely improvised. Look at the domain registration dates on a wave of checker phishing and a pattern emerges: lookalike domains are registered weeks or months before the real announcement, with pages staged and SEO aged so they surface the moment search demand exists.

Scammers monitor the precursors: incentivized testnets, points programs, integration activity, likely token generation events. By the time the project announces, the fake checker ecosystem is not catching up to the news — it is already ranked, already shared, already waiting. The practical consequence: "it showed up early" is not evidence of legitimacy. If anything, a checker appearing before the project has even confirmed an airdrop is the strongest possible tell that you are looking at staged infrastructure.

For any real or rumored airdrop, the sequence that never requires trust in a random site:

1. Start at the project's own documentation. Official docs, GitHub, and governance forums — reached by typing the domain yourself or from a bookmark, never from search ads (see fake airdrop distribution channels for why ads are hostile territory).

2. Look for the published mechanics. Genuine programs document claim windows, snapshot blocks, and eligibility rules. Many publish the merkle tree or contract addresses so eligibility can be verified independently.

3. Use your public address, pasted. If a tool exists at all, an honest one accepts a pasted address.

4. Before any real claim, run the on-chain checks. Contract age, deployer history, holder concentration — the full workflow is airdrop scam checking in 5 steps.

5. Claim with a dedicated wallet. The burner wallet claim workflow contains the blast radius of anything you misjudge.

All of these checks, consolidated and printable, live in the airdrop safety checklist. The one-line version of this entire guide: eligibility is a question, and questions do not need signatures.

Originally published at https://theonchaindiary.com/articles/airdrop-eligibility-checker-phishing/. More Web3 security guides and risk-scoring tools at Onchain Diary.