How to Detect Sybil Attacks in Crypto Airdrops

If you run a token launch, quest campaign, faucet, waitlist, or referral program, one question matters more than almost anything else: are these real users, or one operator controlling hundreds of accounts? That is the core of a Sybil attack. In crypto, Sybil abuse usually shows up as airdrop farming — one person or team creating large numbers of wallets, emails, accounts, or KYC attempts to capture rewards that were meant for genuine community members.

The tricky part is that there is no single silver bullet. Wallet-level analysis helps, but on-chain data alone often arrives too late. CAPTCHA helps, but serious farmers solve or outsource it. Device fingerprinting helps, but it can be evaded. The strongest systems combine multiple signals: IP intelligence, ASN clustering, rate limits, wallet behavior, session patterns, and review queues. That layered approach is what makes airdrop abuse expensive instead of profitable.

In this guide, we'll break down a practical detection architecture for Web3 products. We'll focus especially on the signals you can deploy before claim approval, which is where crypto-specific bot detection creates the most leverage. You'll also see how to combine network data with application logic and how to design decisions that reduce abuse without blocking too many legitimate privacy-conscious users.

Why airdrop farming is hard to stop

Good attackers do not reuse one IP and one browser. They rotate residential proxies, spread traffic over multiple ASNs, randomize browser signatures, use warm wallets, and slow down claim timing to imitate real humans. That means naïve rules like “block all VPNs” or “one claim per IP” are both too weak and too blunt.

The goal is not to find one perfect indicator. The goal is to combine weak signals into a strong decision. A residential proxy alone may not be enough to reject a claim. But a residential proxy plus a high-risk ASN, plus 18 wallets from the same subnet, plus synchronized quest completion, plus a fresh disposable email domain, becomes a very strong abuse pattern.

Build a risk pipeline, not a binary gate

The best architecture is a scoring pipeline with three outcomes: allow, challenge/review, and block. That lets you reserve hard blocks for obvious abuse while giving suspicious but potentially legitimate users an alternate path. For example, a user connecting from a commercial VPN might still be fine if they have an older wallet, normal quest behavior, and no infrastructure clustering.

type ClaimDecision = 'allow' | 'review' | 'block';

interface ClaimSignals {
  isDatacenter: boolean;
  isProxy: boolean;
  isResidentialProxy: boolean;
  isTor: boolean;
  riskScore: number;
  asn: string;
  subnet: string;
  walletAgeDays: number;
  claimsFromASN24h: number;
  claimsFromSubnet1h: number;
  questsCompletedIn10m: number;
}

function decideClaim(s: ClaimSignals): ClaimDecision {
  let score = 0;

  if (s.isTor) score += 100;
  if (s.isDatacenter) score += 60;
  if (s.isResidentialProxy) score += 45;
  if (s.isProxy) score += 25;
  score += Math.round(s.riskScore * 40);

  if (s.walletAgeDays < 7) score += 20;
  if (s.claimsFromASN24h > 25) score += 30;
  if (s.claimsFromSubnet1h > 5) score += 35;
  if (s.questsCompletedIn10m > 10) score += 25;

  if (score >= 100) return 'block';
  if (score >= 55) return 'review';
  return 'allow';
}

This kind of model is simple enough to tune quickly and explain to stakeholders. It also maps cleanly to real operational workflows: approved claims go through instantly, borderline claims face extra friction, and clearly abusive claims are denied before token allocation.

The highest-value signals for Sybil detection

1. Infrastructure type

Start with network infrastructure. Datacenter IPs, Tor exits, public proxies, and high-risk VPN ranges are unusually common in farming operations. Airdrop claim flows, faucet endpoints, and reward redemptions are especially sensitive because they convert infrastructure abuse directly into financial loss.

2. ASN and subnet clustering

Farmers rotate IPs, but they often stay within a provider or nearby network ranges. That is why ASN clustering matters so much. If 40 “independent” wallets are claiming from the same hosting ASN or adjacent /24 ranges, that is usually not organic growth. Shared infrastructure analysis is much more durable than single-IP blocking.

3. Velocity and burst patterns

Real users arrive unevenly. Farmers often arrive in bursts after campaign links circulate in abuse communities. Track claims per subnet, ASN, referral code, device family, and wallet age bucket. Sudden spikes are often the first visible symptom of organized farming.

4. Wallet maturity and account context

A brand new wallet is not proof of fraud, but fresh wallets combined with suspicious infrastructure are highly predictive. If the same network is submitting dozens of new wallets with similar creation timing and no prior engagement, your system should escalate aggressively.

5. Cross-signal consistency

Look for mismatches. Example: a user claims to be a retail community member, but their requests originate from datacenter infrastructure and complete all quests in two minutes. Those inconsistencies are often more useful than any single attribute.

Inline screening for claim endpoints

You do not need a huge fraud platform to start. A simple middleware layer can screen claim, referral, faucet, and waitlist endpoints in real time. The pattern below checks IP intelligence, computes cluster counters, and adds headers or context for downstream decisioning.

// Next.js middleware for airdrop claim screening
import { NextRequest, NextResponse } from 'next/server';

export async function middleware(request: NextRequest) {
  if (!request.nextUrl.pathname.startsWith('/api/claim')) {
    return NextResponse.next();
  }

  const ip = request.headers.get('x-forwarded-for')?.split(',')[0]?.trim() || '127.0.0.1';

  try {
    const resp = await fetch(`https://api.ipasis.com/v1/lookup/${ip}`, {
      headers: { Authorization: `Bearer ${process.env.IPASIS_API_KEY}` },
      signal: AbortSignal.timeout(50),
    });

    const data = await resp.json();
    const headers = new Headers(request.headers);

    headers.set('x-ip-risk-score', String(data.risk_score ?? 0));
    headers.set('x-ip-asn', String(data.asn ?? 'unknown'));
    headers.set('x-ip-proxy', String(Boolean(data.is_proxy)));
    headers.set('x-ip-residential-proxy', String(Boolean(data.is_residential_proxy)));
    headers.set('x-ip-datacenter', String(Boolean(data.is_datacenter)));
    headers.set('x-ip-tor', String(Boolean(data.is_tor)));

    if (data.is_tor || data.is_datacenter) {
      return NextResponse.json(
        { error: 'claim_blocked', reason: 'high_risk_infrastructure' },
        { status: 403 }
      );
    }

    return NextResponse.next({ request: { headers } });
  } catch {
    return NextResponse.next(); // fail open, but log timeout metrics
  }
}

Inline checks are best for obvious abuse and immediate routing decisions. For deeper pattern detection, enrich the event asynchronously and aggregate over time. That is where you catch multi-account farming that looks clean on a single request but suspicious in aggregate.

Add cluster intelligence with Redis or your event pipeline

Cluster counters let you answer questions like: how many claims came from this ASN in the last 24 hours? How many wallets from this subnet claimed in the last hour? How many “unique” users completed all tasks from the same network slice? This is one of the most effective ways to catch farmers rotating IPs inside the same provider footprint.

import Redis from 'ioredis';
const redis = new Redis(process.env.REDIS_URL!);

export async function recordClaimTelemetry({ asn, subnet, referralCode }: {
  asn: string;
  subnet: string;
  referralCode?: string;
}) {
  const pipeline = redis.pipeline();

  pipeline.incr(`sybil:asn:${asn}:24h`);
  pipeline.expire(`sybil:asn:${asn}:24h`, 86400);

  pipeline.incr(`sybil:subnet:${subnet}:1h`);
  pipeline.expire(`sybil:subnet:${subnet}:1h`, 3600);

  if (referralCode) {
    pipeline.incr(`sybil:referral:${referralCode}:1h`);
    pipeline.expire(`sybil:referral:${referralCode}:1h`, 3600);
  }

  await pipeline.exec();
}

This is also where internal links to adjacent controls matter. If your campaign is connected to signup bonuses, pair Sybil checks with fake signup prevention. If referrals are involved, combine it with referral abuse controls. Sybil attacks rarely stay in one funnel.

Design review queues instead of overblocking

Overblocking is how good security systems lose support. Community teams get angry users, growth teams see conversion drops, and ops disables the controls. The fix is simple: create a review band. Do not force every suspicious user into a hard reject. Send medium-confidence cases into extra friction, delayed approval, or manual review.

• Allow: low-risk residential traffic, mature wallets, no cluster anomalies
• Review: VPN use plus young wallet, or moderate subnet clustering, or unusual task timing
• Block: Tor, datacenter claim traffic, extreme cluster signals, repeated denied attempts

This approach is especially important in crypto because legitimate users often value privacy. Blanket VPN blocking is attractive operationally, but usually leaves growth on the table. Better to treat VPNs as one signal inside a broader model. That is the same principle behind modern proxy detection more generally.

What to log for future investigations

Even if you only start with basic inline controls, log enough structured data to investigate abuse clusters later. Keep the decision path explainable. For each claim, store the IP risk response, ASN, subnet, request path, referral code, wallet age, device/session identifier, and final decision. That gives your ops team something concrete to query when the campaign gets noisy.

A simple rule of thumb: if you cannot explain why a claim was blocked, you will struggle to tune the model. Explainability is not just for regulators. It is how your internal team improves detection week over week.

A practical rollout plan

1. Week 1: log-only mode on claim endpoints, referrals, and faucets
2. Week 2: hard block Tor and obvious datacenter claim traffic
3. Week 3: add ASN/subnet counters and a review queue
4. Week 4: tune thresholds based on real false positives and abuse patterns
5. Week 5+: enrich with wallet heuristics, referral graph analysis, and device correlation

This staged rollout keeps risk low. You learn your traffic before applying aggressive controls, and you can show the team exactly how much abuse would have been blocked at each threshold.

Final takeaway

If you want to detect Sybil attacks in crypto airdrops, stop thinking in terms of one-user-one-IP or one-user-one-wallet. Farmers break those assumptions easily. Instead, model infrastructure, clustering, velocity, and consistency. Block the obvious abuse inline, review the gray area, and use aggregated network intelligence to expose the operator behind the “many users” story.

That combination is what turns airdrop defense from reactive cleanup into proactive control. And because the financial incentives in crypto are immediate, the earlier you score the request, the more damage you prevent.

Related reading

• Bot Detection for Crypto & Web3
• Mitigating Credential Stuffing with IP Intelligence
• Preventing Referral Abuse with IP-Based Controls
• Detecting Residential Proxies: Practical Techniques