Sybil Filtering for Crypto Marketing Campaigns: Keeping Bots Out of Quests, Waitlists and Airdrops

The campaign report looked great. Tens of thousands of quest completions, a waitlist that doubled inside a week, a Discord busy enough that the team brought in extra moderators just to keep up with it. Then the token went live, and hardly anyone on that list touched the product a second time.

We’ve watched this happen to more than one team. The creative was fine. The campaign paid out for actions a script can perform, so scripts performed them, at volume, for as long as the rewards lasted.

Most people file sybil filtering under airdrops, as a job for the protocol team in the week before claims open. I’d argue that’s far too late. By then the fake wallets have sat inside every growth number the marketing team reported for the past six months (quest completions, waitlist size, community headcount), and budgets were set on those numbers.

There’s less money to go round, too. CoinLaw’s tally puts 2025 airdrops at about $4.5 billion, a fraction of what was handed out the year before. When the pool is smaller, an allocation lost to a farm costs more. So does a user you excluded by mistake.

What follows is the set of filters that work at each stage of a campaign, along with the false positives each one produces. That second part is the one teams skip.

Where sybils get into a marketing campaign

Sybils show up wherever a reward is attached to an action that costs less to fake than the reward is worth. For a marketing team that means quests, waitlists and the airdrop itself. They leak in different ways, so one filter won’t cover all of them.

Quests

Quest platforms pay points for follows, reposts, Discord joins and small on-chain actions, and a script can do any of those for a few cents.

The mistake I see most often is judging the campaign by completions, which happens to be the one number a farm can produce without limit. Ask something else. Of the people who completed, how many did anything unprompted over the next 30 days?

Waitlists

A referral waitlist is the softest target of the lot. The attacker needs email addresses and nothing else. You’ll recognise the shape when you see it: one referrer, several hundred referees, and not a single opened email among them.

For a sense of the baseline, Imperva’s 2026 Bad Bot Report puts automated traffic at a little over half of everything on the web. An unprotected signup form gets its share of that.

Airdrops

The payout is biggest here, so the operators are the most professional. In the aPriori airdrop, Bubblemaps traced about 14,000 connected wallets back to one entity, which walked off with most of the distribution.

Nobody builds a farm that size in the final week. It was there through the testnet, the points season and every quest campaign along the way, padding the numbers each time.

Heuristic sybil filtering, rule by rule

A heuristic is a rule about one wallet or one account: a signal, a threshold, a decision. Heuristics cost almost nothing to run, and they clear out the lazy farms. Each one also misfires on a particular group of honest users, and you should know which group before you turn the rule on.

On chain, four rules do most of the work.

• Dropping wallets created just before the campaign, with nothing in them except the qualifying actions, removes a lot of farms. It also removes every newcomer the campaign was supposed to bring in.

• Arbitrum’s airdrop took a point off wallets whose entire history fit inside a 48-hour window. I like this rule, because a person who tries a product and finds it useful comes back and a script usually doesn’t. The people it wrongly catches are those who tried the product once, in good faith, and moved on.

• A minimum balance or gas-spent threshold works because farms keep their wallets nearly empty. It is unfair to users in lower-income markets, and close to meaningless on chains where a transaction costs a fraction of a cent.

• Many wallets bridging the same amount within minutes of each other is rarely chance. But tutorials often recommend an exact amount, so one popular guide can make a crowd of strangers look coordinated.

Off chain, for waitlists and quest entry, the list is similar in spirit.

• Collapse Gmail dot and plus variants into one identity, and block disposable domains. Be careful with privacy relay addresses; cautious users pick those on purpose.

• Datacenter IP ranges, or dozens of signups from one address, are strong signals. VPN use is heavy among crypto audiences, though, and offices and universities share addresses.

• Account age, follower count and a default avatar say something about a social account. They also describe lurkers, who are often the most serious buyers you have.

• A referral tree with one referrer and hundreds of silent referees looks farmed. On day one, so does a creator with a large audience.

My view is that no heuristic should disqualify anyone by itself. Score with them, and act when several point the same way. A rule that wipes out a big slice of the list feels like progress; most of the time it has taken the newcomers out with the bots.

Clustering: what the graph catches that rules miss

A heuristic examines one wallet. Clustering examines how wallets relate to each other, which is how it finds farms whose wallets each look ordinary: what gives them away is that they were funded together or behave alike. It is also the source of the expensive mistakes, since a single bad edge in the graph can condemn a whole group of people.

Funding graphs

Make each wallet a node and each wallet’s first inbound transfer an edge. Farms tend to appear in the two shapes Wormhole described when it published its method: a hub that funds many wallets directly, and a chain in which each wallet funds the next one.

The large connected components then get split by a community detection algorithm. Arbitrum and Wormhole have both said they used Louvain.

import networkx as nx# edges: (funder, funded) for each wallet's first inbound transferG = nx.DiGraph()G.add_edges_from(first_funding_edges)# remove known shared infrastructure before clusteringG.remove_nodes_from(labelled_exchanges | labelled_bridges | labelled_payout_tools)communities = nx.community.louvain_communities(G.to_undirected(), seed=1)suspect = [c for c in communities if len(c) >= MIN_CLUSTER_SIZE]

Pay more attention to the line that strips labelled infrastructure than to the choice of algorithm. Leave it out and an exchange hot wallet becomes the hub of the biggest «farm» in your data, with most of your customers inside it.

Behavioural similarity

Better-run farms fund every wallet separately from an exchange, and the funding graph sees nothing. What they struggle to hide is that one script is driving all of them.

So compare the sequence of actions and the gaps between them, wallet against wallet, then build a similarity matrix and cluster on that. Wallets calling the same contracts in the same order at the same intervals end up in one group.

Marketing campaigns set a trap here. A quest tells every participant to perform identical steps in an identical order, which means similarity run on quest actions turns your honest users into one giant farm. Run it on what the wallets did outside the quest.

Where clustering goes wrong

Four situations account for most wrongful exclusions.

1. Payroll tools, hackathon prize payouts, DAO multisigs and gas sponsorship services all fund many unrelated people from one address.

2. Someone onboards four relatives and pays for their first transactions, which draws a small star cluster made entirely of humans.

3. A legitimate user receives a single transfer (sometimes just dust) from a farm wallet and inherits the cluster’s label.

4. A minimum cluster size set too low turns every household into a farm.

Nansen wrote that its sybil work on the Linea airdrop was built to favour precision over recall, and I’d take that as the default for any team. It didn’t make the filter gentle. Linea still cut roughly 800,000 wallets, more than the number that went on to claim.

What each sybil filtering method costs in false positives

None of these methods is free. Compare them on two things: which honest users each one tends to exclude, and how much work a farm has to do to slip past it.

The methods in the lower rows are the hardest to evade, and they need the most data and the most care. Save them for the snapshot, where the stakes pay for the effort.

Design the campaign so the filter has less to do

The cheapest sybil defence is a campaign that isn’t worth farming. Anything you filter afterwards is damage control; how many fake participants turn up at all is decided by the reward structure.

A handful of changes do most of the work.

• Reward actions that cost something. Holding a position for weeks, providing liquidity or coming back to use the product ties up a farm’s capital in every wallet, where a repost costs it nothing.

• Scale rewards with depth, so that splitting funds across a thousand wallets earns less than one person concentrating in a single wallet.

• Delay or vest the reward. Farms want out quickly, and a payout that unlocks over months or needs a later action changes their maths.

• Keep the criteria vague until the snapshot, then publish the exact rules afterwards. Exact rules published early are a specification for the script.

Founders often treat reach and quality as one goal. They pull in opposite directions, and a campaign built to maximise the dashboard number will attract farms; the marketing team and the data team tend to discover this separately, months apart.

Teams with nobody to own both sides often have a crypto marketing agency like Blockchain App Factory plan the quest and waitlist mechanics, so the reward rules and the sybil filter are designed together.

Where you can, reduce a suspected sybil’s allocation in place of zeroing it. A wallet with a middling score gets less, and a person caught by mistake still walks away with something.

Setting thresholds without punishing users

Decide which error you can live with first, then test the filter on wallets you already know. Every sybil filter trades missed farms against excluded users, and where to set that trade depends on what the campaign is for: a community airdrop can tolerate a few farms far better than it can tolerate angry early supporters.

This is the order I’d do it in.

1. Build a labelled sample before anything else: a few hundred wallets you know belong to people (team, long-standing community members, verified contributors) and a set you know are farmed. Every rule runs against both before it touches the full list.

2. Measure what each rule does to the known-good sample. If it flags more than a handful of them, it’s too blunt to ban on. Keep it as a score input or drop it.

3. Require agreement. Disqualify only where a cluster signal and one independent signal both fire, since single-signal exclusions are behind most public complaints.

4. Have a person look at the biggest clusters. They hold the most allocation, and they’re where an unlabelled exchange or payout tool is likeliest to be hiding.

5. Open an appeal window with an evidence standard. Farm operators will flood it with claims of innocence, so ask for something that can’t be mass-produced, such as a signed message from a linked wallet with years of history.

6. Publish the method once distribution is done. Describe the signals and the reasoning but hold back exact thresholds. People take exclusion better when they can see it wasn’t arbitrary.

A waitlist needs a lighter version. Flag suspicious signups and leave them in the database, keep them off the referral leaderboard, and let anyone clear the flag by doing one thing that takes effort.

Start with last quarter’s campaign

Before you design anything new, pull the participant list from your most recent quest or waitlist and run two checks. First, with exchanges removed, count the wallets that share a first funder. Second, count the participants who did anything at all in the 30 days after the reward landed.

Between them, those two counts show how much of the growth you reported was people. They’ll also tell you how strict the next campaign has to be, and that’s a better guide than a threshold borrowed from somebody else’s airdrop.

FAQ

What is sybil filtering in a crypto campaign? It means finding the accounts and wallets that one operator controls while pretending to be many users, then removing them or cutting their rewards. Quests, waitlists and referral programs need it as much as token airdrops do.

How do projects detect sybil wallets? Most combine single-wallet rules (wallet age, activity window, balance) with clustering that groups wallets by shared funding source or near-identical behaviour. Someone then reviews the large clusters before anyone is excluded.

Why do genuine users get flagged as sybils? Usually because they share a funding source with strangers: an exchange withdrawal address, a payroll tool, a friend’s wallet. Following the same guide as thousands of other people does it too. The largest errors come from exchanges and bridges that nobody labelled.

Should you filter sybils before or after a campaign? Both. Light checks at entry keep scripted signups out of quests and waitlists; the heavier clustering runs at the snapshot. And the reward design you choose before launch decides how much either filter has to catch.