In short: incentives buy activity, not community. Build for the people who stay when the payments stop, give them a job, and keep the record of who they are on channels you own.
Key points
- Plan an airdrop as an acquisition cost with an expected loss rate, not as a conversion.
- When X changed its API terms in early 2026, much pay-to-post machinery stopped working within days.
- Weight token allocation to repeated usage over time, and build sybil filters before the snapshot.
- Give holders real jobs: testing, curating, governing consequential decisions and vouching referrals.
- The only community metric worth trusting is retained usage measured after incentives stop.
Farmers sell, and that is fine
An airdrop farmer is a rational actor doing exactly what the programme paid for. They completed the task, claimed the reward, and sold it. Nothing in that sequence was a relationship.
The mistake is not that farmers exist. The mistake is counting them as users. The claim rate goes in the launch deck, the sell-through is never mentioned, and the team spends the next quarter wondering where everyone went.
Part 5 made the case that community is a job, not a number. In crypto, the number is unusually easy to inflate. So the job matters more, not less.
Plan the airdrop as an acquisition cost with an expected loss rate. Then design for the fraction who stay.
Quests, points and the platform you do not own
Quest platforms produce completion. A wallet connects, follows an account, retweets a post, joins a server. Every box is ticked and nobody has used the product.
Pay-to-post programmes were the same pattern with more money attached. When X changed its API terms in early 2026, a large part of that machinery stopped working within days. Teams that had built their whole engagement layer on it lost it in one policy change they had no vote on.
The lesson is platform dependency, not any one platform. Any channel you rent can be repriced or removed. Part 8 covers this for every vertical. In crypto, the dependency is usually deeper and the switch-off is usually faster.
Keep using the platforms. Just never let them hold the only copy of your community.
Earned allocation with filters that bite
If you are going to distribute tokens to users, distribute them for behaviour you want repeated. Not for showing up. For using the product in the way a long-term user would.
That means allocation weighted to usage over time, not usage in a single window. It means position size matters less than consistency. It means sybil filtering is a product feature, built before the snapshot, not a clean-up after.
Expect the filters to be contested. Publish the rules in advance, apply them without exception, and keep an appeals channel that a human reads. The people who argue in good faith are often the users you most want to keep.
Give holders a job
A holder with nothing to do is a seller waiting for a price. A holder with a job has a reason to stay that is not the chart.
The jobs that work are real work, not engagement theatre:
- Test new markets or features before they go live, with their feedback visible and acted on.
- Curate listings, parameters or content where judgement matters and you cannot automate it.
- Govern decisions that have consequences, not polls about logo colours.
- Refer people they are willing to vouch for, with their name on the referral.
Part 7 described the first ten customers as design partners. Holders with a job are the same idea at a hundred people. Treat their output as product input, and say so publicly when it ships.
The first hundred in crypto
Part 6 argued that the first hundred people are the whole company for a while. In crypto, the trap is picking them by wallet balance.
The first hundred you want are daily DeFi users. People who already move capital across protocols most days, understand the risks without being told, and will tell you plainly when something is wrong.
They are not the largest holders and often not holders at all. Find them in the places where they already work: governance forums, protocol support channels, the small group who read audit reports. Recruit them by hand. Give them direct access to the team.
A hundred of these people will produce more useful signal than ten thousand quest completions.
Measure retained usage when incentives stop
The only community metric I trust is retention measured after the money stops.
Define it before you start. Pick the action that means someone is using the product, not visiting it. Run incentives for a set period. Then stop, and count how many people keep doing that action in the following weeks.
That number is your community. Everything else is a cost of acquiring it.
Keep that record on channels and systems you own. A member list, a contribution log, an email address or a wallet you can reach without going through a third party. Part 9 said stop reporting reach. In crypto, start reporting who is still here.
The checklist
- [ ] Airdrop planned as an acquisition cost with an expected sell-through, not as a conversion
- [ ] Allocation rules weighted to repeated usage over time and published before the snapshot
- [ ] Sybil filters built and tested before launch, with a human-read appeals channel
- [ ] At least one real job defined for holders, with their output visibly shipped
- [ ] First hundred recruited by hand from daily DeFi users, not by wallet balance
- [ ] Retained usage measured after incentives stop, with the record held on owned channels
Common questions
How do you keep crypto users after an airdrop?
Design for the fraction who stay. Allocate for repeated usage over time, give holders a real job, and measure who keeps using the product after incentives stop.
Are airdrop farmers a problem?
Farmers are rational actors doing what the programme paid for. The mistake is counting them as users rather than planning the airdrop as an acquisition cost with an expected loss rate.
Who should a crypto project's first hundred community members be?
Daily DeFi users who already move capital across protocols, not the largest wallet holders. Recruit them by hand in governance forums and support channels and give them direct access to the team.
How should sybil filtering work for a token distribution?
Build it as a product feature before the snapshot, publish the rules in advance, apply them without exception, and keep an appeals channel that a human reads.