I built an airdrop scanner that tells crypto farmers how much they've already lost. Most see a number they don't like.

Airdrop Farming Economics: Implementing Sybil Detection and Gas-Aware Scoring

Current Situation Analysis

The airdrop farming ecosystem has undergone a structural shift from volume-based accumulation to risk-managed distribution. Historically, farmers operated under the assumption that transaction count was the primary driver of token allocation. This model encouraged high-frequency bridging and repetitive interactions, often ignoring the underlying cost basis. However, protocol allocators have deployed sophisticated Sybil filters that prioritize behavioral diversity and consistency over raw activity.

This misalignment creates a significant blind spot. Many scanning tools continue to market "eligibility scores" based on volume metrics, obscuring the financial reality that farming operations frequently operate at a net loss. Recent token generation events (TGEs) provide empirical evidence of this shift. Berachain's distribution mechanism disqualified between 30% and 60% of farmed wallets due to clustering signals, while zkSync implemented comparable filtering rates. The era of low-friction bridging yielding high-value allocations has ended; per-wallet allocations have compressed, and mainnet gas costs remain prohibitive.

The core problem is twofold: farmers lack visibility into their actual gas expenditure in USD, and they lack tools to detect pairwise Sybil clustering before protocols do. Without these signals, operations risk burning capital on transactions that are either economically unviable or destined for disqualification.

WOW Moment: Key Findings

Analysis of multi-wallet farming setups reveals a critical divergence between volume-optimized strategies and pattern-aware approaches. When evaluating operations across gas expenditure, Sybil risk, and allocation probability, the data indicates that volume alone correlates negatively with net return on investment.

Strategy	Average Gas Expenditure	Sybil Cluster Risk	Allocation Probability
Volume-Optimized	High	Critical (>65% overlap)	Low (Filtered)
Pattern-Aware	Moderate	Low (<20% overlap)	High (Verified)
Gas-Realistic	Controlled	Variable	Net Positive ROI

The finding that matters most is the threshold behavior in Sybil detection. Wallets exhibiting day-overlap ratios exceeding 65% are flagged with high probability by protocol allocators. This metric is easily detectable locally and correctable through activity staggering. Furthermore, pattern-aware scoring demonstrates that 200 transactions distributed across 20 unique counterparties yield a higher effective score than 500 transactions concentrated on a single contract, aligning with actual allocation heuristics.

Core Solution

Building a robust farming scanner requires three technical pillars: accurate gas accounting in USD, pairwise Sybil detection, and pattern-aware scoring. The architecture should prioritize transparency and auditability, minimizing trust assumptions.

1. Gas Accounting in USD

The headline metric must reflect the actual cost of operations. This requires summing gasUsed * gasPrice across all transactions, converting to native token units, and multiplying by live price feeds.

Implementation:

interface TransactionReceipt {
    gasUsed: bigint;
    effectiveGasPrice: bigint;
    chainId: number;
}

interface PriceFeed {
    [chainId: number]: number;
}

const calculateNetBurn = (receipts: TransactionReceipt[], feed: PriceFeed): number => {
    return receipts.reduce((total, tx) => {
        const gasCostWei = tx.gasUsed * tx.effectiveGasPrice;
        const gasCostNative = Number(gasCostWei) / 1e18;
        const pricePerUnit = feed[tx.chainId] || 0;
        return total + (gasCostNative * pricePerUnit);
    }, 0);
};

Rationale: Using effectiveGasPrice ensures accuracy on EIP-1559 chains. Converting to USD via a price feed provides a universal baseline for comparing costs across chains with different native token valuations.

2. Pairwise Sybil Clustering Detection

Protocols cluster wallets based on behavioral overlaps. Day-overlap is a primary signal; if multiple wallets show activity on the same days, they are likely controlled by a single entity.

Implementation:

interface WalletActivity {
    [address: string]: Set<string>;
}

interface ClusterWarning {
    pair: [string, string];
    overlapRatio: number;
    recommendation: string;
}

const analyzePairwiseOverlaps = (
    wallets: string[], 
    activity: WalletActivity, 
    threshold: number = 0.65
): ClusterWarning[] => {
    const warnings: ClusterWarning[] = [];
    
    for (let i = 0; i < wallets.length; i++) {
        for (let j = i + 1; j < wallets.length; j++) {
            const setA = activity[wallets[i]];
            const setB = activity[wallets[j]];
            
            if (setA.size < 5 || setB.size < 5) continue;
            
            const intersection = new Set([...setA].filter(day => setB.has(day)));
            const overlapRatio = intersection.size / Math.min(setA.size, setB.size);
            
            if (overlapRatio > threshold) {
                warnings.push({
                    pair: [wallets[i], wallets[j]],
                    overlapRatio,
                    recommendation: "Stagger activity days to reduce pairwise correlation."
                });
            }
        }
    }
    return warnings;
};

Rationale: The 65% threshold is derived from empirical analysis of public TGE post-mortems. Using the minimum set size as the denominator prevents skew when comparing wallets with vastly different activity levels. This approach detects the easiest leak locally, allowing farmers to correct behavior before protocol-side filtering occurs.

3. Pattern-Aware Scoring

Scoring must reward diversity and consistency rather than volume. A base score is adjusted by multipliers that reflect the quality of interactions.

Implementation:

interface FarmingMetrics {
    baseScore: number;
    uniqueCounterparties: number;
    activitySpreadDays: number;
}

const computeProfileScore = (metrics: FarmingMetrics): number => {
    const diversityMultiplier = Math.min(1.2, 1 + (metrics.uniqueCounterparties / 50));
    const consistencyMultiplier = metrics.activitySpreadDays > 30 ? 1.1 : 1.0;
    
    const adjustedScore = metrics.baseScore * diversityMultiplier * consistencyMultiplier;
    return Math.min(100, Math.round(adjustedScore));
};

Rationale: The diversity multiplier caps at 1.2x to prevent gaming, while the consistency multiplier rewards sustained activity over time. This structure ensures that operations focusing on unique counterparties and long-term engagement receive higher scores, matching protocol allocation logic.

Architecture Decisions

The scanner is deployed as a single HTML file using React 18 and Babel standalone via CDN. This eliminates build steps and backend dependencies, ensuring that API keys and wallet data remain in localStorage and never transit a server. The tool leverages the Etherscan V2 unified API for multi-chain coverage, with fallbacks for specialized explorers like Sonicscan or Routescan. Concurrency is managed via batched requests (5 in-flight) with exponential backoff on 429/503 errors, enabling a 3-wallet × 13-chain scan in approximately 30 seconds.

Pitfall Guide

1. The Volume Trap

Explanation: Farmers often assume that increasing transaction count linearly improves allocation chances. Protocols penalize volume spamming as a Sybil signal. Fix: Shift focus to unique counterparties and contract diversity. Use the pattern-aware scoring model to validate that increased volume correlates with improved diversity metrics.

2. Ignoring Day-Overlap Clustering

Explanation: Running all wallets on the same schedule creates a strong Sybil signal. Even varying transaction types does not mitigate day-overlap detection. Fix: Implement pairwise overlap analysis. Stagger activity days across wallets to keep overlap ratios below the 65% threshold. Automate scheduling to enforce diversity.

3. Neglecting Gas Economics

Explanation: Farmers frequently bridge or transact without calculating the USD cost, leading to operations that are net negative even if an allocation occurs. Fix: Headline the total gas burn in USD. Compare this against estimated allocation values. Abort operations where gas costs exceed potential returns.

4. API Rate Limit Violations

Explanation: Aggressive scanning can trigger rate limits, resulting in incomplete data or temporary bans. Fix: Use batched requests with Promise.allSettled. Implement exponential backoff on 429/503 errors. Monitor API usage quotas and rotate keys if necessary.

5. Stale Protocol Criteria

Explanation: Airdrop criteria change rapidly. Relying on outdated scoring weights leads to inaccurate assessments. Fix: Maintain a dynamic registry of protocol criteria. Update scoring models frequently based on new TGE data and community feedback. Automate registry updates where possible.

6. Over-Reliance on Heuristic Scoring

Explanation: Scoring models are approximations. They may not capture all protocol-side signals, such as IP analysis or transfer graphs. Fix: Treat scores as directional indicators rather than guarantees. Combine scoring with manual review of wallet behavior and protocol documentation.

7. Single-Point API Failure

Explanation: Depending on a single API provider can cause scanner outages if the provider experiences downtime or changes terms. Fix: Implement fallback explorers for critical chains. Use the Etherscan V2 unified API as the primary source but maintain integrations with alternatives like Sonicscan or Routescan.

Production Bundle

Action Checklist

• Audit Gas Spend: Calculate total gas burn in USD across all wallets and chains.
• Run Sybil Check: Execute pairwise overlap analysis to identify clustering risks.
• Diversify Counterparties: Ensure interactions span multiple unique contracts and addresses.
• Stagger Activity: Adjust wallet schedules to reduce day-overlap ratios below 65%.
• Verify API Keys: Confirm Etherscan V2 keys are active and have sufficient quota.
• Update Criteria: Refresh protocol scoring weights based on latest TGE data.
• Monitor ROI: Compare gas costs against estimated allocation values to ensure profitability.

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
Small Farm (<5 wallets)	Manual staggering	Low overhead, easy to manage	Time investment
Large Farm (>20 wallets)	Automated scanner	Efficiency, scalability	API costs
High Gas Chains	Focus on L2s	ROI preservation	Lower gas fees
Pre-TGE Phase	Pattern-aware scoring	Aligns with allocation logic	Variable
Post-TGE Phase	Gas accounting focus	Validate net returns	High accuracy

Configuration Template

{
  "scanner": {
    "batchSize": 5,
    "backoffStrategy": "exponential",
    "maxRetries": 3
  },
  "sybil": {
    "overlapThreshold": 0.65,
    "minActivityDays": 5
  },
  "scoring": {
    "diversityCap": 1.2,
    "consistencyThreshold": 30,
    "maxScore": 100
  },
  "protocols": [
    {
      "name": "ExampleProtocol",
      "chainId": 1,
      "criteria": [
        { "key": "uniqueCounterparties", "weight": 0.5 },
        { "key": "activitySpread", "weight": 0.5 }
      ]
    }
  ]
}

Quick Start Guide

1. Obtain API Key: Register for an Etherscan V2 unified API key to access multi-chain data.
2. Input Wallets: Add wallet addresses to the scanner's configuration. Ensure keys are stored securely in localStorage.
3. Run Scan: Execute the scanner to fetch transaction data, calculate gas burn, and detect Sybil clusters.
4. Review Report: Analyze the output for gas costs, overlap warnings, and pattern scores. Adjust wallet behavior based on findings.