A token team holds an eligibility list of 250,000 addresses and eight days before allocations lock. Part of it belongs to people who used the product. Part belongs to operators running scripted wallets at volume. Nobody can say where the line sits.
Cut too hard and real users lose allocations, complain in public, and skip the next campaign. Cut too lightly and a farming operation takes a large share of supply and sells into the first week of trading. Both mistakes stay invisible until tokens move.
The scale is not hypothetical. In the Sybil analysis Linea published with Nansen, disclosed in January 2025, 1,297,203 addresses were reviewed and 516,960 were classified as Sybil, close to 40 percent of the list. That figure came from thresholds the team chose. It is not a count of proven abuse.
Sybil resistance is an allocation decision under uncertainty, made on partial evidence against a deadline.
Key takeaways
- Sybil resistance is an allocation decision under uncertainty. On-chain signals show correlation between addresses and never prove who controls them.
- Filters, behavioral scoring, clustering, and human review answer different questions. Collapsing them into one pipeline produces confident decisions built on weak evidence.
- Judge a program by allocation quality and by how it handles mistakes. The removal count says little.
Name the behavior the campaign is paying for
Most eligibility disputes start before any filter runs, with a team that never wrote down what the airdrop was buying.
Write the objective first, in plain terms. A campaign rewarding sustained liquidity needs different evidence from one rewarding governance or code contribution. The objective decides which signals carry weight. Scoring that runs ahead of it ranks whatever was easiest to query.
Four groups need an explicit answer before the snapshot:
- Existing users: reward depth and duration over raw counts.
- Newcomers: expect thin histories, and decide in advance whether that reduces a score.
- Contributors: much of the work sits off chain, in repositories, forums, translations, and moderation logs.
- People using several wallets: separating funds by purpose breaks no rule by itself.
Activity volume is the easiest thing to measure and to manufacture. Transaction counts and bridge hops come cheaply from a script. Useful participation is harder to fake: capital held through a drawdown, repeat usage across long gaps, votes with written rationale, code merged into a public repository.
One person controlling several wallets is not automatically abusive. Abuse depends on the published rule and the behavior being assessed. If the rules promise one allocation per person and someone claims twelve, that breaks the rule. If the rules reward volume and someone supplies volume across twelve wallets, the campaign designed that outcome.
What a filter actually proves
A filter is a rule with a cutoff. It answers a narrow question with yes or no. Filters are cheap and easy to explain, which is why most programs start there.
The common signals are familiar:
- Timing: addresses funded or first active within minutes of each other.
- Shared funding: many addresses drawing first gas from one source.
- Repeated patterns: near identical sequences, amounts, intervals, or gas settings.
- Account history: age, dormancy, activity clustered around qualification windows.
- Common counterparties: addresses touching the same contracts in the same order.
Every one of those signals has a benign explanation that occurs constantly. Exchange withdrawals place thousands of unrelated users on one funding source within an hour. Users of a single wallet app or RPC provider produce similar transaction shapes. Popular tutorials and quest boards generate identical action sequences across strangers. A community running a workshop produces clustered activity that looks coordinated because it is.
A filter establishes that a pattern exists. It does not establish who controls the addresses, or that anyone broke a published rule. Treat filter output as a reason to look closer.
A cutoff that worked on one chain, in one quarter, against one cohort is not a best practice for anyone else.
How behavioral scoring should work
Scoring replaces a single cutoff with a weighted combination of signals. Done well, it ranks addresses by how far the evidence departs from expected behavior. Done badly, it wraps guesswork in arithmetic and makes it look official.
Five properties decide whether a score is worth anything:
- Signal quality: a signal earns its weight only if it separates the groups you care about on real data.
- Independence: funding source, first transaction time, and gas origin often describe one event. Counting all three triples the weight of one fact.
- Missing data: a new address has no history. Absence of evidence lowers confidence. It should not raise the risk score.
- Threshold calibration: the cutoff sets both error rates, and moving it trades one against the other.
- Confidence: carry an uncertainty band with every score, and route low confidence cases to reviewers.
One illustrative example follows. Every weight and cutoff below is illustrative and should not be copied into a live program.
- Shared first funding source with 20 or more list addresses: plus 30
- Transaction sequence matching a known cluster template: plus 25
- Capital held through a 30 percent drawdown: minus 20
- Governance vote with written rationale: minus 25
An address at 70 points is not 70 percent likely to be abusive. A score carries probability meaning only after calibration against verified outcomes, which are scarce here. Read it as a queue position. High scores get reviewed first.
| A score tells you where to look. It never tells you who is on the other side of the keyboard. |
Where wallet clustering breaks down
Clustering groups addresses that look related. It is the best available tool for finding industrial scale farming, because scripted operations leave structure individuals do not.
One distinction carries most of the weight. An observed link is not inferred common control. A transfer between two addresses is observed. The claim that one person controls both is an inference, only as strong as the alternatives you ruled out.
Infrastructure manufactures links constantly. Exchange withdrawal addresses connect strangers. Bridges and aggregators sit between thousands of wallets. Shared relayers and paymasters appear in the graph of everyone who touched them. Clustering that treats these as ordinary edges merges strangers into one alleged actor.
Three practices reduce that failure:
- Keep an exclusion list of known service and contract addresses, refreshed before every run.
- Weight direct peer to peer transfers above shared use of a public contract.
- Require several independent link types before treating a cluster as one actor.
The Arbitrum Foundation’s published Sybil detection repository follows this shape. It strips known entity addresses, including bridges, exchanges, routers, and contracts, before building its transaction graphs, then applies community detection to break oversized clusters apart.
| Layer | What it can establish | Main limitation | Evidence strength |
|---|---|---|---|
| Eligibility filters | Whether an address meets a published rule | Nothing about control or intent, and easy to design around once published | Weak on abuse |
| Behavioral risk scoring | A ranking of how far behavior departs from expected patterns | Correlated signals inflate scores, which carry no probability meaning without labels | Partial, ranking only |
| Wallet clustering | Observed links, and the shape of large coordinated operations | Shared infrastructure creates false links, and common control stays an inference | Strong on scale, weak on identity |
| Identity or personhood signals | That a distinct person or credential stands behind a claim | Excludes privacy conscious users, and creates data handling duties | Strong on uniqueness |
| Human review and appeals | Context no automated signal captures, and a record of reversals | Slow and inconsistent between reviewers, hard to run at list scale | Strongest per case |
Planning a token launch and unsure your eligibility rules will hold up?Blockchain App Factory works with launch teams on airdrop campaign strategy, quest campaigns, and pre-TGE marketing. |
When the filter gets it wrong
Every threshold produces two error types. Excluding a legitimate user is a false positive. Paying a farmed address is a false negative. Neither reaches zero, so decide early which one your campaign can live with.
Precision and recall describe the trade. Precision is the share of flagged addresses that really were abusive. Recall is the share of abusive addresses you caught. Both need ground truth, meaning verified labels for a sample. Without labels, a reported accuracy figure is an assertion.
Teams can still learn plenty without perfect labels:
- Review samples from both groups. Pull a random sample of flagged addresses and an equal sample of unflagged ones, then judge them blind against the rules.
- Record a reason for every exclusion, one line per address or cluster, naming the signals that drove it.
- Keep appeals proportionate. A wallet signature and an explanation of the funding path resolves most cases. Identity documents belong at the end of that path.
- Track reversals. The share of decisions overturned after review is the most honest quality signal available before launch.
- Measure friction on legitimate users: decision time, and appeals abandoned part way.
CARV, in October 2024, answered complaints about wrongly flagged accounts with two routes: a third party analytics review it estimated at four to eight weeks, or identity verification at two to four weeks. That is what late appeals cost. CARV published no reversal counts, so the outcome remains unknown.
What documented campaigns actually teach
Three disclosures are worth reading closely. Their rules and measurement methods differ, so these numbers are not comparable.
|
516,960 addresses classified as Sybil out of 1,297,203 reviewed, about 39.9 percent, after initial screening had flagged 654,443 Source: Nansen and Linea Sybil report, disclosed January 2025. Flagged is not the same as confirmed abuse, and the methodology is proprietary. |
803,093 addresses on the published Sybil list, narrowed from an initial pool the project described as over 2 million Source: LayerZero, May 2024, combining self-reporting with analysis by LayerZero, Chaos Labs, and Nansen. Project reported and not independently audited. |
7.4% real world accuracy for a detection model trained on synthetic graphs, against 98.25 percent on its own test set Source: Kaczynski and Wiacek, International Journal of Electronics and Telecommunications, 2026. One rollup, externally owned accounts only, manual labels. |
Linea and Nansen, disclosed January 2025
Nansen reviewed 1,297,203 addresses holding Linea XP. Initial screening flagged 654,443, roughly 50 percent. Thresholds were then adjusted toward larger automated operations. The final count was 516,960 classified as Sybil, with 780,243 still eligible. Nansen stated it favored precision over recall and checked clusters by manual sampling. What it shows: the exclusion count is a policy choice. What stays unknown: the thresholds are proprietary, and no reversal figures were published.
LayerZero, May 2024
LayerZero ran a self-report window from 3 to 17 May 2024. Self-reporting addresses kept 15 percent of their intended allocation, and the other 85 percent went back to qualified users. A bounty period followed. Between self-reporting and analysis by LayerZero, Chaos Labs, and Nansen, 803,093 addresses were identified. What it shows: incentives surface behavior detection alone misses. What stays unknown: how many would survive independent scrutiny, since the list is project reported.
Optimism Airdrop 1, May 2022
After distribution, the Optimism Foundation removed a further 17,000 addresses and recovered over 14 million OP, redistributed proportionally to the remaining eligible addresses. It declined to publish the additional filters used, and cited the integrity of future airdrops. What it shows: teams sometimes resolve the transparency trade against disclosure on purpose. What stays unknown: affected users had no basis to evaluate it.
One more figure belongs here. Monad’s published results state that 4.73 billion MON were made available across 289,000 eligible accounts, and that 76,021 unique wallets claimed 3.33 billion tokens, about 70.4 percent, between 14 October and 3 November 2025. Allocation is not distribution, and a number quoted before a claim window closes describes intent.
Mistakes that keep repeating
- Treating activity volume as proof of contribution. Volume rewards whoever automates fastest.
- Treating correlated signals as independent evidence. Three views of one funding event are one fact.
- Changing rules late without explaining the effect. A short note on who is affected prevents most of the backlash.
- Ignoring legitimate shared behavior. Regional communities and popular tutorials produce exactly the clustered activity the campaign asked for.
- Making opaque decisions with no meaningful review. If nobody can appeal, errors never surface.
- Measuring exclusions instead of allocation quality. A large exclusion count describes a threshold. It says nothing about who was paid.
A rollout plan that survives contact with real users
Most damage comes from running detection and enforcement in one step, on one day. Separating them costs a few weeks and prevents the failures that become public disputes.
| 1 | Define objectives and rules. State what the campaign rewards and how multiple wallets are treated. Say which behaviors break the rules. |
| 2 | Evaluate signals on historical or pilot data. Check which ones separate groups, which duplicate each other, how often each is missing, and how stable each one is over time. |
| 3 | Run scoring in shadow mode. Score the list without enforcing anything, and see who lands where before allocations depend on it. |
| 4 | Review samples and calibrate. Read flagged and unflagged samples blind, adjust thresholds against what reviewers find, and record why. |
| 5 | Publish explanations and open appeals before tokens move. Give affected users a reason category, a route to respond, a turnaround time, and a named owner. |
| 6 | Review outcomes after distribution. Report reversal rates, appeal volumes, median decision time, and how the allocation landed. Carry that into the next campaign. |
Transparency has a limit. Publishing exact thresholds hands a specification to the operators you want to exclude. Publishing nothing, as Optimism chose in 2022, leaves legitimate users unable to contest a decision. A workable middle ground: publish the objective, the signal categories, the reason categories behind exclusions, and the appeals route, while holding back weights and cutoffs.
Where to start this week
Take your eligibility draft and answer three questions on one page. What behavior is this campaign paying for? Which error hurts more, excluding a real user or paying a farmed address? What does an excluded person see, and how do they respond? No scoring model supplies those answers later.
Campaign design sits upstream of all this. Blockchain App Factory works with token teams on airdrop campaign strategy and quest campaigns, token launch marketing in the 60 to 90 day window ahead of a sale, community management across Telegram and Discord, and exchange listing coordination. That work shapes the rules users read and the experience of anyone who appeals. It sits alongside your own detection and review process and does not replace it, since that part stays a data and engineering responsibility inside the project or with an analytics partner.
Want help planning an airdrop campaign your community can actually follow? |
Frequently asked questions
Is using several wallets against the rules?
Only if the campaign said so. Many people separate wallets by purpose or by risk. Rules become enforceable when written before the snapshot, so state whether allocation is per address or per person.
Should we publish our Sybil criteria before the snapshot?
Publish the objective, the signal categories, the exclusion reason categories, and the appeals route. Hold back exact weights and cutoffs. Full disclosure becomes a specification for the operators you want to exclude. Full secrecy leaves honest users unable to contest anything.
Do we need identity verification to run a defensible airdrop?
No. Identity checks answer uniqueness, not usefulness, and they exclude privacy conscious users while creating data obligations. Most programs get further by defining rewarded behavior tightly and reviewing edge cases by hand.
What should happen to tokens recovered from excluded addresses?
Announce the destination before exclusions run. Optimism redistributed recovered OP proportionally to remaining eligible addresses in 2022. Other options include the treasury or a later round. The mistake is deciding once the numbers are known.
How long should an appeals window stay open?
Long enough for every timezone to notice and respond, and closed before tokens become transferable. Post a turnaround time, staff it in advance, and publish reversal counts afterwards.
Vimal J is the Head of Sales at Blockchain App Factory, with 10+ years of experience in sales, client strategy, and Web3 business growth. He helps startups, enterprises, and project founders choose the right blockchain solutions for their goals, bringing a practical market perspective to topics like token development, crypto launches, and Web3 adoption.
