Planning a crypto airdrop: rules, screening and what to say

What should the airdrop achieve?

Quick test: Explain the rules to a friend in 3 sentences. If they cannot say who qualifies, rewrite the rules.

An airdrop should serve a defined project objective, not simply distribute tokens for attention. Decide what action or relationship the distribution is meant to support, then make every campaign choice answerable to that objective.

Possible objectives include introducing a product to relevant users, rewarding prior participation, encouraging people to try a new feature, or recognizing contributors. These goals call for different eligibility rules. A reward for existing contributors should not be designed like an open campaign intended to invite new users.

Before drafting mechanics, write a short internal brief that states:

• The audience you want to reach and why they are relevant.
• The action, history or contribution that may qualify.
• What the project hopes to learn or support after distribution.
• Which team members approve rules, communications and the final allocation.

Choose measures that match the goal. For product discovery, track meaningful visits or completed product actions where your analytics and privacy approach allow it. For contributor recognition, document how contributions will be reviewed. A large participant count alone does not show that the campaign attracted useful users. If the token event sits within a wider launch, align the plan with your token launch checklist and agree how the airdrop will fit the overall schedule.

How to set eligibility rules

Eligibility rules define who can participate and how the project will decide whether each submission qualifies. Keep them specific enough to apply consistently, but simple enough for a participant to check before taking action.

Start by separating automatic criteria from criteria that need human review. A rule based on a stated activity or a defined time period may be easier to explain and verify than a subjective judgment. If you use multiple criteria, clarify whether participants must meet all of them or only some. Explain any location, account, wallet or participation restrictions that apply, without implying that a person is eligible until the review is complete.

Make the rules understandable

Write down the following before promotion begins:

• The qualifying action or contribution and how it is evidenced.
• The period in which that action must have taken place.
• Any exclusions, duplicate-entry policy or disqualification reasons.
• How and when participants can check their status or appeal an error.

Avoid changing criteria after people have acted. If a correction is essential, publish what changed, why it changed and which participants are affected. A clear policy also helps support teams give consistent answers. For a campaign that uses community tasks, compare the participation design with the principles in our quest planning guide; tasks should be relevant to the project rather than added only to increase submissions.

Screening for duplicate or coordinated entries

A useful anti-abuse plan combines proportionate checks with a clear review path. It should reduce duplicate or coordinated entries without treating every unusual participant as ineligible by default.

First, decide what evidence is appropriate for the campaign. Depending on the design, your team might review wallet activity, task completion records, account consistency or repeated submission patterns. A single signal can be misleading, so define how reviewers will combine evidence and when they should request clarification. Avoid collecting personal information that is not needed for eligibility.

Use a written review procedure so that similar cases receive similar treatment. Keep an internal record of the rule applied, evidence considered and decision made. Limit access to that record to team members who need it, and set a retention approach before collecting data.

The participant-facing explanation can be brief: say that entries may be reviewed, identify the kinds of criteria that matter, and explain how to ask for a correction. Do not publish a detailed detection recipe that would make it easier to evade the rules. For ongoing audience work beyond the distribution itself, consider whether a broader community growth plan is a better fit than adding more airdrop tasks.

Choosing a distribution method

The right distribution method is the one your team can explain, test and support for the chosen eligibility model. Compare the participant experience and operational workload before settling on a mechanism.

This is a planning comparison, not a recommendation for a particular contract. Your technical team should confirm that the selected mechanism matches the token, chain and security requirements. Test the participant journey from the announcement through the final confirmation, including what happens when someone uses the wrong wallet or cannot complete a step.

Model the allocation before launch. Set aside any amounts required for the campaign, check that the sum of planned allocations matches the approved distribution, and record who can authorize changes. Make sure communications do not imply that a participant must connect a wallet through an unsolicited message. If your launch includes other distribution or listing work, coordinate the schedule with the wider launch plan.

Your 7-point airdrop plan checklist

Tick off these 7 points before the announcement goes out. A plan that passes all 7 is easier to explain, easier to defend and easier to run.

• Write the outcome you want in one line.
• Publish eligibility and exclusion rules.
• Fix the snapshot date and the claim window.
• Choose direct send or claim, and say why.
• Plan screening for duplicate and coordinated entries.
• Share only official links, in channels you control.
• Prepare a 5-question FAQ and a security notice.

Terms in one line

Snapshot (in plain words: a record of balances or activity taken at a set moment).

Claim window means the period when eligible people can collect their tokens.

Before you announce

Common mistake: Changing rules after the announcement. Freeze them and publish the date of the snapshot.

Prepare the participant instructions, support process and campaign records before promotion begins. Participants should be able to understand the offer, check the rules and find an official route for questions without relying on informal posts.

Create one authoritative campaign page or notice that covers the objective, eligibility, exclusions, distribution method, relevant dates, claim steps and support channel. Use the same wording across community posts and partner materials. If the rules change, update the authoritative source first and make the change visible elsewhere.

Prepare a support response for common cases: a participant cannot find their status, believes an entry was counted incorrectly, has a wallet or claim issue, or encounters a message that may be impersonating the project. Give moderators a clear escalation route for technical or eligibility decisions. Never ask participants to share a recovery phrase or private key.

Before publication, have someone unfamiliar with the campaign read the instructions and explain the steps back to you. If they cannot tell who qualifies or where to get help, simplify the page. Your airdrop campaign management resource can help you map the work across communications, community support and distribution; keep ownership explicit so urgent questions do not sit unanswered.

Running the campaign and judging the outcome

Run the campaign against a shared schedule and keep a record of each decision that affects participant eligibility or distribution. A simple operating plan helps the project team, moderators and technical owners give consistent information.

A practical sequence is to approve rules and allocations, test the participant journey, publish the announcement, monitor questions and submissions, review eligibility, then complete distribution and follow-up. Assign one accountable owner for each stage. Keep a dated log of public updates, rule changes, support themes and distribution status so the team can resolve disputes using the same source of truth.

Measure outcomes against the objective you set at the start. Useful evidence may include whether eligible users completed the intended product action, whether contributors understood the decision process, or which campaign instructions generated repeated questions. Separate confirmed results from assumptions, and do not treat wallet count as proof of lasting participation.

After the claim or distribution window closes, publish a concise status update that explains what has been completed and where unresolved issues can be raised. Review what confused participants and what created unnecessary work for the team. Feed those observations into your next campaign rather than copying another project's mechanics without checking whether its audience and purpose match yours.

What can still go wrong after launch

A sound plan reduces avoidable confusion, but it cannot control every event after an announcement. On-chain transactions can be affected by network conditions and contract behavior, while eligibility decisions can be challenged when evidence is incomplete or rules are unclear.

For this reason, test the selected contract and claim path with your technical team before publication, document the criteria reviewers will apply, and prepare a clear support route for problems. State what the project controls: the published rules, review process, allocation records and campaign communications. Do not describe an estimate or a pending transaction as a completed distribution.

Keep campaign security in view throughout. Share official links through channels the project controls, monitor reports of impersonation, and remind participants that support should never request their recovery phrase or private key. If a contract, claim interface or eligibility process changes, pause promotion until the public instructions match the current process. This makes the campaign easier to verify and gives your team a practical response when something goes wrong.

How it works

1. Set the objectiveWrite down the audience, intended action and what the project needs to learn. Use these decisions to judge every later campaign choice.
2. Approve eligibilityDefine qualifying actions, exclusions, evidence and a review route. Make the participant-facing rules consistent with the process your team can actually apply.
3. Model the allocationChoose a distribution method, check planned allocations and assign approval responsibility. Have technical owners confirm the selected mechanism before promotion.
4. Prepare and testPublish clear instructions, brief community support and test the participant journey. Correct confusing steps before the campaign is announced.
5. Review and reportRecord eligibility decisions, complete distribution and publish a status update. Compare the outcome with the original objective and note improvements for next time.