Разработка системы массового распределения токенов
Массовое распределение токенов (airdrop) — операция, которая ломает проект, если подойти к ней наивно. Транзакции на десятки тысяч адресов через прямой transfer() сжигают миллионы долларов на газ и забивают блоки. Ещё хуже — атакующий с сотней сибил-адресов забирает долю, предназначенную реальным пользователям. Мы разрабатываем системы, которые решают обе проблемы: экономят до 70% газа и отсеивают до 99% сибилов. Наш опыт — более 7 лет, более 50 запущенных проектов с суммарным распределением $50M+.
Ключевые вызовы при массовом распределении токенов
Выбор подхода — push или pull — определяет бюджет и UX. На Ethereum mainnet при 50 000 получателях и цене газа $20/Gwei direct transfer обойдётся в $50 000+ только на комиссиях. При pull-сценарии пользователь оплачивает газ сам, но чтобы claim принес 10 000 человек, нужно демотивировать сибилов. Вторая проблема — атакующие создают тысячи кошельков, выполняют минимальную активность и получают непропорциональную долю. Для защиты мы используем комбинацию: on-chain фильтры (возраст кошелька, история транзакций, объём комиссий) и off-chain верификацию через Gitcoin Passport или социальные сети с подписью. Tiered-распределение (ранние участники получают в 3x больше) делает сибил-атаку экономически невыгодной.
Merkle drop: стандарт массового распределения
Список получателей упаковывается в Merkle tree, на блокчейне хранится только root. Пользователь предоставляет proof своего права на токены. Это золотой стандарт для крупных airdrop: затраты газа минимальны, а доказательство можно проверить on-chain. Вот как выглядит базовая реализация:
contract MerkleDistributor { address public immutable token; bytes32 public immutable merkleRoot; mapping(uint256 => uint256) private claimedBitMap; event Claimed(uint256 indexed index, address indexed account, uint256 amount); constructor(address token_, bytes32 merkleRoot_) { token = token_; merkleRoot = merkleRoot_; } function isClaimed(uint256 index) public view returns (bool) { uint256 claimedWordIndex = index / 256; uint256 claimedBitIndex = index % 256; uint256 claimedWord = claimedBitMap[claimedWordIndex]; uint256 mask = (1 << claimedBitIndex); return claimedWord & mask == mask; } 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).transfer(account, amount); emit Claimed(index, account, amount); } function _setClaimed(uint256 index) private { uint256 claimedWordIndex = index / 256; uint256 claimedBitIndex = index % 256; claimedBitMap[claimedWordIndex] |= (1 << claimedBitIndex); } } Битовая карта вместо mapping(address => bool) экономит существенный объём storage, особенно при сотнях тысяч получателей. Для генерации дерева off-chain используем библиотеку OpenZeppelin MerkleProof.
Как Merkle drop решает проблему газа?
Меркл-дерево позволяет не хранить полный список на блокчейне. Вместо этого — только корень (32 байта). Пользователь доказывает свою долю, предоставляя proof размером ~2–12 хешей. Затраты газа на claim составляют ~50 000 gas, что в десятки раз меньше, чем при push-подходе. Merkle drop выигрывает по газу в 3–5 раз по сравнению с batch transfer при списках от 10 000 адресов.
Как мы проектируем систему: на практике
Для одного крупного DeFi-проекта мы внедрили гибридную схему: 40% токенов распределялись через Merkle drop без KYC, 60% — через интерфейс с Gitcoin Passport. Результат: 92% адресов из whitelist заклеймили токены в первую неделю, 97% из них не продали на DEX в течение месяца. Тематические охоты (snapshot hunters) потеряли 80% своей доли из-за tiered-множителей.
| Категория | Критерий | Множитель |
|---|---|---|
| OG users | Первая транзакция > 12 месяцев назад | 3x |
| Active users | > 10 транзакций за последние 6 месяцев | 2x |
| Regular users | Хотя бы 1 транзакция за последние 3 месяца | 1x |
| Snapshot hunters | Транзакция за последние 2 недели | 0.5x |
Для push-сценариев (компенсация после exploit, retroactive rewards) используем batch transfer с батчами по 200–500 адресов. Оптимальный размер рассчитывается под block gas limit сети — на Polygon это 600–800 адресов, на Ethereum — 250–300.
function disperseToken( IERC20 token, address[] calldata recipients, uint256[] calldata amounts ) external { uint256 total = 0; for (uint256 i = 0; i < amounts.length; i++) { total += amounts[i]; } token.transferFrom(msg.sender, address(this), total); for (uint256 i = 0; i < recipients.length; i++) { token.transfer(recipients[i], amounts[i]); } } Сравнение подходов: push, pull, Merkle drop
| Подход | Газ (проект) | UX | Sybil-резистентность |
|---|---|---|---|
| Push | Очень высокий | Высокий | Нет |
| Pull (batch) | Средний | Средний | Нет |
| Merkle drop | Низкий | Средний | Возможна |
Vesting: защита от давления на цену
Для команд и инвесторов комбинируем mass-claim с персональными VestingWallet. При claim создаётся контракт с расписанием (cliff + linear vesting). Это предотвращает dump-напор на цену. Газ на деплой каждого vesting-контракта компенсируется тем, что пользователи платят за claim сами. Vesting распределяет разблокировку по времени. Например, cliff 3 месяца + равномерное разблокирование за 12 месяцев. Это снижает волатильность и поощряет долгосрочное удержание.
Как мы строим Merkle tree: пошаговая инструкция
- Собираем список адресов и сумм из базы данных (CSV или скрипт).
- Строим Merkle tree с помощью библиотеки OpenZeppelin MerkleProof (ethers.js или Foundry).
- Деплоим контракт MerkleDistributor с корнем дерева и адресом токена.
- Публикуем дерево в IPFS или на сайте для скачивания proofs.
- Пользователи клеймят токены, предоставляя proof.
Что входит в работу
- Анализ требований: список получателей, категории, vesting-условия, метод sybil-защиты.
- Архитектурный дизайн: Merkle drop или batch transfer, L1 или L2.
- Разработка смарт-контрактов: Solidity 0.8.x, Foundry, unit-тесты, fork-тесты, fuzzing.
- Генерация Merkle tree: off-chain на ethers.js, валидация proof.
- Аудит безопасности: Slither, Mythril, Echidna — ищем reentrancy, storage collision, gas-утечки.
- Деплой через multi-sig: временный lock на 24 часа для отката.
- Мониторинг: Tenderly и Dune — процент claimed, адреса-снайперы, retention.
- Документация и обучение: API для frontend, инструкция по администрированию.
Сроки и бюджет
Базовый Merkle distributor с frontend (React + RainbowKit) — 3–4 недели. Полноценная система с sybil-защитой, tiered-распределением, vesting и dashboard — 2–3 месяца. Стоимость рассчитывается индивидуально. Свяжитесь с нами для оценки вашего проекта. Получите консультацию по архитектуре.