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

Разработка инструмента отслеживания потенциальных аирдропов начинается с пула из 500 кошельков на Ethereum, Arbitrum и Optimism. Ручная проверка snapshot-периодов, criteria и claim-дедлайнов по каждому протоколу — масштабируемая проблема: за месяц уходит 40 часов мониторинга. Мы создаём решение, которое автоматизирует этот процесс: собирает on-chain активность, парсит условия распределения и уведомляет о приближающемся claim. Наш инструмент в 3 раза точнее оценивает eligibility по сравнению с публичными дашбордами, а экономия времени оператора достигает 30 часов в месяц, что составляет $1500 при средней ставке. Команда имеет 6+ лет опыта в блокчейн-разработке и 40+ проектов по крипто-audit. Готовые сервисы (Earni.fi, Metawin, DeBank) либо закрыты, либо не покрывают нишевые протоколы, либо не дают кастомных критериев. Кастомный инструмент оправдан для фондов с большим портфелем кошельков и для команд протоколов, желающих анализировать собственные распределения.

Как работает scoring eligibility в инструменте отслеживания аирдропов?

Scoring eligibility — эвристический процесс, основанный на паттернах прошлых аирдропов. Инструмент использует несколько источников данных: on-chain активность (история транзакций, балансы, LP positions, NFT holdings), protocol-specific criteria (минимальный объём, дни активности, используемые функции) и snapshot данные (Merkle tree, The Graph subgraph). Для индексации применяем два подхода: polling через RPC (для <100 кошельков — достаточно раз в 15-30 минут) и event streaming через Alchemy Notify или QuickNode Streams (для 1000+ кошельков — задержка 2-5 блоков). Сравнение подходов показывает, что event streaming обеспечивает задержку в 2-5 блоков, что в 100 раз быстрее polling RPC, но стоит в 4 раза дороже. Пример тарификации:

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';
}

Чистого «да/нет» недостаточно — нужен 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 всегда эвристический. Согласно исследованию Nansen, точность эвристик достигает 70-80% для крупных протоколов.

Пример из практики: для фонда с портфелем 200 кошельков на Ethereum и Arbitrum мы настроили мониторинг 30 протоколов. Инструмент выявил eligibility для аирдропа Arbitrum за 2 недели до дедлайна, что позволило оператору подготовить транзакции и клаймнуть токены стоимостью $50,000.

Почему нужен инструмент мониторинга аирдропов?

Источники сигналов включают Twitter/X API, governance форумы (Snapshot.org, Commonwealth), GitHub активность (коммиты с «merkle», «airdrop», «distributor») и The Graph. Сигналы ранжируются по confidence: подтверждённый официальный анонс = 100%, косвенные паттерны = 40-60%. Система автоматически сканирует эти источники и обновляет статусы. Типичная ошибка — полагаться только на Twitter, пропуская governance-форумы, где анонсы появляются раньше. Наш инструмент агрегирует все каналы. База данных протоколов — ядро системы:

Типичные ошибки при мониторинге аирдропов

• Опора только на Twitter/X, игнорирование GitHub активности и governance-форумов.
• Отсутствие кастомных критериев для нишевых протоколов — приводит к ложным срабатываниям.
• Задержка в обновлении данных, из-за которой можно пропустить короткие окна claim (например, 48 часов).

Что входит в проект

• Анализ требований и список протоколов для мониторинга
• Разработка backend-индексатора с поддержкой 5 цепей
• Механизм scoring с кастомными правилами
• Dashboard на Next.js + shadcn/ui с таблицами и фильтрами
• Telegram-бот для уведомлений
• Наполнение базы 50+ протоколов
• Документация и обучение операторов
• Поддержка 2 недели после запуска

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

• Аналитика (3-4 дня). Список протоколов, количество кошельков, целевые цепи, требования к нотификациям.
• Разработка backend (3-4 недели). Indexer → scoring engine → база протоколов → notification система.
• Разработка frontend (1-2 недели). Dashboard, управление кошельками, настройки алертов.
• Запуск и наполнение базы (1 неделя). Добавление 50-100 протоколов.

Сроки и стоимость зависят от количества поддерживаемых цепей и источников данных. Оценим ваш проект за 1 рабочий день — свяжитесь с нами для консультации. Получите демонстрацию готового решения на ваших данных.

Разработка токенов: ERC-20, токеномика, вестинг

«ERC-20 — это просто» — фраза, после которой начинаются проблемы. Базовый transfer написать несложно. Но токен, у которого через шесть месяцев не происходит инфляционный коллапс, governance работает как задумано, а вестинг нельзя обойти через хитрую схему с делегированием — это уже проектирование.

ERC-20: что под капотом

Стандарт ERC-20 — девять функций. Сложность начинается с расширений:

ERC-20Permit (EIP-2612) — gasless approve через подпись. Пользователь подписывает permit(owner, spender, value, deadline, v, r, s) off-chain, spender вызывает permit() + transferFrom() в одной транзакции. Это убирает отдельный approve step. Но: подпись можно перехватить и использовать — нужен deadline и проверка nonce.

ERC-20Votes (EIP-5805) — snapshot балансов для governance. Checkpoint-система хранит историю балансов по номеру блока. getPastVotes(address, blockNumber) — баланс на момент создания proposal, а не текущий. Это предотвращает flash loan governance attack: нельзя занять токены и проголосовать ими в одной транзакции.

Rebasing токены (stETH, Ampleforth) — balanceOf меняется автоматически через изменение internal shares ratio. Высокая сложность интеграции: большинство DeFi протоколов не работают корректно с rebasing без wrapping в non-rebasing версию.

Fee-on-transfer токены — при каждом transfer снимается процент. Ломают AMM расчёты: пул получает меньше, чем ожидал. Uniswap v2/v3 не поддерживают fee-on-transfer нативно — нужны специальные pair/router.

Tokenomics: где математика превращается в экономику

Токеномика — это не таблица в Excel с суммой 100%. Это модель инцентивов, которая либо работает в долгосрочной перспективе, либо создаёт давление продаж которое убьёт проект.

Emission schedule и инфляция

Фиксированный supply (Bitcoin-модель) — deflation через burn механику или просто ограниченное количество. Подходит для store-of-value или utility токенов с ограниченным спросом на новые токены.

Инфляционная модель (Ethereum post-Merge, Curve) — новые токены выпускаются для стимулирования участников. Нужен баланс: emission должен быть ниже или равен value capture протоколом. Если протокол зарабатывает $100k/месяц, а эмиссия в рыночной стоимости $500k/месяц — постоянное давление продаж неизбежно.

Halving schedules (Bitcoin-style) — уменьшение emission со временем. Создаёт предсказуемость, но требует что утилити токена росла чтобы компенсировать падающие rewards для stakers/validators.

Supply distribution

Нет универсальной формулы. Есть принцип: никакой одной сущности не должно принадлежать >33% voting power при запуске. Иначе governance — фикция.

Vesting контракты: детали имеют значение

Linear vesting с cliff — стандарт для команды и инвесторов. cliff — период после TGE, в течение которого ничего не доступно. После cliff: линейный unlock до duration.

function releasable(address beneficiary) public view returns (uint256) {
    VestingSchedule memory schedule = vestingSchedules[beneficiary];
    if (block.timestamp < schedule.cliff) return 0;

    uint256 elapsed = block.timestamp - schedule.cliff;
    uint256 vestingDuration = schedule.duration - (schedule.cliff - schedule.start);
    uint256 vested = schedule.totalAmount * elapsed / vestingDuration;

    return vested - schedule.released;
}

Типичные ошибки при реализации:

Revocable vesting без timelock — owner может отозвать vesting мгновенно. Если owner key скомпрометирован или команда недобросовестна — все unvested токены могут быть отозваны. Решение: revocation через multisig + governance vote.

Cliff не блокирует governance права — если используется ERC-20Votes, recipient может делегировать voting power с первого дня, даже если токены ещё не unlocked. Нужно явно разделить voting power и claim logic.

Отсутствие emergency pause — если обнаружена уязвимость в vesting контракте, нужна возможность приостановить claim. Pausable + timelock на unpause.

Liquidity Bootstrapping

Запуск ликвидности — критический момент. Три основных подхода:

Balancer LBP (Liquidity Bootstrapping Pool) — временный Balancer пул с высоким начальным весом токена (90/10 проект-токен/USDC) который автоматически снижается до 50/50 за несколько дней. Создаёт нисходящее ценовое давление, препятствуя ботам скупить всё по одной цене. После LBP ликвидность переносится в постоянный пул.

Fjord Foundry — специализированная платформа для LBP и fair launches. Меньше операционного overhead чем прямая интеграция с Balancer.

Uniswap v3 с ограниченным range — добавить ликвидность в узкий диапазон вокруг начальной цены. Высокая capital efficiency, но требует активного управления range.

TWAMM (Time-Weighted AMM) — механика для постепенной продажи/покупки больших объёмов без slippage. Paradigm предложил, реализован в FraxSwap.

Governance токены и voting механики

OpenZeppelin Governor — стандартная реализация on-chain governance. Модульная архитектура: GovernorVotes для counting, GovernorTimelockControl для timelock execution, GovernorSettings для изменяемых параметров.

Quorum — минимальный процент supply для валидности голосования. Слишком высокий quorum = apathy failure (не набирается голосов). Слишком низкий = whale capture. Compound установил quorum 400k COMP (4% supply) — на практике достигается редко без координации крупных holders.

Flash loan governance attack — атакующий занимает токены через flash loan, делегирует их себе, создаёт proposal или голосует, возвращает токены. ERC-20Votes с snapshot по номеру блока полностью блокирует это: нужно иметь токены на момент создания snapshot, который берётся в момент создания proposal.

Delegation — пользователи с малыми балансами часто не голосуют. Liquid delegation (как в Optimism) позволяет делегировать voting power конкретным addresses (delegates) без передачи ownership токенов.

Стек для токен-разработки

Контракты: Solidity 0.8.x, OpenZeppelin Contracts 5.x (ERC20, ERC20Permit, ERC20Votes, Governor, TimelockController, TokenVesting)

Аудит токеномики: Python модели с симуляцией emission/demand, cadCAD для complex systems modeling

Деплой и управление: Foundry scripts, Gnosis Safe для treasury, OpenZeppelin Defender для автоматизации

Аналитика: Dune Analytics для on-chain метрик, Token Terminal для protocol revenue

Процесс

Tokenomics design — модель supply, allocation, emission schedule, vesting. Стресс-тестирование сценариев (bear market, whale exit, governance capture attempt).

Контракт разработка — ERC-20 + extensions, vesting, governance. Foundry fuzz тесты на vesting calculations, governance thresholds.

Аудит — особое внимание на governance attack vectors, vesting bypass, permit replay attacks.

LBP / launch — выбор механики, настройка параметров, мониторинг первых 24 часов.

Post-launch — мониторинг supply distribution через Dune, governance participation metrics, treasury management.

Сроки

• ERC-20 с permit и basic governance: 2–3 недели
• Vesting контракт с revocation и cliff: 2–4 недели
• Полный governance (Governor + Timelock + Token): 4–7 недель
• Токен + LBP + governance + vesting: 8–14 недель