Разработка инструмента отслеживания потенциальных airdrop

Разработка инструмента отслеживания потенциальных airdrop

Airdrop-фарминг превратился в отдельную профессию. Пользователи ведут десятки кошельков, взаимодействуют с протоколами по чётким паттернам, и упускают распределения только потому что не успевают следить за анонсами. Инструмент отслеживания потенциальных airdrop автоматизирует мониторинг: собирает данные о взаимодействиях кошелька с протоколами, оценивает eligibility по известным критериям и алертит о новых возможностях.

Рынок здесь неоднородный. Есть готовые решения — Earni.fi, Metawin, DeBank portfolio — но они либо закрытые, либо не покрывают нишевые протоколы, либо не дают кастомных критериев оценки. Кастомный инструмент оправдан для фондов с большим портфелем кошельков, для команд протоколов, которые хотят анализировать собственные потенциальные распределения.

Архитектура системы

Источники данных

Инструмент работает с несколькими классами данных:

On-chain activity data — история транзакций кошелька, взаимодействия с контрактами, token balances, LP positions, NFT holdings. Получается через RPC-ноды (Alchemy, Infura, QuickNode) или специализированные индексеры.

Protocol-specific criteria — каждый протокол, анонсируя airdrop, публикует snapshot criteria. Типичные: минимальный объём торгов, количество уникальных дней активности, использование конкретных функций (borrow, не только deposit). Эти критерии нужно парсить и хранить структурированно.

Snapshot данные — многие протоколы публикуют Merkle tree с адресами и суммами до официального анонса (или в момент). The Graph subgraph-ы, IPFS, GitHub репозитории протоколов — источники для ранней проверки eligibility.

Стек индексации

Для мониторинга on-chain активности два подхода:

Polling через RPC: запрос eth_getLogs для известных контрактов, eth_getTransactionCount, balance checks. Просто, дёшево, но медленно при большом количестве кошельков и цепей.

Event streaming через Alchemy Notify / QuickNode Streams: webhook при появлении транзакции от отслеживаемого адреса. Near-realtime, но требует подписки и webhook endpoint.

Для инструмента с < 100 кошельков на 3-5 цепях: polling раз в 15-30 минут достаточно. Для 1000+ кошельков — обязательно event streaming или self-hosted нода с кастомным indexer.

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

Чистого «да/нет» недостаточно — нужен score с объяснением чего не хватает. Пример логики для протокола типа Arbitrum:

function scoreArbitrumEligibility(activity: ChainActivity): EligibilityResult {
  const criteria = [
    {
      name: 'Минимум 4 транзакции',
      met: activity.txCount >= 4,
      weight: 20,
    },
    {
      name: 'Активность в 2+ месяцах',
      met: countActiveMonths(activity) >= 2,
      weight: 25,
    },
    {
      name: 'Объём > $10,000',
      met: activity.volumeUSD >= 10000,
      weight: 30,
    },
    {
      name: 'Взаимодействие с 3+ протоколами',
      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 };
}

Реальные критерии никогда не известны точно до анонса — scoring всегда эвристический, основанный на паттернах прошлых распределений аналогичных протоколов.

Мониторинг новых возможностей

Источники сигналов

• Twitter/X API — поиск по ключевым словам «airdrop», «snapshot», «eligible», упоминания конкретных протоколов из watchlist
• Governance форумы — Snapshot.org, Commonwealth, Discourse. Proposal с упоминанием token distribution = ранний сигнал
• GitHub активность — commit с «merkle», «airdrop», «distributor» в репозитории протокола
• The Graph — новые subgraph-деплойменты протоколов из watchlist иногда предшествуют airdrop-у

Сигналы агрегируются и ранжируются по confidence: подтверждённый официальный анонс = 100%, паттерн из нескольких косвенных сигналов = 40-60%.

База данных протоколов

Ядро системы — база знаний о протоколах и их исторических airdrop-ах. Схема:

Базу нужно поддерживать вручную + автоматически парсить из открытых источников (airdrops.io, DeFiLlama airdrop раздел).

Нотификации и UI

Пользователь должен видеть: какие кошельки потенциально eligible, что нужно сделать для прохождения критериев (action items), deadline для claim.

Каналы нотификаций: Telegram bot (самый удобный для крипто-аудитории), email, webhook для интеграции с внешними системами.

Dashboard минимально: таблица кошельков × протоколов с eligibility score, сортировка по estimated value, фильтр по статусу. Next.js + shadcn/ui + TanStack Table — стандартный выбор.

Ограничения и честный взгляд

Инструмент не гарантирует airdrop. Критерии всегда публикуются после snapshot, и узнать точные правила заранее невозможно. Исключение — Sybil-detection: большинство протоколов отсекают кошельки с очевидными Sybil-паттернами (одинаковые суммы, созданы в один день, связаны через один адрес-источник). Инструмент может детектировать такие паттерны в собственном портфеле кошельков и предупреждать.

Второе ограничение — data freshness. The Graph subgraph-ы отстают на несколько блоков, некоторые протоколы не индексированы публично вообще, и тогда нужно парсить контракты напрямую через eth_getLogs с кастомной ABI декодировкой.

Процесс работы

Аналитика (3-4 дня). Список протоколов для мониторинга, количество кошельков, целевые цепи, требования к нотификациям.

Разработка backend (3-4 недели). Indexer → scoring engine → база протоколов → notification система.

Разработка frontend (1-2 недели). Dashboard, управление кошельками, настройки алертов.

Запуск и наполнение базы (1 неделя). Добавление 50-100 протоколов в базу знаний.

Сроки и стоимость зависят от количества поддерживаемых цепей и источников данных.