Airdrops: the claim is the attack
A token you didn't buy has appeared in your wallet. The balance looks real. There's a website printed right in the token's name, and the site says you're eligible for more.
Almost everything about that sentence is designed to get you to do one thing: connect your wallet and sign. The token is bait. The claim is the attack.
Real airdrops exist, and some have been genuinely valuable. But the mechanics of a legitimate claim and a malicious one look almost identical from the user's side, which is exactly why this category of theft keeps working.
Why free tokens are the perfect lure
Anyone can create a token and send it to any address. It costs the sender a small fee and costs you nothing, and you can't refuse it. That asymmetry is the whole foundation of the scam.
An unsolicited token does three useful things for an attacker. It gets their message into your wallet interface, where you're conditioned to trust what you see. It creates a feeling of ownership — I have something, I should do something with it. And it gives them a pretext for sending you to a website.
Some of these tokens carry a URL as their name or symbol. Some show enormous balances, often with absurdly long supplies designed to look impressive at a glance. A few are engineered so that trying to sell or transfer them triggers the malicious interaction directly.
This is a close cousin of address poisoning and dusting: unrequested value landing in your wallet as a delivery mechanism for something else.
Holding the token is not the danger
Here's the reassuring part, and it's worth being precise about.
A token sitting at your address cannot take anything from you. It can't move your other assets, can't sign on your behalf, and can't reach into your wallet. Receiving it required nothing from you, and doing nothing with it keeps you exactly as safe as you were.
The danger begins the moment you interact. Every theft in this category requires a signature from you — and the attacker's whole craft goes into making that signature feel routine.
So the first rule is simple: an unexpected token is information, not an invitation. You can ignore it indefinitely.
What the claim page actually asks you to sign
The page will ask you to "claim", "verify eligibility", or "connect to check your allocation". What it actually requests is usually one of three things.
A token approval. A transaction granting some contract the right to move a token you already hold — typically with an unlimited allowance. It's labelled as part of the claim, but it has nothing to do with receiving anything. Approvals are permissions that outlive the moment you grant them, and a drainer only needs one.
An off-chain signature. This is the more dangerous modern variant. Standards like EIP-2612 permits and Permit2 let you authorise token spending with a signed message rather than a transaction. No gas, nothing broadcast, nothing in your history — and the attacker can submit it later to move your tokens. People who've learned to be careful with transactions are often much less careful with "just a signature", because it doesn't feel like it costs anything.
A transaction that does more than it says. A "claim" call that also transfers assets out, bundled into one approval.
All three share a feature: the page describes a benefit to you while the actual payload describes a permission for them. That gap is what blind signing means, and airdrop claims are its most common real-world form.
What SSP shows you for a typed-data signature
Off-chain permits arrive as EIP-712 typed-data requests, so it's worth being specific about how SSP handles them — including where it falls short.
When a dApp requests a typed-data signature, SSP shows you the requesting site's name and URL, the address that would sign, the network, and a chain-switch warning if the request targets a different chain than the one you're on. Then it shows the full structured EIP-712 payload — every field, nothing hidden.
Signing it requires approval on SSP Wallet and then confirmation on SSP Key. Two devices, two deliberate steps. That genuinely protects you from a single compromised device producing a signature on its own.
Now the honest limitation. For typed data, SSP shows you the raw structured JSON rather than a plain-language summary. Our transaction decoder translates common ERC-20 calls into readable sentences — including flagging unlimited allowances — but typed-data permits are not decoded that way today. You get the complete truth, but you have to read it: look for a spender, a value or amount, and a deadline. If a "claim" is asking you to sign something containing a spender and a large value, it is not a claim. It's a permission.
And the two-device design has a boundary worth stating plainly. It defends against a compromised device, not against you being convinced. If you approve a malicious permit on both devices, it's validly signed. The second confirmation is a second chance to notice, not a guarantee that you will.
How to tell a real airdrop from a fake one
Real airdrops are announced, not delivered. Legitimate projects announce eligibility through their own established channels, well before any claim. A token that simply appears, promoting its own claim site, is almost always the scam.
Navigate, never click through. If you believe you're eligible for something real, go to the project's official site by typing it yourself or from a source you already trust. Never follow a link embedded in a token name, a DM, or a reply under a post.
A claim should not need your other assets. Receiving tokens doesn't require approving anything you already own. If a claim asks for an approval or a permit on a different token, stop.
Urgency is a tell. "Claim within 2 hours" exists to stop you thinking.
Check what's being signed, not what the page says. The page is written by whoever wants your signature. The payload is the only honest part.
If you've already signed something
Act quickly, because drainers often sweep assets within minutes.
Revoke the permission. For an on-chain approval, revoke it — this is exactly what revocation is for. Off-chain permits are harder: they aren't recorded on-chain until used, so the practical defence is to move the affected tokens to a fresh address before the signature is submitted.
Move what's still exposed. Anything the attacker could still reach should go somewhere they can't.
Don't interact further. "Recovery" sites and helpful strangers offering to reverse the theft are the second wave of the same operation.
The broader lesson is worth more than any checklist. In crypto, you almost never lose money by receiving something. You lose it by signing something. Free tokens are simply the most effective way anyone has found to get you to sign.
