crypto-seo

Data-driven growth for Web3 projects.

Growth & Community Building·August 11, 2026·21 min read

Crypto airdrop farming: how to identify sybil wallets

Airdrop farming becomes a Sybil problem when one participant creates or controls multiple wallets to appear as many independent users.

Crypto airdrop farming: how to identify sybil wallets

Crypto Airdrop Farming: Advanced Sybil Detection Methods

The economic effect is direct: the protocol allocates rewards by address, while the operator captures several allocations with one underlying behavior pattern.

The scale is measurable. During LayerZero’s June 2024 ZRO distribution, approximately 2.08 million wallets were assessed. The protocol filtered out 803,093 wallets as Sybils and left roughly 1.28 million qualified wallets. Arbitrum’s March 2023 distribution produced a different result. An external analysis identified more than 148,595 Sybil addresses and 279,328 addresses linked to the same person that collectively claimed about 253 million ARB, or 21.8% of the distribution.

These cases establish the baseline. Airdrop Sybil detection is not a single-wallet inspection task. It is a graph analysis problem combined with funding-source tracing, temporal analysis, and behavioral clustering.

The anatomy of a Sybil attack on-chain

A Sybil wallet does not need to be technically sophisticated. It needs to look independent from the other wallets participating in the campaign. That distinction determines the detection method.

A protocol rarely identifies a wallet because it interacted with one decentralized application or because it claimed a small reward. Those signals have low attribution value in isolation. The stronger evidence appears when multiple wallets share transaction structure, funding paths, timing, and subsequent actions.

On-chain analysis represents wallets and transfers as a graph:

  • wallets function as nodes;
  • transfers function as directed edges;
  • transaction values, timestamps, assets, and counterparties add attributes to each edge;
  • contract interactions form a second layer of behavioral data.

This graph exposes patterns that are difficult to observe from individual wallet histories.

Star-shaped funding patterns

The simplest structure is a star. One source wallet sends funds to many recipient wallets. Those recipients then perform similar actions, often within a compressed time window.

The source may be:

  • a centralized exchange withdrawal wallet;
  • a decentralized exchange account;
  • a bridge contract;
  • a treasury-controlled wallet;
  • an intermediary wallet used to obscure the original source.

The source does not need to be directly connected to every final participant. A single intermediary layer can create a tree structure, with one wallet funding several wallets that fund further addresses.

A protocol can score this pattern using several variables:

1. Number of recipient wallets funded by the same source.

2. Time interval between the transfers.

3. Similarity in transferred amounts.

4. Time between funding and the first campaign-related transaction.

5. Overlap in contracts, tokens, and transaction sequences.

6. Whether the funded wallets return unused assets to one destination.

No single value proves control by one entity. The combination increases attribution.

Converging transfers

The inverse pattern is convergence. Multiple wallets send assets to the same target after completing campaign tasks. This can be a consolidation wallet, a bridge deposit address, a liquidity position, or a centralized exchange deposit path.

Convergence is not automatically malicious. Independent users may use the same exchange or bridge. The signal becomes stronger when the wallets also share:

  • identical or near-identical transaction timing;
  • the same initial funding source;
  • matching gas behavior;
  • repeated interaction sequences;
  • similar balances before and after each action.

The analytical question is not whether wallets touched the same address. It is whether their complete paths are more similar than would be expected from unrelated users.

Tree and chain structures

Tree structures are common when an operator distributes funds through several layers. The original source funds a group of intermediary wallets. Those wallets then fund the final campaign wallets. This creates separation in the graph without removing the underlying relationship.

Chain structures use sequential transfers:

Wallet A funds Wallet B, Wallet B funds Wallet C, and so on. The final addresses may appear unrelated to the original source when examined only through direct counterparties. A graph traversal across multiple hops restores the connection.

The number of hops affects both detection quality and latency. One-hop analysis is fast but incomplete. Multi-hop analysis creates better attribution but increases the volume of possible relationships. It also produces more false positives when common infrastructure is involved.

A Sybil cluster is defined by repeated relationships across several variables, not by wallet count alone.

Why transaction timing has high attribution value

Timing is one of the most useful features in preventing airdrop farming because campaign operators often automate wallet activity. Independent users do not behave identically, even when they follow the same public instructions. They act at different times, use different amounts, and stop at different points.

A coordinated cluster often shows compressed latency:

  • funding occurs within minutes or hours;
  • the first contract interaction follows shortly after funding;
  • the same sequence is repeated across many wallets;
  • transactions occur in a consistent order;
  • balances are reduced or consolidated after the task is complete.

The relevant measure is not simply whether two wallets transacted on the same day. Daily overlap has limited resolution. Detection systems can examine the distribution of time differences between events.

For example, a protocol might compare:

  • the latency between funding and the first interaction;
  • the latency between two required contract calls;
  • the time from the final task to token transfer or withdrawal;
  • the interval between transactions across wallets in the same suspected cluster.

Repeated low-latency sequences increase the probability of coordination. A large number of wallets performing the same actions within a narrow interval is a different pattern from a large number of users completing the same task over several weeks.

Arbitrum used a simple temporal rule in its 2023 eligibility logic. Wallets lost points when all their transactions occurred within 48 hours. That rule was not a complete Sybil classifier, but it reflected a practical baseline: wallets created or activated only for a short campaign window carry less evidence of independent, durable usage.

The limitation is clear. A genuine user can be active for only one or two days. A sophisticated operator can also distribute activity over a longer period. Timing therefore works best as a feature in a broader scoring model.

Tracing the money back to the source

Funding-source analysis is central to how protocols identify Sybil wallets. The transaction history of the final wallet may look diverse, but the asset flow that created its initial balance often reveals a common origin.

A detection pipeline can start with the first meaningful funding event and then trace backward through:

1. direct transfers from known wallets;

2. bridge deposits and withdrawals;

3. decentralized exchange swaps;

4. centralized exchange withdrawal clusters;

5. intermediary wallets;

6. stablecoin and native-token movements across chains.

The objective is not to identify the real-world person behind an address. Public on-chain data usually cannot establish that conclusion. The objective is to determine whether multiple addresses share a common operational source.

Chaos Labs’ methodology for LayerZero focused on this relationship. Wallets were evaluated for shared funding sources within a 24-hour window and for similar behavior afterward. This combines origin and consequence. A shared source alone may describe a service provider or exchange. A shared source followed by matching interaction patterns is more probative.

Funding-source features

A practical model can assign features to each wallet cluster:

FeatureLow-signal interpretationHigher-signal interpretation
Common sourceSame exchange or bridge used by unrelated usersSame source wallet funds many addresses directly
Funding intervalTransfers spread across weeksTransfers grouped within minutes or a few hours
Transfer amountDifferent values and irregular balancesRepeated or algorithmically similar amounts
First-use latencyWallet becomes active after an unpredictable delayWallet interacts with the target protocol almost immediately
Asset pathSeveral unrelated assets and applicationsSame asset, same route, same contract sequence
Exit behaviorFunds remain in varied destinationsBalances converge on one wallet or route
Cross-chain activityIndependent bridge useMatching bridge deposits and withdrawals across wallets

The distinction between low and high signal matters because common infrastructure creates unavoidable overlap. Many legitimate users withdraw from the same exchange hot wallet. Many use the same canonical bridge. A detection system that treats every shared counterparty as proof of a Sybil relationship will produce a high false-positive rate.

Funding is not the whole identity

Operators can reduce the visibility of direct funding links by using multiple sources, batching transfers, or routing assets through bridges. This increases analytical latency but does not eliminate attribution. The graph can be expanded to include value equivalence, temporal correlation, and downstream behavior.

A protocol should also distinguish operational funding from ordinary usage. A wallet receiving a small amount of gas from a common faucet is not equivalent to receiving a complete task budget from a source that funds 500 addresses in the same sequence.

The value of the funding transaction matters, but less than its relationship to the next actions. A small transfer followed by identical automated behavior across a cluster can be more informative than a large transfer used for unrelated activity.

Behavioral clustering separates users from wallets

Address-level rules are easy to explain but easy to evade. Behavioral clustering examines what wallets do after they receive funds.

Trusta Labs’ open-source framework illustrates this two-stage approach. First, community detection algorithms such as Louvain and K-Core can identify connected structures in asset-transfer graphs. These methods locate groups with unusually dense or repetitive relationships. Second, K-means clustering can compare behavioral profiles and reduce false positives among wallets that are structurally connected for legitimate reasons.

A behavioral profile may include:

  • number of active days;
  • number of contracts called;
  • unique protocols used;
  • transaction count;
  • transaction-value distribution;
  • gas-price behavior;
  • sequence of contract calls;
  • bridge and exchange activity;
  • asset diversity;
  • balance retention;
  • interaction spacing;
  • activity before and after the campaign.

The model does not need to identify a wallet as “real” or “fake” from one feature. It can calculate similarity across the complete profile.

Common behavioral signatures of airdrop farming

A cluster is more suspicious when it exhibits several of the following patterns:

  • wallets are funded shortly before the first eligible action;
  • the same contracts are called in the same order;
  • transaction values differ only by small, regular amounts;
  • activity occurs on the same block or in narrow block intervals;
  • wallets use the minimum interaction required by the campaign;
  • wallets stop activity immediately after the eligibility window;
  • assets are consolidated after completion;
  • the wallets have little or no unrelated history;
  • the same cross-chain route is repeated across all addresses.

This does not mean that every short-lived wallet is a Sybil. Some campaigns specifically attract new users who have no previous history. A fair system must account for that baseline. The question is whether a wallet’s behavior is consistent with the campaign’s intended user profile or with a coordinated execution script.

Contract diversity and minimum viable participation

Airdrop farming often optimizes for eligibility rather than usage. Operators identify the least expensive path through the rules and repeat it across addresses.

That creates a measurable difference between broad participation and minimum viable participation. Legitimate users may still complete only the required tasks, but their transaction values, timing, and surrounding activity usually vary. A farm tends to produce a narrow distribution.

Arbitrum’s rules included a penalty for wallets with a balance below 0.005 ETH that had interacted with only one smart contract. The rule was a proxy for economic depth and behavioral diversity. It did not prove that a wallet was controlled by a farmer. It reduced the score of addresses with limited evidence of independent activity.

This approach has a known trade-off. Low-capital users may resemble Sybil wallets because they interact with only one protocol and maintain a small balance. The model therefore requires calibration against the project’s real user base. A rule imported from another ecosystem may have different error characteristics.

Lessons from Arbitrum’s loopholes

Arbitrum’s March 2023 distribution demonstrates the cost of incomplete attribution. According to an analysis by X-explore, more than 148,595 Sybil addresses and 279,328 same-person addresses bypassed the available filters and claimed approximately 253 million ARB.

The figure is material because the allocation was not merely distributed among more wallets than expected. It changed the ownership structure of the token distribution. A user acquisition campaign can report a large wallet count while still reaching a much smaller number of underlying participants.

Several weaknesses can create this result:

  • rules evaluate wallets independently rather than as a graph;
  • eligibility is based on a small set of transactions;
  • temporal compression is not penalized;
  • shared funding sources are ignored;
  • one-person multi-wallet relationships are treated as independent demand;
  • contract interaction thresholds are too easy to satisfy;
  • post-claim consolidation is not part of the attribution model.

Arbitrum’s 48-hour and 0.005 ETH rules show how a protocol can add behavioral friction to a simple eligibility formula. But isolated heuristics have limited coverage. They can be bypassed by spreading transactions, increasing balances, or interacting with additional contracts.

The broader lesson is that Sybil attack prevention in Web3 must be designed before the campaign begins. Retrospective filtering is possible, but it creates governance pressure, delayed claims, and disputes about false positives.

A reliable system defines the evidence model in advance:

1. what behavior qualifies as meaningful usage;

2. which relationships create a cluster;

3. how the protocol handles ambiguous wallets;

4. whether rewards are removed, reduced, or held for review;

5. how users can challenge a decision;

6. how the model will measure false positives after distribution.

Without these definitions, a project tends to improvise at the point of maximum community attention.

LayerZero and the value of staged filtering

LayerZero used a multi-phase anti-Sybil campaign before its ZRO distribution. The first phase offered users an opportunity to self-report Sybil activity. Participants who self-reported retained 15% of the relevant allocation. The second phase introduced community bounty reporting, with successful reporters receiving 10% of the disqualified Sybil allocation.

This structure created two information channels. The protocol’s own analysis provided the initial detection layer. Community participants then supplied additional evidence about wallet clusters and operational behavior.

The value of community reporting is practical. Users may recognize address relationships that are difficult to infer from public graph data alone. They may identify repeated campaign behavior, operator patterns, or wallet lists shared in private channels.

The cost is also practical. A bounty can encourage low-quality reports, strategic disputes, and accusations based on weak evidence. It can create friction between participants and shift a technical classification problem into a social conflict. A report should therefore require reproducible evidence, not a narrative assertion.

A controlled reporting system can define an evidence threshold:

  • the reported addresses must form a connected funding or behavior cluster;
  • the reporter must document the relevant transactions;
  • the relationship must include more than a shared exchange or bridge;
  • the report must identify the timing or behavioral pattern;
  • the protocol must review the evidence independently;
  • the reporter’s reward must depend on a confirmed result.

Community input is an extension of the detection system. It is not a substitute for one.

Beyond the ban: weighted Sybil scoring

Blanket exclusion is not the only response. A binary model assigns one of two outcomes: eligible or disqualified. That is simple to communicate but can be unstable near the decision boundary.

Hyperlane’s 2025 HYPER distribution used a weighted Sybil score from 0.0 to 1.0. Wallets with a score of 1.0 were fully excluded. Wallets below 1.0 received a negative multiplier calculated as:

Reward multiplier = 1 - Sybil score

This approach reduces the reward in proportion to the detected risk. It recognizes that evidence can have different strengths. A wallet with a high-confidence relationship to a coordinated cluster can be excluded, while an address with partial overlap can receive a reduced allocation.

Hyperlane also applied a fee threshold: wallets generating less than $5 in fees were fully excluded. The threshold functioned as a proxy for economic participation. It was not a complete identity mechanism, but it helped distinguish low-cost scripted activity from usage that generated measurable protocol fees.

Weighted scoring has three operational advantages:

  • it reduces the impact of borderline classifications;
  • it makes multiple signals easier to combine;
  • it lowers the incentive to optimize around one hard cutoff.

It also creates a communication challenge. Users need to understand why their reward was reduced. A score without an explanation can appear arbitrary, even when the underlying model is sound.

A project can expose evidence categories without publishing exploitable thresholds. For example, it may state that a reduction was associated with common funding, compressed timing, and repetitive contract behavior. It does not need to disclose every model weight or every graph query.

How to stop airdrop bots without relying on one rule

The phrase “how to stop airdrop bots” suggests a single countermeasure. The mechanics do not support that assumption. Automated wallets can imitate almost any isolated rule. Detection improves when the campaign requires a portfolio of actions with different costs and time profiles.

A stronger campaign design can combine:

1. Time dispersion. Eligibility should not depend on a short activity window. A 48-hour burst provides weak evidence of durable use.

2. Economic depth. Requirements should measure more than a single transaction. Balance, fees, liquidity duration, or retained positions can add signal.

3. Behavioral diversity. Several contract interactions should represent distinct user actions rather than repeated low-value calls.

4. Cross-session attribution. The protocol should compare activity before, during, and after the campaign.

5. Graph analysis. Funding and consolidation paths should be evaluated across multiple hops.

6. Delayed finalization. A delay between eligibility calculation and reward distribution allows additional graph relationships to emerge.

7. Risk-weighted rewards. Ambiguous clusters can receive reduced allocations instead of automatic exclusion.

8. Post-distribution monitoring. Consolidation, immediate selling, or coordinated movement after the claim can inform later campaigns.

These measures introduce latency. They also increase analytical cost and may reduce participation from users who prefer simple tasks. The correct design depends on the project’s objective. If the objective is unique-user acquisition, address count is a weak metric. If the objective is liquidity, a high wallet count without retained capital has limited value. If the objective is governance, delegated or coordinated wallets can distort representation.

The detection model must therefore be connected to the growth metric. Otherwise, the protocol may optimize for a clean Sybil report while measuring the wrong outcome.

Measuring detection quality

A Sybil filter should be evaluated like any other growth system. The relevant question is not whether it removed many wallets. The relevant question is whether the remaining distribution better represents the intended user population.

Useful measurements include:

  • qualified wallets per underlying participant, where estimation is possible;
  • share of rewards later consolidated into common destinations;
  • percentage of eligible wallets with activity before the campaign;
  • seven-, 30-, and 90-day retention after the airdrop;
  • median transaction count after claiming;
  • post-claim liquidity retention;
  • cost per retained user rather than cost per eligible address;
  • proportion of rewards assigned to flagged clusters;
  • appeal rate and confirmed false-positive rate;
  • detection latency between campaign activity and final classification.

The last two measures are often omitted. A filter that removes 40% of wallets but creates a substantial false-positive rate may damage more value than it protects. A filter that finishes analysis only after claims are distributed cannot prevent allocation leakage, although it can improve future models.

Attribution should also separate campaign mechanics from organic behavior. A user who interacts with five contracts only because the campaign requires five transactions is not necessarily a retained user. The stronger metric is whether the user remains active when the reward incentive is removed.

The operational baseline is not wallets acquired. It is independent users retained after the reward condition disappears.

The limits of on-chain evidence

On-chain graphs are powerful, but they do not reveal every relationship. They show transfers, contract calls, timing, and balances. They do not reliably establish ownership, physical location, or intent.

Two wallets can share funding because they belong to:

  • members of one investment group;
  • a market-making operation;
  • a family or organization;
  • a custodial service;
  • a common exchange withdrawal system;
  • a grant or treasury program.

A protocol that treats every relationship as proof of abuse will classify legitimate coordinated activity as farming. This is particularly relevant in Web3, where teams, delegates, contributors, and communities often operate through shared infrastructure.

Off-chain data may improve attribution, but it creates additional privacy and governance questions. IP addresses, device information, social accounts, and identity verification can connect wallets to a person, but such data is not recorded on public blockchains and should not be assumed to be used by every protocol.

VPNs and proxies do not change the central analytical problem. A network-level signal may be useful in some systems, but the main evidence in public airdrop analysis remains the transaction graph and the funding pattern. No network configuration guarantees that a coordinated wallet cluster will avoid detection.

The correct language is probabilistic. A wallet can be high-risk, low-risk, or unresolved. It should not be described as definitively fraudulent unless the evidence supports that conclusion through a separate process.

Building an anti-Sybil system as a repeatable process

A project preparing an airdrop can structure detection into several stages.

Stage one: define the target user

The protocol must first define what it wants to reward. A trader, liquidity provider, developer, delegate, bridge user, and community contributor will produce different on-chain patterns.

If all categories are combined into one model, the classifier will confuse legitimate diversity with anomalous behavior. Separate cohorts produce a stronger baseline.

Stage two: collect the graph

The protocol should index:

  • inbound and outbound transfers;
  • bridge activity;
  • contract calls;
  • token approvals;
  • transaction timestamps;
  • gas and fee data;
  • balances before and after interactions;
  • known exchange and infrastructure labels.

The data should be collected across every relevant chain. A single-chain view can miss the original funding source or the consolidation path.

Stage three: generate candidate clusters

Graph algorithms can identify connected components, dense subgraphs, common sources, and repeated topologies. The output is a candidate set, not a final verdict.

This distinction controls false positives. Candidate generation should be broad. Final classification should require multiple independent signals.

Stage four: score behavior

Behavioral features can be converted into a risk score. The score should account for both positive and negative evidence. Long-term activity, varied protocol use, retained balances, and independent funding paths can reduce risk. Compressed timing, repeated sequences, and common consolidation can increase it.

The scoring system should be tested against historical users and synthetic attack patterns. A model that performs well on one campaign may fail when the user base or incentive structure changes.

Stage five: review and communicate

High-confidence exclusions can be automated. Borderline cases need review, delayed rewards, or weighted allocation. Users should receive a description of the evidence categories used in the decision.

A review process does not need to reveal proprietary model weights. It does need to establish that decisions are based on reproducible transaction data rather than arbitrary wallet lists.

Stage six: measure post-distribution outcomes

The final model is not complete when tokens are claimed. Post-claim movement reveals whether the distribution created retained usage or temporary address activity.

The protocol should compare the initial campaign baseline with later behavior. If most allegedly independent users disappear after claiming, the campaign’s acquisition metric was overstated even if the Sybil filter performed as designed.

The measurable conclusion

Crypto airdrop farming is best treated as an attribution problem. The protocol is not trying to determine whether an address exists. It is trying to estimate how many independent participants stand behind a set of addresses.

The strongest airdrop Sybil detection systems combine:

  • asset-transfer graph analysis;
  • common funding-source tracing;
  • transaction-timing analysis;
  • contract and behavior clustering;
  • economic participation thresholds;
  • community evidence with controlled review;
  • weighted treatment of uncertain cases;
  • post-claim retention measurement.

LayerZero demonstrated the scale of filtering that can be required: 803,093 wallets removed from approximately 2.08 million assessed addresses. Arbitrum demonstrated the cost of loopholes: roughly 253 million ARB claimed by addresses identified as Sybil or same-person wallets in a later analysis. Hyperlane demonstrated that a protocol can move beyond a binary ban by applying proportional penalties.

The formula is direct:

Distribution quality = eligible addresses × estimated independence × post-reward retention.

If independence is not measured, wallet count is only a proxy. If retention is not measured, user acquisition is only a temporary transaction pattern. A defensible airdrop model therefore reports fewer superficial participants and more reliable attribution.

FAQ

What is a Sybil attack in the context of crypto airdrops?
A Sybil attack occurs when a single participant controls multiple wallets to mimic independent users, allowing them to capture multiple reward allocations for the same underlying behavior.
How do protocols identify Sybil wallets using transaction timing?
Detection systems look for compressed latency, such as funding and contract interactions occurring within minutes or hours across many wallets, which suggests automated coordination rather than organic user behavior.
Why is funding-source analysis important for detecting Sybil clusters?
Even if wallets appear diverse, tracing their initial funding back to a common source—such as a specific exchange withdrawal or intermediary wallet—reveals a shared operational origin.
What is the difference between binary bans and weighted Sybil scoring?
Binary bans completely exclude wallets from an airdrop, while weighted scoring reduces the reward multiplier based on the calculated risk score, allowing for more nuance in borderline cases.
Can community reporting help identify Sybil wallets?
Yes, community reporting can provide evidence of operational patterns that are difficult to infer from public graph data alone, provided the protocol uses a controlled process with reproducible evidence.

By Thomas Kingsley