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

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

Простий snapshot-базований airdrop давно не працює: боти скупають левову частку, реальні користувачі отримують крохи, команда витрачає газ на адреси, які продадуть токени в перший же час. Мультикритеріальний розподіл — система, де підсумкова алокація кожної адреси обчислюється через кілька незалежних фільтрів і вагових коефіцієнтів. Завдання: вознаградити тих, хто реально взаємодіяв з протоколом, і виключити 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 важливий для обсязних метрик: без нього кит з $10M обсягом отримує в 10000 раз більше користувача з $1000. З log-scale — в 4 рази. Це правильніше з точки зору цілі (вознаградити участь, не капітал).

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

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

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

• Однакове час створення акаунтів (в межах одного блоку або години)
• Спільний source of funds (усі фундовані з однієї адреси)
• Ідентичні паттерни транзакцій (ті ж контракти, ті ж суми)
• Відсутність активності поза цільовим протоколом

Інструменти: 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 даних і складності критеріїв.