Разработка airdrop-фармилки (автоматизация действий)

Разработка мульти-критериального распределения airdrop

Простой airdrop по snapshot-у баланса давно не работает: боты собирают львиную долю, реальные пользователи получают крохи, а команда тратит газ на адреса, которые продадут токены в первый же час. Мульти-критериальное распределение — это система, где итоговая аллокация каждого адреса вычисляется через несколько независимых фильтров и весовых коэффициентов. Задача: вознаградить тех, кто реально взаимодействовал с протоколом, и исключить Sybil-аккаунты.

Классический пример — ENS airdrop 2021 и Uniswap 2020. Оба дали токены всем адресам с определённой историей. Более сложный подход у Arbitrum STIP и Optimism RPGF: там использовались ретроспективные метрики активности за длительный период с несколькими весовыми группами.

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

Слой сбора данных (off-chain)

Вся аналитика делается off-chain. On-chain хранить полные критерии невозможно — стоимость вычислений и storage запретительна. Схема: данные из нод (через Alchemy/QuickNode архивные ноды или The Graph субграф) → аналитический pipeline → Merkle tree → root публикуется on-chain → клейм через proof.

Типичный набор источников:

• Transaction history — все транзакции адреса с протоколом за период
• Event logs — Swap, Deposit, Borrow, Repay из контрактов протокола
• Token balances at snapshot — ERC-20 балансы на определённых блоках
• ENS / Lens / Farcaster — верификация реальной идентичности
• Cross-chain активность — деятельность на других цепях для anti-Sybil

Критерии и веса

Каждый адрес получает score по нескольким осям. Пример структуры:

Log-scale важен для объёмных метрик: без него whale с $10M объёмом получает в 10000 раз больше пользователя с $1000. С log-scale — в 4 раза. Это правильнее с точки зрения goal (вознаградить участие, не капитал).

Anti-Sybil фильтрация

Проблема Sybil — главная боль любого airdrop. Фермы создают тысячи кошельков с похожим паттерном: создан недавно, несколько транзакций в протоколе, никакой другой активности, получение токенов → немедленная продажа.

Технические признаки кластера:

• Одинаковое время создания аккаунтов (в пределах одного блока или часа)
• Общий source of funds (все funded с одного адреса)
• Идентичные паттерны транзакций (те же контракты, те же суммы)
• Отсутствие активности вне целевого протокола

Инструменты: Sardine и Chainalysis для коммерческой Sybil-детекции, MACI (Minimum Anti-Collusion Infrastructure) для более сложных случаев. Для собственной реализации — кластерный анализ через граф фондирования: если 50 адресов образуют звезду с одним центральным кошельком-спонсором, это кластер.

Merkle-дистрибьютор

Стандартная реализация — MerkleDistributor (как у Uniswap). Алгоритм:

1. Вычислить аллокации для всех адресов off-chain
2. Построить Merkle tree: каждый лист = keccak256(abi.encodePacked(address, amount))
3. Записать root в контракт
4. Пользователь клеймит, предоставляя proof (массив sibling-хешей)

function claim(uint256 index, address account, uint256 amount, bytes32[] calldata merkleProof) external {
    require(!isClaimed(index), "Already claimed");
    
    bytes32 node = keccak256(abi.encodePacked(index, account, amount));
    require(MerkleProof.verify(merkleProof, merkleRoot, node), "Invalid proof");
    
    _setClaimed(index);
    IERC20(token).safeTransfer(account, amount);
    
    emit Claimed(index, account, amount);
}

Claimed биты упаковываются в mapping(uint256 => uint256) — 256 адресов на один uint256, газ экономится на storage.

Vesting опция

Немедленный клейм всей суммы провоцирует dump. Альтернатива: линейный vesting через контракт TokenVesting или cliff + linear схема.

Пример: 10% немедленно, остальное линейно за 6 месяцев. Реализуется или отдельным vesting контрактом (пользователь клеймит → токены идут в vesting stream), или через интеграцию с Sablier v2 / LlamaPayV2 для stream-based distribution.

Процесс разработки

Аналитика (1-2 недели). Определение критериев совместно с командой протокола, выбор snapshot-блоков, написание SQL/GraphQL запросов для извлечения данных.

Pipeline и Sybil-фильтрация (1-2 недели). Python/TypeScript скрипты: сбор данных, нормализация, clustering, финальный расчёт аллокаций. Верификация результатов: топ-10 и дно-10 адресов смотрим вручную.

Смарт-контракты (1 неделя). MerkleDistributor с опциональным vesting, деплой на testnet, верификация на Etherscan/Arbiscan.

Frontend для клейма (3-5 дней). Простой интерфейс: ввод адреса → проверка аллокации → клейм через wagmi/viem. Генерация proof на клиенте из публично доступного Merkle tree.

Общая длительность от kick-off до production: 3-5 недель в зависимости от объёма on-chain данных и сложности критериев.