Airdrop-кампании: разработка систем распределения токенов

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Airdrop-кампании: разработка систем распределения токенов
Средний
~3-5 дней
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1360
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    957
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929

Представьте: вы запускаете retroactive airdrop для 200 000 адресов. Наивный подход — 200 000 вызовов transfer — обойдётся в миллионы долларов газа, а боты с 10 000 сибил-адресов выкачают половину токенов ещё до того, как реальные пользователи успеют клейм. Именно здесь на помощь приходит Merkle Distributor. Он позволяет каждому получателю самостоятельно запросить токены, предоставив доказательство включения, при этом контракт хранит всего один root хеш. Сравнение: Merkle Distributor уменьшает газовые затраты в 1000+ раз относительно побайтового перебора. Но airdrop — это не только контракт. Защита от Sybil-атак, вестинг для удержания токенов, интерфейс клейма и аналитика — каждая деталь решает успех распределения. Мы разрабатываем системы airdrop-кампаний под ключ: от smart-контрактов до фронтенда.

Как работает Merkle Distributor?

Наивный подход — вызвать transfer на каждый адрес. При 100 000 получателей это 100 000 транзакций, огромный газ и точка отказа. Merkle Distributor решает проблему: получатели сами клеймят токены, предоставляя Merkle proof.

Off-chain: формируем список (address → amount), строим Merkle tree, публикуем root в контракт. On-chain: пользователь предоставляет proof, контракт верифицирует и выдаёт токены.

contract MerkleDistributor {
    address public immutable token;
    bytes32 public immutable merkleRoot;

    mapping(uint256 => uint256) private claimedBitMap;

    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 _setClaimed(uint256 index) private {
        uint256 claimedWordIndex = index / 256;
        uint256 claimedBitIndex = index % 256;
        claimedBitMap[claimedWordIndex] |= (1 << claimedBitIndex);
    }

    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).safeTransfer(account, amount);
        emit Claimed(index, account, amount);
    }
}

Bitfield vs mapping: хранение claimed status в packed bitfield экономит ~80% gas на SSTORE/SLOAD.

Типы airdrop и их применение:

Тип Описание Примеры Когда использовать
Retroactive Для существующих пользователей UNI, ARB, OP Стимулирование early adopters
Task-based За выполнение заданий Galxe, Layer3 Привлечение новой аудитории
Vested Токены с вестингом Linear vesting 12 мес Долгосрочная лояльность

Как защитить airdrop от Sybil-атак?

Sybil filtering — главная техническая задача retroactive airdrop. Один человек с 1000 адресов не должен получить в 1000 раз больше. Потери от Sybil-атак достигают $10M. Признаки кластеров:

  • Адреса получают ETH с одного funding source
  • Одинаковые паттерны транзакций
  • Минимальные транзакции для выполнения критериев

Используем Dune Analytics или собственный indexed node для off-chain анализа. Для сложных кейсов — Chainalysis Sybil.

Task-based airdrop: пользователь выполняет задания (Twitter, Discord, testnet). Проблема — боты. Задания должны требовать on-chain активности. По желанию интегрируем Galxe или Layer3 — минус: платформа берёт fee, пользователи остаются там.

Метод Сложность Эффективность Стоимость
On-chain кластеризация Средняя Высокая Низкая
Chainalysis Sybil Высокая Очень высокая Высокая
CAPTCHA Низкая Низкая Очень низкая

Почему стоит использовать vesting?

Vested airdrop с cliff + linear (например, 3 месяца cliff, 9 месяцев linear) снижает immediate dump на 70% (Token Engineering Commons): пользователи не могут продать всё сразу, становятся долгосрочными holders. Пример контракта:

contract VestedAirdrop is MerkleDistributor {
    uint256 public immutable vestingStart;
    uint256 public immutable vestingDuration;
    mapping(address => uint256) public claimed;
    mapping(address => uint256) public totalAllocated;

    function claimVested(
        uint256 index,
        address account,
        uint256 totalAmount,
        bytes32[] calldata merkleProof
    ) external {
        if (totalAllocated[account] == 0) _verifyAndSetAllocation(index, account, totalAmount, merkleProof);
        uint256 vested = _vestedAmount(account);
        uint256 claimable = vested - claimed[account];
        require(claimable > 0, "Nothing to claim");
        claimed[account] += claimable;
        IERC20(token).safeTransfer(account, claimable);
        emit VestedClaimed(account, claimable);
    }

    function _vestedAmount(address account) internal view returns (uint256) {
        if (block.timestamp < vestingStart) return 0;
        uint256 elapsed = block.timestamp - vestingStart;
        if (elapsed >= vestingDuration) return totalAllocated[account];
        return totalAllocated[account] * elapsed / vestingDuration;
    }
}

Технические детали

Система начисления баллов

Для сложных кампаний с множеством действий — off-chain система баллов. Используем квадратный корень (quadratic voting) для анти-whale: whale с 10 000 очков получит только в ~3.16x больше, чем пользователь с 1 000.

function calculateAllocation(points: number, totalPoints: number): bigint {
  const sqrtScore = Math.sqrt(points);
  const totalSqrtScore = /* sum for all users */ 0;
  const allocation = (TOTAL_AIRDROP_AMOUNT * BigInt(Math.floor(sqrtScore * 1e18)))
    / BigInt(Math.floor(totalSqrtScore * 1e18));
  return allocation;
}

Gas optimization для mass claiming

  • EIP-2612 Permit: одна подпись вместо отдельной approve транзакции.
  • Batch claiming: один transfer вместо N для множественных allocations.
  • Bitfield: экономия 80% gas.

Экономия на газе может превышать $500k для массового claim.

Frontend для airdrop

Eligibility checker — ввод адреса, проверка через API или Merkle tree. Snapshot публикуем в открытом доступе (GitHub, IPFS) для прозрачности.

async function checkEligibility(address: string) {
  const normalizedAddress = ethers.getAddress(address);
  const allocation = await fetchAllocation(normalizedAddress);
  if (!allocation) return { eligible: false, amount: 0n, proof: [] };
  const proof = getMerkleProof(merkleTree, allocation.index, normalizedAddress, allocation.amount);
  const alreadyClaimed = await distributor.isClaimed(allocation.index);
  return { eligible: true, amount: allocation.amount, proof, alreadyClaimed };
}

Expiry и unclaimed tokens

Устанавливаем expiry на 1 год. Unclaimed токены возвращаются в treasury или сжигаются. Airdrop без срока годности — это бомба замедленного действия для казначейства (Token Engineering Commons).

Процесс работы и что входит

  • Аналитика — разбор требований, on-chain данных вашего протокола, оценка eligibility критериев.
  • Проектирование — архитектура смарт-контрактов, схема данных, UX фронтенда.
  • Реализация — написание контрактов, фронтенда, настройка бэкенда для Sybil detection.
  • Тестирование — unit тесты, форк mainnet, формальная верификация.
  • Деплой — на staging и mainnet, проверка транзакций.
  • Запуск — публикация Merkle tree, on-chain распределение, мониторинг.

Входит: аудит и проектирование smart-контрактов (Merkle Distributor, vesting, batch claim), написание и деплой (Solidity, Foundry, Hardhat), верстка фронтенда (React, Next.js, RainbowKit), интеграция с wallet (MetaMask, WalletConnect, Coinbase Wallet), аналитика (Dune, собственный дашборд), тестирование (Slither, Mythril, Echidna fuzzing), документация и обучение команды, поддержка после запуска (3 месяца).

Сроки: от 2 недель (базовый Merkle Distributor) до 8+ недель (с vested, task-based, аналитикой). Стоимость рассчитываем индивидуально после аудита проекта. Свяжитесь с нами для оценки вашего проекта за 2 дня.

Наши компетенции

  • 5+ лет в блокчейн-разработке (Ethereum, Polygon, Arbitrum, Solana, BNB Chain)
  • 50+ успешных airdrop-кампаний с общим объёмом распределения > $100M
  • Аудиты смарт-контрактов от CertiK и Hacken
  • Работаем с OpenZeppelin Contracts и Merkle tree

Закажите разработку — защитите токены от ботов. Получите консультацию по вашему проекту — оценим airdrop за 2 дня.

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