Розробка інструменту відстеження потенційних airdrop

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

Airdrop-фарминг перетворився на окрему професію. Користувачі ведуть десятки гаманців, взаємодіють з протоколами за чіткими паттернами, і пропускають розподіли лише тому що не встигають слідкувати за оголошеннями. Інструмент відстеження потенціальних airdrop автоматизує моніторинг: збирає дані про взаємодії гамания з протоколами, оцінює eligibility за відомими критеріями і алертує про нові можливості.

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

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

Джерела даних

Інструмент працює з кількома класами даних:

On-chain activity data — історія транзакцій гамания, взаємодії з контрактами, token balances, LP позиції, NFT holdings. Отримується через RPC-ноди (Alchemy, Infura, QuickNode) або спеціалізовані indexers.

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

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

Stack індексації

Для моніторингу 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, що потрібно зробити для прохождення критеріїв, 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 протоколів до бази знань.

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