There's a general consensus that a big Discord member count means a healthy project, and it's a belief that's quietly bankrupting marketing budgets across Web3. You've watched it happen: the server hits 40,000 members the week the points program launches, the announcements channel lights up like a slot machine, and then the airdrop lands and the whole place goes silent within a fortnight. That isn't a community collapsing. It never was one. It was a queue, and the queue got what it came for.
What you had was attention, rented briefly at the price of a token distribution. A lot of crypto marketing teams reading this will already know the feeling of watching a number they were proud of turn out to be worth precisely nothing. This piece is about telling the difference before you spend another cent finding out the hard way, and about building a crypto community management model that measures contribution instead of counting heads. No moralising about farmers, no pretending every low-effort wallet is a criminal mastermind. Just a way to see who is actually there, and why.
Why “Community” Is an Overloaded Metric
"Community" gets used for seven entirely different things, and most projects only ever measure one of them: how many wallets are technically inside the server. That single number is doing the work of seven, and it's failing at all of them.
An audience reads your announcements and does nothing else. A wallet holds your token, which tells you about a balance, not a person. A holder has held it for more than a week, which is a slightly better signal and still not much of one. A user actually opens the product and does something with it.
A contributor costs the project their own effort in return, whether that's testing a broken feature, filing a real bug report, or translating documentation nobody asked them to translate. An ambassador brings other people in and stays around to see what happens to them. A farmer optimizes for exactly one outcome, which is qualifying for the next distribution, and once that's secured, there is no reason left for them to be there.
Every one of these seven can look identical on a member-count dashboard, and that's precisely the trap. A project with 3,000 farmers and a project with 300 contributors can both report "3,000-plus community members" and be describing two completely different businesses. The instinct from there is to sort everyone into two bins, real and fake — and that instinct is exactly what causes the trouble covered later in this piece. The useful move is simpler: stop treating "member" as one category and start treating it as seven, because the tactics that grow an audience will not grow a contributor base, and mistaking one for the other is how the money gets spent twice.
What Incentives Attract
Incentives are extremely good at generating one thing: volume. What they don't reliably generate is a reason for anyone to stay once the reward has cleared.
That's not an argument against running incentive programs. Points systems, quests and airdrop campaigns work exactly as designed, pulling in attention and testing at a scale organic growth rarely matches on its own. The trouble starts when a project mistakes that volume for demand for the product, rather than demand for the reward sitting on top of it.
zkSync's own on-chain activity tells this story with no interpretation required. Active addresses reportedly ran above 110,000 in July 2024 and had fallen to around 41,000 by December, an 85% collapse in the months following its token distribution. That figure doesn't prove the incentive program was a mistake. It proves that passing a Sybil filter and staying engaged are two completely separate achievements, and reporting them as the same thing is where the numbers stop meaning anything.
Build a Contribution-segmentation Model
The fix for an overloaded metric is a model that scores what people actually do, not which wallet they did it from. Think of it as a credit score for genuine effort rather than a passport check for humanity. Several categories cover most of what matters, and none of them require guessing at anyone's intent.
- Repeat product use — did the wallet interact with the product more than once, across more than one week, without a reward attached to the second action?
- Support contribution — did the person answer another user's question in a public channel, unprompted and correctly?
- Governance quality — did a vote or proposal comment show evidence of having read the proposal, rather than a one-line "yes" copied across twenty wallets?
- Content creation — did the person produce a thread, a video or a guide that another user engaged with independently of any bounty?
- Referral with retention — did a referred user still show product activity 30 days later, not just a signup?
- Developer or integration work — is there a public commit, plugin or integration that depends on the project's SDK or API?
Score these per wallet or per identity cluster, and a very different picture emerges from the one a member counter ever gave you. Most wallets will score zero across the board, and that's expected, not an accusation worth acting on. The wallets scoring on two or more categories are the actual community, whatever the headline number on the server sidebar says.
Avoid the Sybil-versus-human False Binary
The temptation, once a scoring model exists, is to bolt a punishment model onto it. That's where good community managers do genuine, lasting damage to the exact people they most need to keep.
Wallet-pattern detection is a useful signal. It is not proof of identity, and treating it as proof is how a project ends up banning its best future advocate for the crime of being new.
Arbitrum's own anti-Sybil rules illustrate how blunt this has to be at scale. The foundation's eligibility criteria deducted points from wallets whose transactions all fell within a 48-hour window, or that held under 0.005 ETH while touching only one contract. Those are reasonable heuristics for flagging risk, and they are also precisely the pattern a genuine new user creates in their first week on a chain: one wallet, one contract, a short burst of activity because that's all the onboarding tutorial covered.
That's why Arbitrum's documentation frames the process as graph-based "Sybil hunting" rather than a rule applied automatically and left to run. Even so, the eventual list still drew pushback. Independent analysis found that more than 279,328 same-person addresses and 148,595 flagged Sybil addresses collectively claimed over 253 million ARB, about 21.8% of the entire distribution, even after filtering.
LayerZero built an explicit appeal mechanism for exactly this reason. After its clustering process flagged 803,093 addresses as potential Sybils, it gave flagged wallets a route to self-report and still collect 15% of their intended allocation, rather than losing everything on an algorithm's word alone.
The working rule is simple to state and easy to skip under deadline pressure: flags trigger review, never automatic removal. A risk score sorts a wallet into a queue for a human to look at, not straight into a ban list. Punitive action without review is how a project turns its most active tester into its loudest public critic, and it does that in public, on the same channels it's trying to grow.
Design Post-airdrop Pathways
An airdrop that ends the moment the token lands in a wallet has done exactly half its job. The other half is giving someone a reason to open the app again on day two.
That reason has to be built into the structure, not requested in an announcement. Recognition tiers separate a one-time claimer from a repeat contributor in a way people can actually see. A visible next action matters too, whether that's a beta feature, a governance thread, or a bug bounty that existed before the token unlocked rather than one invented afterward as an afterthought. A feedback loop where a contributor's report visibly changes something matters most of all, because nothing kills a contributor's motivation faster than watching their bug report vanish into a support queue with no reply.
None of this needs new tooling most projects don't already have sitting unused somewhere. It needs a decision, made before the snapshot, about what a contributor is allowed to become afterward — and that path needs to live in the product itself, not in a pinned Discord message nobody reads twice. It's worth reading alongside our guide to Discord, Telegram, and X community marketing, since the same principle applies there: an event, or a campaign, only pays off if there's somewhere for the audience to go once it's over.
Report the Right Outcomes
Stop reporting member count as a headline metric. It's answering a question nobody serious is actually asking, and it's been doing that for years.
Report five things instead. Activation rate is the share of airdrop recipients who took a single product action afterward. Repeat-use rate at 30 and 90 days shows whether that action turned into a habit or stayed a one-off. Contribution rate is the share of the segmented base scoring on two or more of the categories described above. Support load shows how much of the team's time goes to genuine questions versus farming complaints and appeal tickets. Retention by cohort tracks farmers, testers, contributors and ambassadors as separate lines on the same chart, rather than one blended average that flatters everyone by hiding all of them.
| Metric | What it actually tells you |
| Member count | Almost nothing. Includes bots, alts, and one-time visitors |
| Activation rate | Whether the incentive produced a single real action |
| 30/90-day repeat use | Whether the product itself is the reason people stayed |
| Contribution rate | Share of the base doing something beyond claiming |
| Retention by cohort | Whether farmers, testers, and ambassadors behave differently |
Coinpresso doesn't have a published before-and-after dataset of our own showing these cohorts side by side yet. A project running this framework for two or three quarters would have exactly that data, and it would be worth more to a founder than any industry-wide farming percentage currently doing the rounds on Crypto Twitter.
Conclusion
A mercenary community isn't a failure of screening. It's usually a success of screening applied to the wrong question, sorting wallets into real and fake when the actual question is which ones are doing something worth keeping around.
Here's a worksheet version of the segmentation model, one you can run against your own server tonight:
- List every incentive-earning action from your last campaign
- Score each wallet or identity cluster on the contribution categories above
- Separate risk-flagged wallets into a review queue, not a ban list
- Set a 30-day and 90-day repeat-action check for every cohort
- Report contribution rate and cohort retention alongside member count, not instead of it
Incentives can create attention; systems create contribution. Ask Coinpresso to design a community measurement model beyond wallet and member counts, one that covers the operating structure, the moderation workflow and the reporting behind it, rather than handing you another dashboard that just counts heads.
The thing to check tonight: pull your last incentive campaign's wallet list and see how many addresses touched the product a second time without being paid to. If that number embarrasses you, this piece was written for your project specifically. Get in touch with Coinpresso when you're ready to talk through what a real segmentation model looks like for yours.
FAQs
Are airdrop farmers always bad for a project?
No. Incentive programs do what they're designed to do, which is pull in attention and testing at a scale organic growth rarely matches. The mistake is reading that volume as demand for the product rather than demand for the reward sitting on top of it, then budgeting as though the two are the same.
Is a token holder automatically a community member?
No. A wallet tells you about a balance, not a person, and holding for a week is a slightly better signal rather than a meaningful one. Community shows up as contribution: repeat product use with no reward attached, a question answered in public, a bug report that changes something.
How should a project measure real contribution?
Score what people actually do, per wallet or identity cluster, across a few categories: repeat product use, support answers given to other users, governance comments that show the proposal was read, content nobody was paid to make, referrals that are still active after 30 days, and developer work against your SDK. Most wallets score zero, which is expected. The ones scoring in two or more categories are your actual community.
Can an airdrop improve retention?
Only if there's somewhere to go on day two, decided before the snapshot rather than announced afterwards. Recognition tiers, a visible next action such as a beta feature or bug bounty, and a feedback loop where a contributor's report visibly changes the product. It has to live in the product, not in a pinned Discord message.
How can teams avoid calling legitimate users Sybils?
Treat wallet-pattern flags as a trigger for human review, never automatic removal. The patterns that mark risk, like a single wallet touching one contract in a short burst, are also exactly what a genuine new user looks like in their first week. See our case studies for how that review queue works in practice.
