Розробка інструменту відстеження потенціальних airdrop
Airdrop-фарминг перетворився на окрему професію. Користувачі ведуть десятки гаманців, взаємодіють з протоколами за чіткими паттернами, і пропускають розподіли лише тому що не встигають слідкувати за оголошеннями. Наш інструмент відстеження потенціальних airdrop автоматизує весь цикл моніторингу: збирає on-chain дані про взаємодії гаманців з протоколами, оцінює eligibility за відомими критеріями, алертує про нові можливості та розраховує потенційний прибуток від кожного airdrop-розподілу. Це особливо корисно для команд і фондів, що керують великими портфелями гаманців.
Ринок тут неоднорідний. Є готові рішення — Earni.fi, Metawin, DeBank portfolio — але вони або закриті, або не покривають нішеві протоколи, або не дають кастомних критеріїв оцінки. Кастомний інструмент під ключ виправданий для фондів з великим портфелем гаманців та для команд протоколів, які хочуть аналізувати власні потенційні розподіли і налаштовувати критерії eligibility під конкретну стратегію.
Архітектура системи
Джерела даних
Інструмент працює з кількома класами даних:
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 завжди евристичний, на основі паттернів минулих розподілів аналогічних протоколів.
Моніторинг нових можливостей
Джерела сигналів для відстеження airdrop
- 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-и. Схема:
| Поле | Тип | Описання |
|---|---|---|
| protocol_id | uuid | |
| name | text | Uniswap, dYdX, Arbitrum |
| category | enum | dex, lending, l2, bridge |
| chains | int[] | chainId масив |
| past_airdrops | jsonb | історичні розподіли |
| known_criteria | jsonb | відомі критерії eligibility |
| snapshot_contract | text | адреса distributor якщо відома |
| watchlist_priority | int | 1-10 |
Базу потрібно підтримувати вручну + автоматично парсити з відкритих джерел (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 протоколів до бази знань.
Строки і вартість залежать від кількості підтримуваних чейнів і джерел даних. Напишіть нам — оцінимо проект безкоштовно і запропонуємо оптимальне рішення.