Key takeaways<\/h4>\n\n- Sybil resistance is an allocation decision under uncertainty. On-chain signals show correlation between addresses and never prove who controls them.<\/li>\n
- Filters, behavioral scoring, clustering, and human review answer different questions. Collapsing them into one pipeline produces confident decisions built on weak evidence.<\/li>\n
- Judge a program by allocation quality and by how it handles mistakes. The removal count says little.<\/li>\n<\/ul>\n<\/div>\n
Name the behavior the campaign is paying for<\/h2>\n
Most eligibility disputes start before any filter runs, with a team that never wrote down what the airdrop was buying.<\/p>\n
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.<\/p>\n
Four groups need an explicit answer before the snapshot:<\/p>\n
\n- Existing users: reward depth and duration over raw counts.<\/li>\n
- Newcomers: expect thin histories, and decide in advance whether that reduces a score.<\/li>\n
- Contributors: much of the work sits off chain, in repositories, forums, translations, and moderation logs.<\/li>\n
- People using several wallets: separating funds by purpose breaks no rule by itself.<\/li>\n<\/ul>\n
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.<\/p>\n
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.<\/p>\n
What a filter actually proves<\/h2>\n
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.<\/p>\n
The common signals are familiar:<\/p>\n
\n- Timing: addresses funded or first active within minutes of each other.<\/li>\n
- Shared funding: many addresses drawing first gas from one source.<\/li>\n
- Repeated patterns: near identical sequences, amounts, intervals, or gas settings.<\/li>\n
- Account history: age, dormancy, activity clustered around qualification windows.<\/li>\n
- Common counterparties: addresses touching the same contracts in the same order.<\/li>\n<\/ul>\n
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.<\/p>\n
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.<\/p>\n
A cutoff that worked on one chain, in one quarter, against one cohort is not a best practice for anyone else.<\/p>\n
![\"Diagram](\"https:\/\/www.blockchainappfactory.com\/blog\/wp-content\/uploads\/2026\/09\/One-wallet-funding-pattern-with-two-possible-explanations-Image.jpg\")
<\/p>\n
How behavioral scoring should work<\/h2>\n
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.<\/p>\n
Five properties decide whether a score is worth anything:<\/p>\n
\n- Signal quality: a signal earns its weight only if it separates the groups you care about on real data.<\/li>\n
- Independence: funding source, first transaction time, and gas origin often describe one event. Counting all three triples the weight of one fact.<\/li>\n
- Missing data: a new address has no history. Absence of evidence lowers confidence. It should not raise the risk score.<\/li>\n
- Threshold calibration: the cutoff sets both error rates, and moving it trades one against the other.<\/li>\n
- Confidence: carry an uncertainty band with every score, and route low confidence cases to reviewers.<\/li>\n<\/ul>\n
One illustrative example follows. Every weight and cutoff below is illustrative and should not be copied into a live program.<\/p>\n
\n- Shared first funding source with 20 or more list addresses: plus 30<\/li>\n
- Transaction sequence matching a known cluster template: plus 25<\/li>\n
- Capital held through a 30 percent drawdown: minus 20<\/li>\n
- Governance vote with written rationale: minus 25<\/li>\n<\/ul>\n
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.<\/p>\n
<\/p>\n
Name the behavior the campaign is paying for<\/h2>\n
Most eligibility disputes start before any filter runs, with a team that never wrote down what the airdrop was buying.<\/p>\n
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.<\/p>\n
Four groups need an explicit answer before the snapshot:<\/p>\n
- \n
- Existing users: reward depth and duration over raw counts.<\/li>\n
- Newcomers: expect thin histories, and decide in advance whether that reduces a score.<\/li>\n
- Contributors: much of the work sits off chain, in repositories, forums, translations, and moderation logs.<\/li>\n
- People using several wallets: separating funds by purpose breaks no rule by itself.<\/li>\n<\/ul>\n
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.<\/p>\n
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.<\/p>\n
What a filter actually proves<\/h2>\n
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.<\/p>\n
The common signals are familiar:<\/p>\n
- \n
- Timing: addresses funded or first active within minutes of each other.<\/li>\n
- Shared funding: many addresses drawing first gas from one source.<\/li>\n
- Repeated patterns: near identical sequences, amounts, intervals, or gas settings.<\/li>\n
- Account history: age, dormancy, activity clustered around qualification windows.<\/li>\n
- Common counterparties: addresses touching the same contracts in the same order.<\/li>\n<\/ul>\n
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.<\/p>\n
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.<\/p>\n
A cutoff that worked on one chain, in one quarter, against one cohort is not a best practice for anyone else.<\/p>\n
<\/p>\nHow behavioral scoring should work<\/h2>\n
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.<\/p>\n
Five properties decide whether a score is worth anything:<\/p>\n
- \n
- Signal quality: a signal earns its weight only if it separates the groups you care about on real data.<\/li>\n
- Independence: funding source, first transaction time, and gas origin often describe one event. Counting all three triples the weight of one fact.<\/li>\n
- Missing data: a new address has no history. Absence of evidence lowers confidence. It should not raise the risk score.<\/li>\n
- Threshold calibration: the cutoff sets both error rates, and moving it trades one against the other.<\/li>\n
- Confidence: carry an uncertainty band with every score, and route low confidence cases to reviewers.<\/li>\n<\/ul>\n
One illustrative example follows. Every weight and cutoff below is illustrative and should not be copied into a live program.<\/p>\n
- \n
- Shared first funding source with 20 or more list addresses: plus 30<\/li>\n
- Transaction sequence matching a known cluster template: plus 25<\/li>\n
- Capital held through a 30 percent drawdown: minus 20<\/li>\n
- Governance vote with written rationale: minus 25<\/li>\n<\/ul>\n
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.<\/p>\n
<\/p>\n
![\"Flow](\"https:\/\/www.blockchainappfactory.com\/blog\/wp-content\/uploads\/2026\/09\/Airdrop-Eligibility-Process-2.jpg\")
<\/p>\n