Разработка системы массового распределения токенов: MerkleDrop и Vesting

Разработка системы массового распределения токенов

Массовое распределение токенов (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-множителей.

Для 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

Vesting: защита от давления на цену

Для команд и инвесторов комбинируем mass-claim с персональными VestingWallet. При claim создаётся контракт с расписанием (cliff + linear vesting). Это предотвращает dump-напор на цену. Газ на деплой каждого vesting-контракта компенсируется тем, что пользователи платят за claim сами. Vesting распределяет разблокировку по времени. Например, cliff 3 месяца + равномерное разблокирование за 12 месяцев. Это снижает волатильность и поощряет долгосрочное удержание.

Как мы строим Merkle tree: пошаговая инструкция

1. Собираем список адресов и сумм из базы данных (CSV или скрипт).
2. Строим Merkle tree с помощью библиотеки OpenZeppelin MerkleProof (ethers.js или Foundry).
3. Деплоим контракт MerkleDistributor с корнем дерева и адресом токена.
4. Публикуем дерево в IPFS или на сайте для скачивания proofs.
5. Пользователи клеймят токены, предоставляя 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 месяца. Стоимость рассчитывается индивидуально. Свяжитесь с нами для оценки вашего проекта. Получите консультацию по архитектуре.

Разработка токенов: 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

Нет универсальной формулы. Есть принцип: никакой одной сущности не должно принадлежать >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 недель