How to Plan and Run a Crypto Airdrop Campaign

For project teams planning an airdrop: snapshot design, Sybil-resistance criteria, claim-page security, and legal/compliance issues that need real counsel.

Updated August 2026 · Reviewed by the PipeFlare team

Designing an airdrop campaign means deciding snapshot criteria, Sybil-resistance rules, claim-page security, and legal structure before any marketing begins

Snapshot and legal decisions are difficult or impossible to unwind once tokens have moved, which makes them first-order design constraints rather than a marketing afterthought

About how to market a crypto airdrop campaign

Designing an airdrop campaign as a project team is a different problem from claiming one: the core decisions are snapshot design, Sybil-resistance criteria, claim-page security, and legal exposure, not marketing copy. This page is written for teams planning their own token distribution, covering the mechanics real projects have published (Arbitrum's Sybil-detection methodology and Uniswap's snapshot design among them) and the areas where getting real legal counsel matters more than any marketing decision. It is general, factual information, not legal or business advice for a specific launch.

How it actually works

A snapshot is the single decision that defines who is eligible before any marketing happens, and it needs to be set (and, ideally, kept unannounced) well before the criteria and timing are public, since a known future snapshot date invites exactly the last-minute, minimal-activity wallet behavior that dilutes a distribution meant for genuine users. Sybil-resistance criteria are what separate a meaningful airdrop from one where value gets split thousands of ways among bot-created wallets; the Arbitrum Foundation's own published methodology is a useful public reference, penalizing wallets whose full transaction history sits inside a 48-hour window, and separately penalizing wallets under 0.005 ETH that touched only one smart contract, both patterns strongly associated with wallets created purely to farm a specific criterion rather than use the protocol. Arbitrum's methodology also cross-referenced an external list, disqualifying outright any wallet already flagged as a Sybil address through the separate Hop Protocol bounty program, a reminder that a new project doesn't have to build every detection signal from scratch when a prior, unrelated program has already done that work on an overlapping set of addresses. Claim-page security matters because a claim page is, by definition, a page that asks users to connect a wallet and sign a transaction, exactly the pattern drainer scams impersonate; a genuine project protects its users by using an audited, minimal-permission claim contract (never requesting a blanket approval like setApprovalForAll), publishing the exact contract address across every official channel before launch so it can be independently verified, and monitoring for phishing clones of the claim page from the moment eligibility becomes public. Legal and compliance considerations are the area where general guidance runs out fastest, because whether a distributed token is treated as a security, and what disclosure or registration obligations attach to distributing it, depends on the token's own structure and the jurisdictions the recipients are in; the SEC's ongoing enforcement actions against various token issuers, and the EU's MiCA framework for token issuers and service providers, are both live examples of regulators actively defining these lines rather than settled ones a general guide can summarize into a checklist. Any team planning a real distribution needs counsel who can assess the specific token and the specific jurisdictions involved, not a generic article.

Start here

1Decide snapshot criteria and timing before any public marketing begins, and keep the exact snapshot date unannounced until after it has already passed, to avoid inviting last-minute farming behavior.
2Build or adopt published Sybil-resistance criteria (Arbitrum's own methodology is a public, workable reference) rather than relying on a single simple threshold like 'used the protocol once,' which is trivially gamed.
3Use an audited claim contract with minimal permissions, never requesting a blanket token approval, and publish the exact contract address on every official channel before claims open so users can independently verify it.
4Monitor actively for phishing clones of your claim page from the moment eligibility becomes public; drainer scams specifically target real, imminent claim events because urgency and unfamiliarity both work in the scammer's favor.
5Get jurisdiction-specific legal counsel on the token's security status and any disclosure obligations before finalizing distribution mechanics, not after a snapshot has already been taken.

Strengths

A well-designed snapshot and Sybil-resistance model concentrates a distribution among genuine users, which strengthens a token's actual holder base rather than diluting it across bot wallets.
Published, public Sybil-detection methodologies (like Arbitrum's) mean a project doesn't have to invent this from scratch; adapting a proven public model saves real design time.
Publishing a verified claim contract address across every official channel before launch is a low-cost step that materially reduces successful phishing against a project's own users.

Common misunderstandings

Keeping snapshot timing unannounced is difficult once a project has any visible token trajectory, since community speculation about 'who qualifies' tends to start well before an official announcement.
No Sybil-resistance model catches every farming pattern; sophisticated farmers adapt to published criteria once they're public, which is part of why some criteria are only revealed after the fact.
The legal and compliance side has no general checklist that reliably applies across jurisdictions, and treating it as a marketing afterthought rather than a first-order design constraint is a common and costly mistake.

Common questions

What's the first decision a project should make when designing an airdrop?

The snapshot: which wallets, doing what, by what date, count as eligible. Every other decision, including Sybil-resistance criteria and claim-page design, follows from how the snapshot is defined, and it needs to be set before any part of the criteria becomes public.

How do successful projects prevent Sybil farming?

By building specific, published behavioral criteria rather than a single simple threshold. The Arbitrum Foundation's own methodology penalized wallets whose entire transaction history sat inside a 48-hour window, and wallets under 0.005 ETH that had touched only one smart contract, both patterns associated with bot-created wallets rather than genuine users.

Should we announce our snapshot date in advance?

Generally no. A known future snapshot date invites exactly the last-minute, minimal-activity wallet behavior that dilutes a distribution meant to reward genuine, sustained usage; most well-executed airdrops set criteria retroactively, after the snapshot has already passed.

What makes a claim page secure against phishing clones?

An audited, minimal-permission claim contract that never requests a blanket approval like setApprovalForAll, combined with publishing the exact, verified contract address across every official channel before claims open, so users have a reliable way to check a page against the real one.

Do we need legal counsel before running an airdrop?

Yes, specifically counsel familiar with the jurisdictions your recipients are in and the token's own structure, since whether a distributed token is treated as a security and what obligations attach to distributing it are live, actively enforced questions, not settled ones a general guide can answer for a specific project.

Is a crypto airdrop a marketing expense or a distribution decision?

It's fundamentally a distribution and, in many jurisdictions, a regulatory decision first; the marketing around an airdrop announcement is secondary to getting the snapshot, Sybil-resistance, and legal structure right, since those decisions are difficult or impossible to unwind after tokens have already moved.

What's the biggest mistake projects make when planning an airdrop?

Treating legal and Sybil-resistance design as an afterthought to be handled once marketing and community hype are already underway, rather than as first-order constraints decided before any snapshot criteria become public.

How large should a claim window be before unclaimed tokens are handled some other way?

Published examples vary by project, but a window measured in weeks to a few months, rather than days, gives recipients across time zones and levels of attentiveness a realistic chance to claim, while still letting a project eventually resolve what happens to unclaimed tokens instead of leaving them in limbo indefinitely. What happens to unclaimed tokens after the window, redistribution, burning, or return to treasury, should be decided and disclosed before the window opens, not improvised afterward.

Should snapshot and eligibility criteria be built in-house or handled by an outside firm?

Either can work, but the harder question either way is whether whoever builds it actually understands the specific farming patterns relevant to your protocol's own mechanics, rather than applying a generic checklist. A firm with a public track record and published methodology, the kind a project can point to and defend if the criteria are later challenged, is generally a stronger starting point than an undocumented in-house model no outside party can review or verify.

Sources

Ready to put this into practice?

Exchange sign-up bonuses pay both you and a referrer after a qualifying trade.

See bonuses →