The reason this pattern works is that nothing about it feels like a loss while it is happening. You do not send anything. Your balance does not change. You click a button labelled claim.
The chain, in four steps that rarely vary
Step one is delivery. A direct message, a post from a compromised or lookalike account, a link shared in a group, an automated reply under a popular post. What they share: the information came to you rather than you going to find it.
Step two is the page. Usually complete — project description, a countdown, a claimed count, social icons. Those exist to manufacture legitimacy and urgency. The domain is typically close to the real project's, which is the layer covered in confirming a real app and a real site.
Step three is connecting a wallet. Connecting alone usually causes no loss; its function is to let the page read your address and see what you hold. Some pages adjust what they ask for next based on what they find.
Step four is the signature request, and this is the actual objective. Framed as verifying eligibility, confirming a claim, or binding an address, while the substance is frequently an approval. Nothing is transferred, the balance is unchanged, and there is no sense of loss at all. The mechanics are in what that button actually signed.
"Pay a fee to claim" ends the analysis
This variant is the easiest to call, because the structure is explicit: to receive something that is yours, first send something. That is a gate.
One technical clarification, so the rule does not misfire. A genuine on-chain claim can legitimately require a network fee. That fee is paid to the network, is comparable to any transaction you initiate yourself, and appears in your wallet as an ordinary transaction cost.
The fake version is different: it asks you to send an asset to a specified address, under a name like activation, deposit, gateway or verification fee. The test is whether it is deducted as a network fee or sent as a transfer to an address. If it goes to an address, it is a scam — no exceptions.
Tokens that turn up in your wallet unasked
Another common form: tokens you never claimed appear in your wallet, often carrying a recognisable project's name and an apparently significant value.
Their purpose is to route you to a page. You want to know what they are and whether they can be sold, so you search, and land on an imitation swap or claim page. Some such tokens also have contracts that behave unexpectedly on transfer.
The correct response is to ignore them. Do not click links in the token's details, do not attempt to swap, do not search the name. Most wallets support hiding specific tokens; hide it. Anyone can send tokens to any address, so "it is in my wallet" carries no implication that it was meant for you.
One further note: hide the token rather than trying to get rid of it. Sending it somewhere or interacting with the contract to "clear" it means transacting with code you have no reason to trust, and it costs a fee to do something that hiding achieves for nothing.
What a genuine airdrop generally looks like
Everything above is negative space. Here is the positive reference — knowing what real looks like is less work than memorising every variety of fake.
The entry point is on the project's own site. Typically a path under the main domain rather than a newly registered separate one, published through the project's official announcement channels, reachable by anyone from a public entry point. Nobody needs to hand you a link.
It does not come looking for you. A real distribution has no reason to message you privately, reply to you in a comment thread, or offer a personal allocation. Eligibility is usually determined by on-chain history, which is public — the project does not need to contact you to work out the list.
Claiming is claiming, not authorising. A normal claim sends assets to your address; you pay a network fee and sign an ordinary transaction. It does not require you to grant transfer permission over any token.
Time pressure is usually mild. Most projects allow weeks or months. A countdown is not automatically fake, but a countdown attached to a link that arrived in your messages settles the question.
Eligibility checkers deserve the same treatment
Some pages ask for nothing but your address, just to "check if you qualify". That feels harmless. But it accomplishes one thing regardless: it associates your address with a live person interested in airdrops — a list well suited to more targeted phishing later.
So run checker pages through the same verification. There is never any urgency about checking eligibility, and if the page is fake your address has joined someone's list.
The countdown, and the one time it is real
Nearly every fake claim page has a timer on it, and the timer is doing a specific job: removing the interval in which you would go and check. It is the cheapest element on the page to build and the most reliable one to include.
Two things give it away. The first is that it usually restarts. Close the page, reopen it in a fresh window, and a genuinely fixed deadline will show less time remaining, while a manufactured one often resets to the same figure. That takes about twenty seconds to test and requires no expertise.
The second is scale. A real distribution window is measured in weeks or months, because a project wants as many eligible people as possible to claim. A window measured in hours serves the opposite purpose, and no legitimate project benefits from most of its recipients missing out.
There is a case where urgency is genuine: some claim windows really do close, and unclaimed allocations really do get returned. But that deadline is published in the project's own announcement channels well in advance, and you will find it there when you do the reverse check. A deadline you only learn about from the page enforcing it is not a deadline, it is a technique.
What to do with a timer
Treat it as absent. Do the reverse verification at your own pace, and if the window genuinely closes while you are checking, you have lost an allocation you were never certain existed. Compare that with the alternative cost, which is a signature you cannot take back.
Reverse verification: a procedure, not an attitude
Reverse verification means not entering through the door you were given. Find the official channel independently, and confirm from there whether the thing exists.
Four steps you can follow exactly
- Close the page or message. Do not verify while looking at it; you will unconsciously use it as your reference.
- Reach the project's official entry point yourself. A bookmark if you have one; otherwise the project's listed links on a well-known data site or a block explorer's project page, not a search for the project name.
- Look for the announcement there. A real airdrop appears in official announcement channels. If it is not there, treat it as not existing.
- Compare the claim address. If an official announcement does exist, use the link inside it and read the domain character by character, not the link you originally received.
Step three carries the whole procedure: not finding it means treating it as non-existent. You never have to prove anything is fake. You only need the absence of evidence that it is real. That puts the burden in the right place and costs almost nothing to apply.
For a tickable version of this, the official source checklist turns it into a five-item flow showing exactly which item failed. It runs in your browser and sends nothing anywhere.
If a claim page does request a signature
Four fields: the requesting domain, the action type, who is being authorised, and the amount. Any one unclear, cancel.
For airdrops specifically the action type matters most. A claim should not require granting transfer permission. If the prompt shows an approval rather than a claim, the page is doing something different from what it says, and that mismatch is itself the conclusion.
The subtler variant is a request presented as signing structured data, costing no fee, which removes the moment of hesitation a cost normally creates. No fee does not mean no consequence.
If you already connected, or already signed
Order: move assets, then revoke, then investigate. Many people invert this and spend the critical window working out exactly what they signed, which is precisely the window in which it can be used.
Move anything of value to a fresh wallet first. Then revoke the approvals on the original address using a block explorer's approval tool. Then, without time pressure, work out what happened and whether the same site prompted you more than once. Full detail in wallet signatures: what that button actually signed.
If you take one thing from this article: an unexpected token is information, not an opportunity. What it tells you is that your address has been added to somebody's list, which is worth knowing on its own.