При запуске токен дропа протоколы сталкиваются с дилеммой: как раздать токены справедливо, не переплачивая за газ и не допуская злоумышленников? Автоматическая система клейма решает эту проблему, комбинируя off-chain расчёты и on-chain верификацию. Мы разрабатываем такие системы под ключ: от сбора on-chain данных до дистрибуции через Merkle Tree. Наша инфраструктура покрывает полный цикл: снепшот, антисибил-анализ, построение дерева, смарт-контракт и claim UI. За 5+ лет мы реализовали более 50 проектов, гарантируя безопасность и прозрачность. В среднем Sybil-фильтрация экономит проекту от $50,000 до $200,000 в зависимости от размера пула.
Как работает автоматический клейм airdrop?
В основе лежит дерево Меркла — криптографическая структура, позволяющая компактно хранить распределение. Leaf вычисляется как keccak256(keccak256(abi.encode(account, amount))). Контракт хранит только корень (32 байта). Для миллиона адресов proof занимает 20 хешей (640 байт calldata), что в 5000 раз дешевле хранения полного списка on-chain. Пользователь вызывает claim() с proof и получает токены.
Что даёт автоматизация клейма airdrop?
Автоматизация исключает ручные ошибки, ускоряет распределение и снижает затраты. Газовые расходы при Merkle Tree минимальны: для миллиона участников сумма газа составляет менее $10,000 при стандартных ценах. Кастомный индексер позволяет обрабатывать данные за часы, а не дни. В результате вы получаете готовую систему за 2–3 недели вместо месяцев разработки.
Экономия на газе — разработка системы автоматического
Использование Merkle Tree снижает стоимость claim до уровня одной транзакции на пользователя. Для пула в 1 млн адресов разница с полным маппингом — более $50,000 экономии. Дополнительно мы оптимизируем смарт-контракт под холодное чтение storage.
Как мы защищаем airdrop от Sybil-атак?
Проблема Sybil
Создание множества адресов для получения большего объёма токенов — реальная угроза. Согласно данным раздачи Optimism, ~17% eligible адресов были отфильтрованы как Sybil. Наше решение базируется на трёх методах:
- Финансирование адресов. Строим граф финансирования: если N адресов получили ETH от одного источника и совершали похожие действия в узком окне — они помечаются как кластер.
- Временные паттерны. Сканируем транзакции на предмет массовых регистраций за короткий промежуток. Кластер из 50 адресов, активированных в течение 10 минут — стоп-сигнал.
- On-chain identity. Учитываем ENS, Lens Profile, Gitcoin Passport. Наличие ENS имени снижает вероятность Sybil почти до нуля.
Результаты фильтрации
| Метрика |
До фильтра |
После |
| Unique адресов |
150 000 |
124 000 |
| Объём токенов (пул) |
10M |
8.3M |
| Экономия на газе (claim) |
— |
23% |
При пуле в 10M токенов фильтрация Sybil экономит проекту около $200,000. Снижение gas costs на 23% при claim дополнительно экономит ~$5,000 на этапе распределения.
Что входит в разработку системы airdrop?
- Snapshoot и индексация — сбор исторических событий через RPC или The Graph. Для больших объёмов пишем кастомный индексер на TypeScript + viem + PostgreSQL.
- Определение критериев — вес действий (объём, частота, время активности). Логарифмическое масштабирование предотвращает доминирование китов.
- Merkle Tree построение — off-chain расчёт корня, proof для каждого адреса. Стандарт OpenZeppelin с двойным хешированием.
- Смарт-контракт — Solidity + Foundry, поддержка deadline и возврат невостребованных токенов в treasury.
- Claim UI — React + wagmi + RainbowKit, проверка eligibility через API, защита от просмотра сумм до старта.
- Аудит и тестирование — формальная верификация контракта (Slither, Mythril, Echidna). Даём гарантию на код.
Пример расчёта proof
Leaf = `keccak256(keccak256(abi.encode(account, amount)))`. Контракт хранит только корень (32 байта). Размер proof для 1M адресов — 20 хешей (640 байт calldata). Это в 5000 раз дешевле хранения полного списка on-chain.Как обеспечивается безопасность смарт-контракта?
Помимо стандартных утилит (Slither, Mythril), мы проводим формальную верификацию в Echidna для fuzzing. Контракты тестируются на reentrancy, переполнение и race conditions. Для чувствительных проектов подключаем внешний аудит.
Сколько времени занимает разработка?
| Этап |
Срок |
| MVP с готовым снепшотом |
2–3 недели |
| Полная система с индексером и Sybil-защитой |
5–8 недель |
| С адаптацией под специфические критерии |
6–10 недель |
Стоимость рассчитывается индивидуально — зависит от сложности данных и функционала. Закажите оценку вашего проекта за 1 день — мы пришлём коммерческое предложение. Для оценки заполните форму на сайте, и мы свяжемся с вами в течение дня.
Наши компетенции и гарантии
Опыт в Merkle Tree и аудите смарт-контрактов. 5+ лет на рынке, 50+ реализованных airdrop. Гарантируем, что ваш токен дроп пройдёт без технических сбоев и Sybil-захвата. Получите консультацию по вашему проекту уже сегодня, оставив заявку.
Разработка токенов: ERC-20, токеномика, вестинг
«ERC-20 — это просто» — фраза, после которой начинаются проблемы. Базовый transfer написать несложно. Но токен, у которого через шесть месяцев не происходит инфляционный коллапс, governance работает как задумано, а вестинг нельзя обойти через хитрую схему с делегированием — это уже проектирование.
ERC-20: что под капотом
Стандарт ERC-20 — девять функций. Сложность начинается с расширений:
ERC-20Permit (EIP-2612) — gasless approve через подпись. Пользователь подписывает permit(owner, spender, value, deadline, v, r, s) off-chain, spender вызывает permit() + transferFrom() в одной транзакции. Это убирает отдельный approve step. Но: подпись можно перехватить и использовать — нужен deadline и проверка nonce.
ERC-20Votes (EIP-5805) — snapshot балансов для governance. Checkpoint-система хранит историю балансов по номеру блока. getPastVotes(address, blockNumber) — баланс на момент создания proposal, а не текущий. Это предотвращает flash loan governance attack: нельзя занять токены и проголосовать ими в одной транзакции.
Rebasing токены (stETH, Ampleforth) — balanceOf меняется автоматически через изменение internal shares ratio. Высокая сложность интеграции: большинство DeFi протоколов не работают корректно с rebasing без wrapping в non-rebasing версию.
Fee-on-transfer токены — при каждом transfer снимается процент. Ломают AMM расчёты: пул получает меньше, чем ожидал. Uniswap v2/v3 не поддерживают fee-on-transfer нативно — нужны специальные pair/router.
Tokenomics: где математика превращается в экономику
Токеномика — это не таблица в Excel с суммой 100%. Это модель инцентивов, которая либо работает в долгосрочной перспективе, либо создаёт давление продаж которое убьёт проект.
Emission schedule и инфляция
Фиксированный supply (Bitcoin-модель) — deflation через burn механику или просто ограниченное количество. Подходит для store-of-value или utility токенов с ограниченным спросом на новые токены.
Инфляционная модель (Ethereum post-Merge, Curve) — новые токены выпускаются для стимулирования участников. Нужен баланс: emission должен быть ниже или равен value capture протоколом. Если протокол зарабатывает $100k/месяц, а эмиссия в рыночной стоимости $500k/месяц — постоянное давление продаж неизбежно.
Halving schedules (Bitcoin-style) — уменьшение emission со временем. Создаёт предсказуемость, но требует что утилити токена росла чтобы компенсировать падающие rewards для stakers/validators.
Supply distribution
| Категория |
Типичный диапазон |
Риск |
| Команда + advisors |
15–20% |
Dumping при unlock |
| Investors (seed, private) |
15–25% |
Координированный выход |
| Treasury / DAO |
20–35% |
Governance capture |
| Ecosystem / grants |
10–20% |
Неэффективное распределение |
| Public sale / LBP |
5–15% |
Недооценка на LBP → whale capture |
| Liquidity provision |
5–10% |
Mercenary capital |
Нет универсальной формулы. Есть принцип: никакой одной сущности не должно принадлежать >33% voting power при запуске. Иначе governance — фикция.
Vesting контракты: детали имеют значение
Linear vesting с cliff — стандарт для команды и инвесторов. cliff — период после TGE, в течение которого ничего не доступно. После cliff: линейный unlock до duration.
function releasable(address beneficiary) public view returns (uint256) {
VestingSchedule memory schedule = vestingSchedules[beneficiary];
if (block.timestamp < schedule.cliff) return 0;
uint256 elapsed = block.timestamp - schedule.cliff;
uint256 vestingDuration = schedule.duration - (schedule.cliff - schedule.start);
uint256 vested = schedule.totalAmount * elapsed / vestingDuration;
return vested - schedule.released;
}
Типичные ошибки при реализации:
Revocable vesting без timelock — owner может отозвать vesting мгновенно. Если owner key скомпрометирован или команда недобросовестна — все unvested токены могут быть отозваны. Решение: revocation через multisig + governance vote.
Cliff не блокирует governance права — если используется ERC-20Votes, recipient может делегировать voting power с первого дня, даже если токены ещё не unlocked. Нужно явно разделить voting power и claim logic.
Отсутствие emergency pause — если обнаружена уязвимость в vesting контракте, нужна возможность приостановить claim. Pausable + timelock на unpause.
Liquidity Bootstrapping
Запуск ликвидности — критический момент. Три основных подхода:
Balancer LBP (Liquidity Bootstrapping Pool) — временный Balancer пул с высоким начальным весом токена (90/10 проект-токен/USDC) который автоматически снижается до 50/50 за несколько дней. Создаёт нисходящее ценовое давление, препятствуя ботам скупить всё по одной цене. После LBP ликвидность переносится в постоянный пул.
Fjord Foundry — специализированная платформа для LBP и fair launches. Меньше операционного overhead чем прямая интеграция с Balancer.
Uniswap v3 с ограниченным range — добавить ликвидность в узкий диапазон вокруг начальной цены. Высокая capital efficiency, но требует активного управления range.
TWAMM (Time-Weighted AMM) — механика для постепенной продажи/покупки больших объёмов без slippage. Paradigm предложил, реализован в FraxSwap.
Governance токены и voting механики
OpenZeppelin Governor — стандартная реализация on-chain governance. Модульная архитектура: GovernorVotes для counting, GovernorTimelockControl для timelock execution, GovernorSettings для изменяемых параметров.
Quorum — минимальный процент supply для валидности голосования. Слишком высокий quorum = apathy failure (не набирается голосов). Слишком низкий = whale capture. Compound установил quorum 400k COMP (4% supply) — на практике достигается редко без координации крупных holders.
Flash loan governance attack — атакующий занимает токены через flash loan, делегирует их себе, создаёт proposal или голосует, возвращает токены. ERC-20Votes с snapshot по номеру блока полностью блокирует это: нужно иметь токены на момент создания snapshot, который берётся в момент создания proposal.
Delegation — пользователи с малыми балансами часто не голосуют. Liquid delegation (как в Optimism) позволяет делегировать voting power конкретным addresses (delegates) без передачи ownership токенов.
Стек для токен-разработки
Контракты: Solidity 0.8.x, OpenZeppelin Contracts 5.x (ERC20, ERC20Permit, ERC20Votes, Governor, TimelockController, TokenVesting)
Аудит токеномики: Python модели с симуляцией emission/demand, cadCAD для complex systems modeling
Деплой и управление: Foundry scripts, Gnosis Safe для treasury, OpenZeppelin Defender для автоматизации
Аналитика: Dune Analytics для on-chain метрик, Token Terminal для protocol revenue
Процесс
Tokenomics design — модель supply, allocation, emission schedule, vesting. Стресс-тестирование сценариев (bear market, whale exit, governance capture attempt).
Контракт разработка — ERC-20 + extensions, vesting, governance. Foundry fuzz тесты на vesting calculations, governance thresholds.
Аудит — особое внимание на governance attack vectors, vesting bypass, permit replay attacks.
LBP / launch — выбор механики, настройка параметров, мониторинг первых 24 часов.
Post-launch — мониторинг supply distribution через Dune, governance participation metrics, treasury management.
Сроки
- ERC-20 с permit и basic governance: 2–3 недели
- Vesting контракт с revocation и cliff: 2–4 недели
- Полный governance (Governor + Timelock + Token): 4–7 недель
- Токен + LBP + governance + vesting: 8–14 недель
