Розробка системи ретроактивного airdrop
Ретроактивний airdrop — один з найефективніших механізмів розподілу токенів серед реальних користувачів протоколу. Ідея проста: вознаградити тих, хто користувався продуктом до того, як з'явився токен. Uniswap розповсюдив UNI в вересні 2020 — кожен хто робив swap отримав 400 UNI. dYdX, Optimism, Arbitrum, ENS — всі побудували подібні механіки, але з різною складністю критеріїв eligibility.
Реалізація виглядає простою лише на перший погляд. За нею стоїть нетривіальна інфраструктура: збір і обробка on-chain даних, snapshot системи, перевірка Sybil-активності, Merkle tree дистрибуція, і UI для claim. Кожен з цих етапів може стати bottleneck або точкою уязвимості.
Збір даних і snapshot
Джерела даних
Основа ретроактивного airdrop — історичні on-chain дані. Потрібно відповісти на запитання: хто робив що, коли, і в якому обсязі? Для цього використовуються кілька підходів.
The Graph — індексація подій контрактів через subgraph. Якщо у протоколу вже є subgraph, історичні события (Swap, Deposit, Borrow) доступні через GraphQL. Проблема: The Graph зберігає дані з моменту деплоя subgraph, а не з початку історії блокчейну. Якщо subgraph з'явився після протоколу — ранні события можуть бути недоступні.
Direct RPC indexing — власний скрипт, який обходить блоки через eth_getLogs і збирає события. Повільно (Ethereum ~19M блоків на момент написання), вимагає архівної ноди або платного RPC (Alchemy, Infura з архівним доступом). Але повний контроль над даними.
Dune Analytics — SQL-запити до індексованих даних Ethereum. Швидко для exploration, але CSV експорт обмежений для великих датасетів. Підходить для прототипування критеріїв.
Для production airdrop на кілька тисяч адрес — рекомендую власний indexer. Stack: TypeScript + viem + PostgreSQL. Вивертаємо события батчами по 2000 блоків, зберігаємо в БД, будуємо агрегації.
Критерії eligibility
Критерії визначають хто і скільки отримує. Типові підходи:
| Дія | Вага | Приклад |
|---|---|---|
| Кількість транзакцій | Базова | ≥3 транзакцій = eligible |
| Обсяг торговлі | Лінійна/логарифмічна | $1000 обсяг = 1 балл |
| Час активності | Часові вікна | Використовував в 3+ різних місяцях |
| Ранній користувач | Бонус | До блоку X = 2x |
| Надання ліквідності | Обсяг × час | TVL × дні |
Логарифмічне масштабування обсяг запобігає домінуванню китів: score = log10(volume_usd + 1). Без цього топ-10 адрес отримають половину airdrop.
Анти-Sybil захист
Проблема Sybil-атак
Sybil — створення множини адрес для отримання більшої кількості токенів. Якщо критерій «1 транзакція = eligible», атакуючий створює 1000 гаманців і робить по одній транзакції з кожного. Це реальна проблема: при Optimism airdrop ~17% від спочатку eligible адрес були відфільтровані як Sybil.
Методи детекції
Фінансування адрес. Усі адреси Sybil-кластера отримують ETH на газ від одного джерела. Граф фінансування будується як дерево: корінь — CEX вивід або відомий гамань, листя — Sybil адреси. Якщо N адрес отримали ETH від однієї адреси і усі N робили подібні дії в подібно час — це кластер.
Часові паттерни. Sybil-скрипт створює транзакції в певному часовому вікні (поки скрипт працює). Кластер з 50 адрес, усі зробили першу транзакцію протягом 10 хвилин — підозріло.
On-chain identity. ENS імя, Lens Protocol профіль, Gitcoin Passport score — індикатори реального користувача. Адреса з ENS імям майже ніколи не є Sybil.
Мінімальний ETH баланс. Нульові гаманці після airdrop claim — ознака Sybil. Додати вимогу мінімального балансу (0.001 ETH) в момент snapshot відсікає більшість фейкових адрес.
Merkle Tree дистрибуція
Чому Merkle Tree
Наївний підхід — зберігати список eligible адрес і суми on-chain. При 100,000 адресах це ~3MB on-chain даних, вартість деплоя буде астрономічною. Merkle Tree вирішує це: корінь дерева (32 байти) зберігається в контракті, користувач надає proof при claim.
Proof — масив хешів, які разом з адресою і сумою дозволяють перетворити корінь дерева. Для N листків розмір proof — O(log N). При 1M користувачів proof містить ~20 елементів по 32 байти = 640 байт calldata.
Реалізація
Merkle tree будується off-chain з списку пар [address, amount]. Стандарт — OpenZeppelin MerkleProof бібліотека з keccak256 хешуванням:
// leaf = keccak256(abi.encodePacked(account, amount))
// подвійне хеширование запобігає second preimage attack
bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(account, amount))));
require(MerkleProof.verify(proof, merkleRoot, leaf), "Invalid proof");
Claim контракт зберігає маппінг claimed[address] => bool для запобігання повторному claim. Після claim — transfer токенів з контракту на користувача.
Часове вікно claim. Ретроактивний airdrop повинен мати deadline: 3-6 місяців достатньо. Неполучені токени повертаються в treasury або спалюються. Це запобігає вічно висячим allocations.
Frontend та UX
Мінімальний claim UI: підключення гамания → перевірка eligibility (запит до off-chain API або обчислення proof на клієнті) → відображення суми → транзакція claim. Proof можна зберігати в IPFS (публічний JSON файл) або генерувати на сервері.
Важливо: не показувати суми до публічного оголошення. Перевірка eligibility через API (без розкриття суми) дозволяє користувачам перевірити статус без розкриття повного списку до старту.
Stack та строки
Смарт-контракт (Solidity + Foundry) + off-chain indexer (TypeScript + PostgreSQL) + Merkle tree генератор + claim UI (React + wagmi).
MVP для простого airdrop з готовими даними — 2-3 тижні. Повна система з власним indexer, Sybil-детекцією і claim UI — 5-8 тижнів.