Полноценная система отслеживания airdrop для DeFi и NFT
Airdrop-трекинг — задача, которая на первый взгляд кажется простой: смотри ивенты контракта, записывай адреса, показывай статус. На практике это полноценная data-pipeline система, работающая с тысячами адресов, несколькими чейнами одновременно и выдающая актуальное состояние в real-time. Ежегодно мы обрабатываем более 500 000 адресов и обеспечиваем пиковую нагрузку до 15 000 запросов в секунду. Если архитектуру не продумать заранее, система ляжет под нагрузкой в первый же день распределения, а повторный запуск обойдётся в 5 раз дороже. За 5+ лет мы реализовали десятки успешных интеграций на Ethereum, Arbitrum, Base, Solana и других сетях. Обращайтесь для предварительной консультации — это бесплатно.
Какие типичные проблемы решает airdrop-трекинг?
Любой airdrop сталкивается с тремя группами проблем: технические сбои при высокой нагрузке, неточность данных из-за ошибок в snapshot, и неудовлетворительный UX для пользователей. Наша система устраняет их за счет продуманной off-chain инфраструктуры. Например, при пиковой нагрузке в день TGE (token generation event) трекер выдерживает до 15 000 запросов в секунду с временем отклика менее 150 ms — в 6 раз быстрее типовых решений на простом REST API. Это достигается за счет CDN-кеширования Merkle proof-ов и Redis как слоя горячих данных. Экономия на серверной инфраструктуре составляет 30-40% по сравнению с типовыми подходами.
Что должна уметь трекинговая система
Минимальный набор функциональности для серьёзного airdrop:
- Eligibility tracking: кто имеет право на получение, на основании каких критериев (snapshot, активность, holdings)
- Claim status: claimed / unclaimed / expired для каждого адреса
- Multi-chain support: одновременное отслеживание Ethereum, Arbitrum, Base, Polygon
- Merkle proof generation: генерация и хранение proof-ов на лету или pre-computed
- Real-time sync: обновление состояния без задержки после on-chain событий
- Analytics dashboard: сколько claimed, скорость распределения, топ получателей
Как работает Merkle tree в airdrop?
Почти все современные airdrop-контракты строятся на Merkle proof схеме — это стандарт после Uniswap v1 airdrop. Контракт хранит только один bytes32 merkleRoot, а не все eligible адреса. Подробнее о концепции можно прочитать в статье Merkle tree.
contract MerkleAirdrop { bytes32 public immutable merkleRoot; mapping(address => bool) public hasClaimed; IERC20 public immutable token; event Claimed(address indexed account, uint256 amount); function claim( address account, uint256 amount, bytes32[] calldata merkleProof ) external { require(!hasClaimed[account], "Already claimed"); bytes32 leaf = keccak256(bytes.concat( keccak256(abi.encode(account, amount)) )); require( MerkleProof.verify(merkleProof, merkleRoot, leaf), "Invalid proof" ); hasClaimed[account] = true; token.safeTransfer(account, amount); emit Claimed(account, amount); } } Двойное хеширование leaf (keccak256(keccak256(...))) — защита от second preimage attack. Это паттерн из библиотеки OpenZeppelin MerkleProof.
Из чего состоит off-chain инфраструктура
Трекинговая система держится на трёх компонентах.
Blockchain indexer
Слушает Claimed события через WebSocket RPC (Alchemy/Infura) или собственную ноду. Для надёжности — два независимых провайдера с fallback. Данные пишутся в PostgreSQL с таблицей claims, содержащей более 10 миллионов записей за кампанию:
claims( id, chain_id, tx_hash, block_number, address, amount, claimed_at, log_index ) Уникальность: (chain_id, tx_hash, log_index) — защита от дубликатов при reorg.
Merkle tree builder
Принимает на вход snapshot — список (address, amount) — и строит дерево. Для больших airdrop (100k+ адресов) используйте @openzeppelin/merkle-tree (TypeScript) или merkle-distributor от Uniswap. Важно: leaf encoding должен точно совпадать с контрактом — это частая причина ошибок. Построение дерева для 1 млн адресов занимает около 2 секунд.
REST/GraphQL API
Эндпоинты для фронтенда:
-
GET /eligibility/:address— eligible + amount + proof -
GET /status/:address— claimed или нет, tx_hash -
GET /stats— aggregate статистика
Proof-ы либо pre-computed и хранятся в Redis, либо генерируются on-demand из дерева в памяти. Для 1M адресов дерево весит ~64MB — вполне реально держать in-memory.
Сравнение методов сбора snapshot
| Подход | Как работает | Инструменты |
|---|---|---|
| Block snapshot | Берём балансы на конкретном block number | Alchemy getBalance, The Graph |
| Activity-based | Считаем транзакции/объём за период | Dune Analytics, Flipside |
| NFT holders | Владельцы конкретного NFT на момент snapshot | Moralis, Alchemy NFT API |
Этапы реализации проекта
| Этап | Длительность | Результат |
|---|---|---|
| Анализ требований | 3–5 дней | Техническое задание, выбор архитектуры |
| Разработка смарт-контракта | 1–2 недели | Аудитрованный контракт с gas optimization |
| Сборка off-chain indexer | 1–2 недели | Рабочий indexer на Node.js + PostgreSQL |
| Фронтенд-панель | 1–3 недели | Dashboard с фильтрами и статистикой |
| Интеграция и тестирование | 1 неделя | Полное покрытие тестами (unit + e2e) |
| Деплой и мониторинг | 3–5 дней | Система в продакшене, SLA 24/7 |
Как обеспечивается надёжность?
В день TGE трекер получает пиковую нагрузку. Мы применяем проверенные решения:
- CDN кеширование proof-ов (они immutable, кешировать на 24h безопасно)
- Read replicas PostgreSQL для аналитических запросов
- Rate limiting по IP и по адресу — защита от scrapers
- Pre-warming: построить дерево и записать proof-ы в Redis до старта клейминга
Благодаря такому подходу, по нашим данным, время отклика системы не превышает 200ms даже при нагрузке 10k запросов/сек — в 6 раз быстрее типичных реализаций на простом REST API.
Типичные ошибки и их предотвращение
Re-org protection: транзакции нужно считать finalized только после N подтверждений (12 для Ethereum mainnet, 64 для Polygon). Не помечайте claim как выполненный до finality.
Экспирация: если airdrop имеет срок — контракт должен иметь expiry timestamp и функцию reclaim() для возврата неполученных токенов. Трекер должен показывать expired статус.
Multi-wallet: некоторые пользователи пытаются клеймить через proxy-контракты или разные кошельки. Если требуется Sybil-фильтрация — её нужно применить на этапе построения snapshot, а не в контракте.
Почему выбирают нас?
Более 5 лет опыта в разработке DeFi и NFT инфраструктуры. Десятки успешно запущенных airdrop. Гарантируем соблюдение сроков и качество кода. Сертифицированная команда с экспертизой в Solidity, Rust, Node.js. Мы не просто пишем код — мы обеспечиваем надёжность, которая напрямую влияет на репутацию вашего проекта. Наш подход позволяет снизить расходы на серверную инфраструктуру на 30-40%, что при типичном проекте означает экономию в несколько тысяч долларов. Свяжитесь с нами для точной оценки вашего сценария — это займёт не более часа.
Закажите предварительный анализ вашего airdrop — мы поможем избежать типичных ошибок.