Potential Airdrop Tracking Tool Development

Potential Airdrop Tracking Tool Development

Airdrop farming has become a profession. Users maintain dozens of wallets, interact with protocols following clear patterns, and miss distributions only because they can't keep track of announcements. A potential airdrop tracking tool automates monitoring: collects data on wallet interactions with protocols, assesses eligibility based on known criteria, and alerts on new opportunities.

The market here is heterogeneous. There are ready-made solutions — Earni.fi, Metawin, DeBank portfolio — but they're either closed, don't cover niche protocols, or don't allow custom scoring criteria. Custom tool is justified for funds with large wallet portfolio, for protocol teams wanting to analyze own potential distributions.

System Architecture

Data Sources

Tool works with several classes of data:

On-chain activity data — transaction history, contract interactions, token balances, LP positions, NFT holdings. Obtained through RPC nodes (Alchemy, Infura, QuickNode) or specialized indexers.

Protocol-specific criteria — each protocol announcing airdrop publishes snapshot criteria. Typical: minimum trading volume, number of unique active days, use of specific functions (borrow, not only deposit). These criteria must be parsed and stored structurally.

Snapshot data — many protocols publish Merkle tree with addresses and amounts before official announcement (or at moment). The Graph subgraphs, IPFS, protocol GitHub repos — sources for early eligibility check.

Indexing Stack

For monitoring on-chain activity two approaches:

Polling via RPC: request eth_getLogs for known contracts, eth_getTransactionCount, balance checks. Simple, cheap, but slow with many wallets and chains.

Event streaming via Alchemy Notify / QuickNode Streams: webhook on transaction from tracked address. Near-realtime, but requires subscription and webhook endpoint.

For tool with < 100 wallets on 3-5 chains: polling every 15-30 minutes sufficient. For 1000+ wallets — event streaming or self-hosted node with custom indexer mandatory.

interface WalletProfile {
  address: string;
  chains: ChainActivity[];
}

interface ChainActivity {
  chainId: number;
  txCount: number;
  uniqueProtocols: string[];
  uniqueActiveDays: number;
  volumeUSD: number;
  lastActivity: Date;
  tokenBalances: TokenBalance[];
  defiPositions: DefiPosition[];
}

interface AirdropOpportunity {
  protocolName: string;
  estimatedValue: number | null;
  eligibilityScore: number;   // 0-100
  missingCriteria: string[];
  snapshotDate: Date | null;
  claimDeadline: Date | null;
  status: 'potential' | 'confirmed' | 'claimable' | 'claimed' | 'expired';
}

Eligibility Scoring

Pure "yes/no" insufficient — need score with explanation of missing elements. Example logic for protocol like Arbitrum:

function scoreArbitrumEligibility(activity: ChainActivity): EligibilityResult {
  const criteria = [
    {
      name: 'Minimum 4 transactions',
      met: activity.txCount >= 4,
      weight: 20,
    },
    {
      name: 'Activity in 2+ months',
      met: countActiveMonths(activity) >= 2,
      weight: 25,
    },
    {
      name: 'Volume > $10,000',
      met: activity.volumeUSD >= 10000,
      weight: 30,
    },
    {
      name: 'Interaction with 3+ protocols',
      met: activity.uniqueProtocols.length >= 3,
      weight: 25,
    },
  ];

  const score = criteria.reduce((sum, c) => sum + (c.met ? c.weight : 0), 0);
  const missing = criteria.filter(c => !c.met).map(c => c.name);
  return { score, missing };
}

Real criteria never known exactly before announcement — scoring always heuristic, based on past distribution patterns of similar protocols.

Monitoring New Opportunities

Signal Sources

• Twitter/X API — search for keywords "airdrop", "snapshot", "eligible", mentions of protocols from watchlist
• Governance forums — Snapshot.org, Commonwealth, Discourse. Proposal mentioning token distribution = early signal
• GitHub activity — commits with "merkle", "airdrop", "distributor" in protocol repo
• The Graph — new subgraph deployments from watchlist protocols sometimes precede airdrop

Signals aggregated and ranked by confidence: confirmed official announcement = 100%, pattern from multiple indirect signals = 40-60%.

Protocol Database

Core of system — knowledge base about protocols and their historical airdrops. Schema:

Database must be maintained manually + automatically parsed from open sources (airdrops.io, DeFiLlama airdrop section).

Notifications and UI

User should see: which wallets potentially eligible, what actions needed to meet criteria, deadline for claim.

Notification channels: Telegram bot (most convenient for crypto audience), email, webhook for integration with external systems.

Dashboard minimal: wallet × protocol table with eligibility score, sort by estimated value, filter by status. Next.js + shadcn/ui + TanStack Table — standard choice.

Limitations and Honest Look

Tool doesn't guarantee airdrop. Criteria always published after snapshot, impossible to know exact rules in advance. Exception — Sybil-detection: most protocols filter out obvious Sybil patterns (identical amounts, created same day, linked through one address). Tool can detect such patterns in own wallet portfolio and warn.

Second limitation — data freshness. The Graph subgraphs lag by several blocks, some protocols not indexed publicly at all, then must parse contracts directly via eth_getLogs with custom ABI decoding.

Work Process

Analytics (3-4 days). List of protocols to monitor, number of wallets, target chains, notification requirements.

Backend development (3-4 weeks). Indexer → scoring engine → protocol database → notification system.

Frontend development (1-2 weeks). Dashboard, wallet management, alert settings.

Launch and database population (1 week). Add 50-100 protocols to knowledge base.

Timeline and cost depend on number of supported chains and data sources.