Every airdrop scam needs one ingredient more than any other: a reason to act now. The snapshot mechanic supplies the perfect fake one. “The snapshot happens in 6 hours — verify your wallet now or lose your allocation.” Countless variations of that sentence have run through X replies, Telegram DMs, and cloned sites, and the sentence is not merely phishing — it is a technical contradiction.

This article explains what a snapshot actually is, walks the deadline-pressure playbook that fake campaigns run against real ones, covers the zombie campaigns that keep stealing years after their airdrops ended, and gives the verification rules that make the pattern collapse on sight. It is part of our Airdrop Safety series.

What a Snapshot Actually Records

A snapshot is a read of the chain at a fixed moment. The project picks a block height, and a script walks the chain state at that height: who held the token, who used the protocol, how much, for how long. Eligibility and allocation are computed from that historical data. If a merkle tree is used for distribution, the leaves are the computed allocations, and the claim contract later verifies each user’s proof against the root.

Read that again from the user’s side: everything the snapshot needs from you already happened. Your balance existed. Your transactions existed. The chain remembers. A project that needed you to “register” before its snapshot would be building a worse version of the mechanism — collecting self-reported data instead of reading the chain it is about to distribute tokens on.

That is the collapse-on-sight test. It does not require judging the website’s design, the URL, or the tone of the announcement. “Verify before the snapshot” fails at the level of mechanism, before any surface-level check even starts.

The Deadline-Pressure Playbook

The fake version follows a stable script. Recognizing the script is faster than evaluating each instance.

The announcement rides a real project. The scam does not announce its own campaign — it latches onto one people are already waiting for. Impersonator accounts reply under the real project’s posts within minutes, DMs cite the real campaign’s name, and cloned domains register variations of the real one. The infrastructure often goes up before the hype does: phishing domains registered weeks ahead of a campaign, waiting for the announcement moment. How this supply chain works — kits, domains, traffic — is mapped in anatomy of the biggest airdrop scams.

The countdown starts immediately. The page shows hours, not days. The purpose is not information but suppression — of the checks you would otherwise run. Urgency is the oldest tool in social engineering precisely because it works on experienced users too; the difference between a veteran and a novice is how many seconds of doubt they need before tapping.

The action is small. “Check eligibility.” “Sync wallet.” “Confirm allocation.” None of these sound like transfers. But behind the connect button is a wallet drainer page whose entire product is the signature prompt that follows the connection — an approval, a permit, or in the account-takeover cases an EIP-7702 delegation. What each signature type can take from you is broken down in airdrop signature scams.

The deadline never actually matters. Follow the pattern to its end: the snapshot is fake, so its deadline is theater. When the countdown expires, the site shows “verification closed” — and a new timer starts for the “final extension.” A deadline that extends is a marketing asset being reused, not a rule being enforced.

The Zombie Problem: Campaigns That Outlive Their Airdrops

The most durable snapshot scams do not even need a live campaign. Flare’s snapshot for XRP holders was taken in December 2020, and according to public reports, “Flare airdrop” verification scams were still circulating years after distribution was complete. The pattern is general: an airdrop ends, its SEO footprint remains, and new users arrive daily who never learned the campaign finished. For a scam operator, a dead campaign is an evergreen one — no fresh announcements needed, just a page claiming to be the “official claim portal” for an allocation that no longer exists.

The structural lesson: finish lines do not protect you. “Already distributed” and “claimed years ago” are facts about the campaign’s history that a fake page can simply not mention. The checks below apply regardless of whether a campaign is upcoming, live, or long dead.

The Verification Rules

Rule 1: Eligibility never requires a connection. Anything you can learn by connecting a wallet to an eligibility page, you can learn without it — from the project’s published criteria, a block explorer, or the official checker on the real domain. The connect button is the product. The detailed mechanics of why checkers are the ideal phishing format are in airdrop eligibility checker phishing.

Rule 2: Pre-token deadlines are inverted. Real urgency runs the other direction: the token must exist before a claim makes sense. A deadline attached to a token that does not exist yet — verify before the snapshot, register before TGE — describes a mechanism that is not how airdrops work. The five-step on-chain inspection for whatever claim contract eventually appears is in airdrop scam checker.

Rule 3: Sources are findable, pressure is not proof. A real deadline is verifiable from the project’s official channels — the same place the campaign itself is announced. If the only evidence of the deadline is the page applying the pressure, the deadline is the campaign.

Rule 4: Burners make mistakes cheap. When a claim is real, you will still be connecting a wallet to a website. The burner wallet workflow — dedicated low-value wallet, bookmarked official URL, read signatures, revoke after — converts a catastrophic error into a small one. The full pre-connect checklist lives in the airdrop safety checklist.

What This Check Cannot Tell You

The mechanism test is a scam filter, not an investment thesis. A campaign can pass every rule here — real snapshot, no fake deadline, verifiable claim contract — and still distribute a token with no liquidity, no listing, and no future. Safety checks answer “will I be robbed,” and that is all they answer. Whether the allocation is worth claiming is a separate question, settled by the token’s economics rather than its claim page.

There is also a genuine gray zone: some projects do run “registration” phases for off-chain activity tracking (points programs, waitlists) before a token exists. These are not snapshots — they are points systems, and their risk profile is different: the hazard is data and attention, not signatures. The moment any pre-token phase asks for wallet credentials, a seed phrase, or a signature, it has left the gray zone and entered the drainer pattern, whatever language it uses to describe itself.

The snapshot inverted is the entire scam: a read dressed up as a write, a past event dressed up as a deadline, and your own history dressed up as something you still need to prove. You already proved it — by holding, by transacting, by being on the chain the project is about to read. The verification page was never verifying anything. It was collecting.

This article is part of our Airdrop Safety series.

Frequently Asked Questions

Do I need to do anything before an airdrop snapshot?

No. A snapshot records on-chain state at a specific block height — balances, activity, holdings — from blockchain history. The project's script reads the chain; your participation happened in the past or happens automatically. There is no 'register,' 'verify,' or 'sync' step before a real snapshot. If a campaign claims one is required, the campaign is describing a mechanism legitimate airdrops do not have.

How do snapshot verification scams work?

The scam inverts the real mechanic. Fake announcements — impersonator accounts on X, DMs, cloned sites — tell users to 'verify eligibility' or 'sync their wallet' before a snapshot deadline, with a countdown timer to force speed. The verification page is a wallet drainer: connecting triggers signature requests that authorize token transfers or account-level delegation. The deadline exists because the signature is easier to obtain from someone in a hurry.

How can I check airdrop eligibility without connecting my wallet?

Legitimate projects publish eligibility criteria and, after the snapshot, either a checker on their official domain or an on-chain claim contract. You can verify eligibility by reading the criteria against your own on-chain history on a block explorer, or by using the official checker from a bookmarked official URL. Connecting a wallet should only ever happen at the official claim step — and eligibility itself never requires a signature.

What are zombie airdrop scams?

Campaigns that outlive their moment. Flare's snapshot for XRP holders was taken in December 2020, and according to public reports, 'new Flare airdrop' verification scams still circulated years later. The pattern repeats with ended or fully-claimed airdrops: the scam keeps running because new users keep arriving who never learned the campaign finished. Anything announcing a second round of a years-old, fully distributed airdrop should be treated as fabricated by default.

Do real airdrops have claim deadlines?

Yes — after the token exists, claims often close after a window (commonly 30 to 90 days, set per project), and unclaimed tokens are redirected by the project's contract logic. But that deadline applies to claiming tokens that already exist, through a contract you can verify on a block explorer. It never applies to 'verifying' or 'registering' a wallet before a snapshot. Pre-token urgency is the inversion; post-token claim windows are normal.