Start with the moment your community is in
An airdrop plan should begin with the reason your community needs a distribution now. Choose one main outcome, such as recognizing useful contributions or helping people discover a product. That choice gives every later decision a reference point.
Picture a volunteer who runs a fan group between a testnet and a mainnet. They want to recognize members who gave thoughtful product feedback, not simply reward whoever found an announcement first. We’d help the team describe that contribution, decide what evidence shows it, and write down what participants should do afterward.
Before you discuss allocation sizes, make a short campaign note. Include the intended audience, the action you value, the person who approves the rules, and the evidence you can review. Add one measure that would show meaningful follow-through. A claim alone may confirm that someone received tokens, but it may not show whether they tried the product or stayed involved.
If the token launch has other public plans, check that the airdrop message fits them. The token launch checklist can help your team line up the timing and language. A clear purpose makes it easier to explain why these participants qualify and what the project hopes to learn.
What makes eligibility easy to understand?
Good eligibility rules tell people what counts, what does not, and how the team will handle questions. Use everyday language and give each rule a clear way to check it.
Write down the qualifying action, any relevant period or snapshot approach, the evidence that counts, and the route for correcting an error. Explain whether the campaign recognizes product use, community contributions, wallet activity, or a mix. If an action needs a record, say where participants should find it and what they should provide.
Then ask someone who did not write the rules to apply them to a few sample situations. Could two reviewers reach the same decision? Can a participant tell whether an action qualifies? Is there a clear owner for questions? If the answers differ, simplify the wording before publishing.
Be especially careful with rules involving more than one wallet or repeated activity. Describe how those cases will be reviewed instead of leaving the team to improvise later. Keep a copy of the published version, so support staff can refer to the same terms participants saw. Clear rules will not remove every question, but they give your team a fair place to start.
Build participation checks around the stated rules
Participation checks work best when they connect directly to the campaign’s purpose. Make the checks understandable, consistent and proportionate to the actions you invited people to take.
For a community contribution, define what makes an entry useful. For a product task, decide what evidence confirms completion. If entries look repeated or coordinated, route them for review rather than relying on one clue to decide eligibility. Tell participants what kinds of information you collect and how they can ask about a decision.
A short review guide can help everyone apply the rules in the same way. It should name the reviewer, list the evidence they can consider, and provide a way to record the reason for an exclusion. Keep a separate path for uncertain cases, so the person handling routine questions does not have to guess.
For example, say a campaign invites feedback about a test feature. We’d help define what counts as a specific product observation, then prepare a simple review note for unclear entries. That keeps the focus on the action the team values, rather than adding extra tasks for their own sake. If community participation is part of the plan, the Telegram community guide can help you prepare the place where questions and updates will appear.
Two delivery routes, two kinds of preparation
Choose a delivery route your team can explain and support. Direct distribution and participant claims ask for different preparation, so compare the work before announcing the campaign.
| Decision | Direct distribution | Participant claim |
|---|---|---|
| Participant action | No separate claim step | Follow the published claim instructions |
| Main preparation | Check recipient addresses and allocations | Test the claim path and support guidance |
| Common questions | Address and receipt details | Access, eligibility and claim steps |
| Useful when | The recipient list is settled | Participants need a self-service route |
Whichever route you choose, write down how allocations are calculated, how rounding works, and what happens to unclaimed tokens. Confirm who can approve a change to the recipient list or claim instructions. Keep the final allocation file and its version easy to identify.
Run an internal test before public instructions go live. Ask a reviewer to follow each step from the participant’s point of view. They should know which network and wallet are supported, where the current instructions live, and where to ask for help. A test can uncover a confusing label or a missing support detail while the team still has time to fix it. If your distribution sits alongside other campaign work, the airdrop management service explains the practical support available.
Carry the plan through three checkpoints
A short checkpoint sequence helps the team move from a useful idea to instructions participants can follow. Give each checkpoint an owner and keep a current copy of the decisions.
- Before drafting: Confirm the goal, audience, qualifying actions and person approving the rules. Collect the product or community details participants will need.
- Before the announcement: Review eligibility examples, confirm the allocation method, test the participant journey, and prepare answers for common questions. Put the rules on one stable page.
- After distribution: Record what was delivered, what participants did next, what support issues came up, and which questions remain open.
Leave time for a second person to read the rules without help from the author. If they have to infer what evidence counts, revise that part. If support staff cannot find the current page quickly, make the reference easier to locate.
Keep the announcement and the reference page consistent. When a correction is needed, explain what changed and update the current version. A small check-in during the first week can help the team notice unclear instructions early. It also gives one named person responsibility for routing eligibility questions and claim problems to the right colleague.
After delivery, look at what people did next
A useful review compares the campaign with its original purpose. Separate the record of token delivery from the actions the distribution was meant to encourage.
Choose a few measures your team can explain and verify. Depending on the goal, these might include completed claims, a relevant product action, repeat use, or thoughtful community contributions. Define what each measure means and where its information comes from before launch. Keep delivery records, eligibility decisions, support themes and corrections together, so you can answer questions later.
Blockchain transactions and network conditions affect when a transfer appears. An on-chain record cannot establish whether one wallet represents one person. We can help prepare clear rules and review steps. The team controls its own eligibility decisions. We cannot promise every participant will agree with them or see a transfer at a particular time.
Use the review to decide what deserves attention next. Perhaps the claim instructions need a clearer explanation, or the product needs better onboarding. Perhaps the community would benefit more from a conversation than another distribution. For more planning notes, visit the project marketing blog. To review your own plan with us, send Brand Community the campaign goal, draft rules, proposed delivery route and participant instructions. We’ll help you identify the next practical decision.
How it works
- Name the community outcomeWrite down the main reason for the distribution and the participant action that would show useful follow-through.
- Draft readable eligibilitySet out qualifying actions, evidence, exclusions and a route for questions or corrections.
- Select a delivery routeChoose direct distribution or claims, then record allocation logic and who can approve changes.
- Test the participant journeyAsk a reviewer to follow the rules and instructions from start to finish, then fix any guesswork.
- Review what happened nextCompare delivery and participant actions with the outcome you set before launch.
Frequently asked questions
What should I decide before announcing an airdrop?
Set the campaign goal, who should qualify, how allocations work and where participants can read the current rules. Also name the person who handles questions and the person who approves changes. For example, if product feedback is the goal, define what useful feedback looks like before inviting entries. That makes the announcement easier to write and the review easier to apply.
How can we make eligibility rules fair to participants?
Describe qualifying actions and evidence in terms participants can check for themselves. Ask a second reviewer to apply the rules to sample situations and compare their decisions. If they interpret a rule differently, clarify it before publishing. Include a simple way to ask about an apparent error, and keep the final public version available for the people answering questions.
How do I handle repeated or coordinated entries?
Explain what the campaign accepts, then give reviewers a consistent way to assess entries that appear repeated or coordinated. Keep a note of the evidence and the reason for a decision, and offer a route for participants to raise a concern. Avoid basing the whole decision on one wallet clue. The review should connect back to the activity described in the published eligibility rules.
Is direct distribution simpler than a claim page?
Neither route is simpler in every situation. Direct distribution puts more preparation into checking recipient addresses and allocations. A claim page adds participant instructions and questions about access. If the recipient list is settled, direct delivery may suit your process. If participants need to act themselves, test the claim journey and support route before choosing it.
What should an airdrop page tell participants?
Explain the purpose, eligibility, allocation method, delivery steps, supported wallet or network, support route and any relevant deadlines. Point social announcements to one current reference page. Add a clear reminder that project staff will not ask for private keys or recovery phrases. Before publishing, have someone follow the instructions without help and note any missing detail.
How do we know whether an airdrop worked?
Compare the campaign with the outcome you chose before launch. A delivery record can show completed transfers or claims; a relevant product action or thoughtful community contribution may show follow-through. Define the measures and their sources in advance. Keep delivery, participant activity and unresolved questions separate in your review. That lets the team see what it learned without overstating what the records show.
Tell us about your project
Answer four quick questions and a manager will send you a plan, timing and a price range within the hour. Everything stays confidential.
Loading the form…