Разработка контракта launchpad: токенсейлы, whitelist, vesting

Мы проектируем launchpad контракты, которые обслуживают TVL до $50M, экономят до 40% газа за счет Merkle tree whitelist и блокируют 99% ботов через Dutch auction и anti-sniping. Если контракт не оптимизирован, газовые траты на участие могут превысить ожидания, а боты выкупают аллокации раньше реальных пользователей. Разберем, как мы строим контракты, которые выдерживают аудит и работают с TVL до миллионов долларов.

Стандартный launchpad-контракт включает seed, private и public раунды с разными ценами и лимитами. Для разграничения доступа используем Merkle tree whitelist — это в 1000 раз эффективнее хранения всех адресов on-chain. Каждый раунд имеет свои параметры: старт, цену, минимальный/максимальный лимит, общий cap. Whitelist реализован через Merkle tree, что позволяет проверять принадлежность к группе без хранения всего списка, экономя газ. KYC-проверка проходит на уровне frontend, а контракт получает Merkle root от проверенных участников.

Типичный проект включает seed-раунд для инвесторов с дисконтом, private-раунд с ограниченным доступом и public-раунд для всех. Для каждого раунда задаются сроки, цена, лимиты. Чтобы управлять доступом, мы используем Merkle tree — это позволяет пускать только тех, кто прошел KYC, не раскрывая весь список. Структура раунда выглядит так:

Как работает whitelist с Merkle tree?

struct Round {
    uint256 startTime;
    uint256 endTime;
    uint256 price;           // в stablecoin (6 decimals для USDC)
    uint256 minAllocation;
    uint256 maxAllocation;
    uint256 totalCap;
    uint256 raised;
    bytes32 merkleRoot;      // whitelist
    bool    requiresKYC;
    bool    isActive;
}

Функция participate верифицирует участника через Merkle proof и проверяет KYC. Лимиты на кошелек защищают от whale-концентрации. Алгоритм Merkle tree описан в Wikipedia.

Почему vesting — главная техническая сложность?

Большинство уязвимостей launchpad контрактов — в vesting. Edge cases: TGE часть, revoke при отзыве, precision loss. Ниже — корректная реализация claimable с учетом cliff.

function claimable(address beneficiary) public view returns (uint256) {
    VestingSchedule memory schedule = vestingSchedules[beneficiary];
    if (block.timestamp < schedule.cliffEnd) return 0;
    uint256 elapsed = block.timestamp - schedule.vestingStart;
    uint256 total = schedule.vestingEnd - schedule.vestingStart;
    uint256 vested = elapsed >= total ? schedule.totalAmount : (schedule.totalAmount * elapsed) / total;
    return vested - schedule.claimed;
}

Как избежать reentrancy в launchpad?

Reentrancy — одна из самых критичных уязвимостей смарт-контрактов. В launchpad она может возникнуть при возврате средств или при вызове external-контрактов. Мы используем модификатор nonReentrant (от OpenZeppelin) и следуем паттерну Checks-Effects-Interactions. Дополнительно все внешние вызовы производятся в конце функций, после обновления состояния.

Обработка softcap и refund

Если сумма сборов меньше softcap, активируется refund: каждый участник может вернуть свои средства. Это защищает инвесторов от неудачных раундов.

function finalizeSale() external onlyOwner {
    require(block.timestamp > saleEndTime, "Sale not ended");
    if (getTotalRaised() < softcap) {
        status = SaleStatus.Failed;
    } else {
        status = SaleStatus.Finalized;
        paymentToken.transfer(treasury, getTotalRaised());
    }
}

Anti-whale и антибот защиты

• Max allocation per wallet — базовое ограничение.
• AntiSnipe-модификатор: первые 30 секунд раунда доступны только tier-1 участникам.
• Dutch auction: цена снижается со временем, что делает ботов неэффективными.

Интеграция с токеном

Launchpad не выдает токены сразу — аллокации фиксируются, токены распределяются через vesting. Есть два подхода: pre-funded (токены переводятся на контракт заранее) или mint-on-claim (контракт получает роль MINTER и чеканит токены при клейме). Второй вариант популярнее для проектов с гибким total supply. Наш опыт показывает, что mint-on-claim снижает нагрузку на ликвидность, так как токены не блокируются заранее.

Сравнение подходов к распределению токенов

Процесс работы над IDO контрактом на Solidity

1. Аналитика: сбор требований, определение количества раундов, цен, лимитов, vesting параметров.
2. Проектирование: архитектура контракта, Merkle tree, KYC, anti-whale.
3. Реализация: написание Solidity кода с использованием Foundry, unit-тесты.
4. Аудит: статический анализ (Slither), fuzz-тестирование (Echidna), ручной review, fork testing на основной сети.
5. Деплой и запуск: развертывание на целевой сети (Ethereum, Polygon, Arbitrum), настройка Tenderly для мониторинга.

Мы гарантируем, что каждый этап проходит проверку и соответствует лучшим практикам безопасности. Наш опыт в разработке децентрализованных проектов насчитывает несколько лет, и мы всегда готовы поделиться экспертизой.

Что входит в работу

Ориентировочный срок полного цикла — 8-14 недель. Стоимость рассчитывается индивидуально в зависимости от сложности проекта.

Если вам нужен надежный launchpad контракт, получите консультацию — оценим ваш проект. Мы предоставляем launchpad разработку под ключ с полным циклом аудита и fork testing.

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