How Protocols Detect Sybil Wallets: Methods and False Positives

How protocols detect sybil wallets is a question people usually ask after the recipient list is published and their address is not on it. Sybil detection before an airdrop is not a single filter but a set of methods: transaction graph analysis, behavioral heuristics, statistical models, farm-hunting programs and manual review. This article describes how those methods work from the protocol's side, what each of them can see, and why none of them works without errors.

This is an explanation of the general principles of Sybil detection, not a description of any specific project's rules. Every team uses its own methods and combination of them, and none publishes them in full. This material is not financial or legal advice and does not guarantee that a wallet will pass or fail a filter.

Why protocols need a Sybil filter

An airdrop distributes a limited pool of tokens. If one participant collects an allocation a hundred times through a hundred wallets, they take it away from a hundred real users. For the protocol this is not only unfair but also unprofitable: the tokens go to someone who will sell them on day one rather than to someone who will use the product and take part in governance.

The second reason is reputation. A distribution where most of the allocation went to farms devalues both the token and the community's trust. The third is data: filtering results feed the next seasons and programs, so teams have an interest in the model becoming more accurate.

Hence the general approach: the protocol does not try to prove that a specific person is behind a wallet. It estimates the probability that a group of wallets is controlled from one center and makes a decision about the group. What this looks like from the user's side, and which habits reduce the risk, is covered in the article on how to avoid a Sybil flag.

Transaction graph analysis

The main tool is a graph in which nodes are addresses and edges are transfers between them. The blockchain stores the full history, so the graph is built from all transactions up to the snapshot, and often after it as well.

What the graph is searched for first:

Shared funding sources. A group of addresses that received their first deposit from one address within a short window is a cluster candidate. A special case is bulk-send contracts that fund dozens of recipients in a single transaction.
Transfer chains. Address A funds B, B funds C. Passing leftover balances down a chain ties every link into one entity.
Shared counterparties. Several addresses regularly send funds to, or receive from, the same external address — for example, one exchange deposit address.
Consolidation. After the distribution, tokens from many addresses flow into one point. This is the most legible signal, and some projects analyze it after the distribution has already happened.

Technically this is a community detection problem: algorithms look for densely connected groups of nodes that are weakly connected to the rest of the network. The output is not «this wallet is Sybil» but «these N wallets most likely belong to one owner». Density and cluster size thresholds are specific to each protocol and are not disclosed.

Behavioral heuristics and models

The graph does not catch farms funded from different sources. For those, behavioral features are used — what an address does and when, regardless of whom it is connected to by transfers.

Typical heuristics:

Timing. A group of addresses performs the same actions seconds or minutes apart, in the same order, on the same days of the week or hours.
Identical routes. The same sequence of contracts and functions, similar amounts, the same number of transactions. Real users diverge quickly; a script never does.
Activity profile over time. The address was created shortly before the campaign, stayed active until the snapshot, then went silent. No «life» before or after the program.
Minimum thresholds. Activity tuned to rumors about the criteria: exactly that many transactions, exactly that volume, and nothing beyond.
Uniformity. A single protocol, no transfers to another person, no NFTs, no domains, no votes.

Individual heuristics are combined into a model. It can be a simple weighting system where each feature adds points to a suspicion score, or a trained classifier fed labeled examples of known farms and real users. In the second case the model finds feature combinations a person would not have described by hand, but explaining why a specific address received a high score becomes harder.

On top of the automation, most teams have a manual review: analysts look at borderline cases, large clusters and addresses with a large potential allocation. The manual stage is expensive, so it covers a small share of addresses, and its size determines how many of the automation's mistakes get corrected.

Hunter programs and community reports

A number of protocols supplement their own analysis with external input. Two formats are the most common.

Hunter programs. The protocol opens a submission channel: anyone can describe a cluster they found — a list of addresses and evidence of a link (shared funding source, identical routes, consolidation) — and receive a reward, usually a share of the allocation removed from confirmed farms. This attracts independent analysts who look for what the protocol's model missed. The downside is an incentive to submit weak reports in hope of a reward, so submissions are reviewed by the team.

Self-report windows. The protocol announces a period during which owners of multiple wallets can declare it themselves and, as a rule, keep one allocation instead of none. The logic for the project: some farms are removed at no analysis cost, and those who did not declare and were found later lose everything.

Community reports. Even without a formal program, teams receive signals from chats and social media: someone noticed a suspicious cluster or, conversely, considers their own exclusion a mistake. These signals are uneven and often emotional, so they are used as a trigger for review rather than as grounds for a decision.

It is important to understand that all three mechanisms operate after the snapshot — at the stage that corresponds to the Verification status in CoinDropster terms. How the snapshot itself works and what it includes is covered in the article on airdrop snapshots.

Why false positives happen

None of the methods described observes a person. All of them observe correlations, and correlation arises without a common owner too. Several typical sources of error:

Shared services. Exchanges use a limited pool of withdrawal addresses. Thousands of independent people receive their first deposit from the same hot wallet, and by the funding-source feature they are indistinguishable from a farm.
Public guides. When hundreds of thousands of people follow the same seven-step list, their routes are identical. A model trained on «identical routes = farm» will file honest participants under farm too.
Families and teams. Several people living together or working at the same company may fund each other's wallets. On the graph that is one cluster.
Noise in the data. Indexing errors, unindexed networks, aggregator contracts through which other people's funds pass — all of this creates edges that do not exist in reality.
The error trade-off. Any filter is tuned between «let a farm through» and «exclude an honest user». A protocol that wants to remove almost all farms will inevitably hit some real users — and vice versa.

There is also a blind spot in the other direction: the filter does not see off-chain links. Wallets funded from different sources, acting at different times along different routes, but controlled by one person look independent to the model. That is exactly why protocols add hunter programs and manual review — automation does not close the task on its own.

For the user, two conclusions follow. First: an exclusion is the result of a probability estimate, not an established fact, and it can be wrong. Second: most protocols have a review procedure, and it is worth using if you have something to show. How it usually works and what to prepare is covered in the article on what to do if your wallet is flagged as Sybil. The Verification stage, where filtering and appeals happen, is tracked on CoinDropster as a separate status for every project. See tracked airdrops →