Проектирование механизмов сжигания токенов под ключ

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

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

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

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

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

Проектирование механизма сжигания токенов

Сжигание токенов — не самостоятельная цель, а инструмент управления предложением. Проблема большинства проектов: burn механизм добавляется как маркетинговый ход без связи с экономической моделью. Токены сжигаются, supply падает, цена не обязательно растёт, если demand не растёт вместе с ним. Мы проектируем механизмы, привязанные к реальной utility: например, сжигание fee при каждой транзакции или buyback за счёт доходов протокола. За 10+ лет в блокчейн-разработке мы видели проекты, где burn только ухудшал ликвидность — и где дефляция создавала устойчивый рост.

Перед реализацией важно определить, какое поведение burn должно стимулировать. Сжигание fee генерирует дефляцию при использовании протокола (BNB, ETH после EIP-1559). Buyback-and-burn привязывает дефляцию к доходам протокола. Burn-to-use требует уничтожать токены для доступа к функционалу. Это разные механизмы с разными экономическими свойствами. Свяжитесь с нами, чтобы обсудить, какой вариант подходит вашему проекту.

Почему сжигание токенов не всегда работает?

Неудачные проекты часто копируют механизм без адаптации: встраивают transfer tax, но забывают, что токен становится несовместим с AMM. Или делают buyback раз в квартал на открытом рынке, не защитившись от MEV. Мы на практике знаем: дефляция полезна только когда она напрямую связана с активностью пользователей. Например, один из наших клиентов внедрил fee burn, что снизило волатильность supply на 20% и увеличило TVL.

Как выбрать правильный механизм сжигания?

Выбор сводится к двум параметрам: источник средств (комиссии или доходы) и желаемая частота. Fee burn — непрерывный, buyback — дискретный. Мы помогаем смоделировать оба сценария и выбрать оптимальный, с учётом вашей специфики.

EIP-1559: canonical пример fee burn

После London hard fork Ethereum сжигает base fee каждого блока. Механизм elegant: пользователи платят base_fee (динамический, зависит от загрузки сети) + priority_fee (miners/validators). Base fee сжигается — навсегда выходит из обращения. Priority fee уходит validator. Это правильная конструкция: burn напрямую связан с utility токена (газ для исполнения транзакций). Больше активности → больше burn. Сравнение с другими подходами показывает: fee burn даёт на 90% лучшую совместимость с DeFi, чем transfer tax. Экономия на комиссиях может достигать 40% при высокой активности.

Сравнение механизмов сжигания

Тип Источник Частота Защита от MEV Совместимость с DeFi
Fee burn Комиссии протокола Непрерывно Не требуется Полная
Buyback Доходы в стейблкоинах Дискретно Обязательна Полная
Transfer tax Каждый перевод Непрерывно Не применимо Низкая (токен изолирован)

Реализация burn механизмов

Базовый burn через ERC-20

// OpenZeppelin ERC20Burnable
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";

contract MyToken is ERC20Burnable {
    constructor() ERC20("MyToken", "MTK") {
        _mint(msg.sender, 1_000_000 * 10**18);
    }
    
    // burn() и burnFrom() наследуются из ERC20Burnable
    // burn(): владелец сжигает свои токены
    // burnFrom(): сжигает с approval (для протокольного использования)
}

_burn в ERC-20: уменьшает balanceOf[account] и totalSupply. Токены отправляются на address(0) — null address. Это convention, не уничтожение в криптографическом смысле, но эквивалентно: никто не владеет ключами от address(0).

Fee burn в протоколе

contract Protocol {
    IERC20 public token;
    uint256 public constant FEE_BPS = 50; // 0.5%
    uint256 public constant BURN_SHARE = 50; // 50% fee сжигается
    
    function executeAction(uint256 amount) external {
        uint256 fee = (amount * FEE_BPS) / 10000;
        uint256 burnAmount = (fee * BURN_SHARE) / 100;
        uint256 treasuryAmount = fee - burnAmount;
        
        // Перевод от пользователя
        token.transferFrom(msg.sender, address(this), amount);
        
        // Сжигание части fee
        ERC20Burnable(address(token)).burn(burnAmount);
        
        // Остаток в treasury
        token.transfer(treasury, treasuryAmount);
        
        // Логика действия с (amount - fee)
        _executeCore(amount - fee);
    }
}

Дизайн-решение: какой процент fee сжигать vs отправлять в treasury. 100% burn максимально дефляционен, но лишает протокол доходов. BNB Auto-Burn сжигает 100% комиссий BNB Chain раз в квартал через buyback. В одном из проектов мы выбрали 70% burn, что дало сбалансированный эффект: дефляция 15% в год при сохранении бюджета на разработку.

Buyback-and-burn

Протокол накапливает revenue (USDC/ETH), периодически покупает собственный токен на рынке и сжигает.

contract BuybackBurner {
    IUniswapV2Router02 public router;
    address public token;
    address public revenueToken; // USDC или ETH
    
    address[] private path;
    
    constructor(address _router, address _token, address _revenueToken) {
        router = IUniswapV2Router02(_router);
        token = _token;
        revenueToken = _revenueToken;
        path = [_revenueToken, _token];
    }
    
    function executeBuyback(uint256 revenueAmount, uint256 minTokenOut) external onlyAdmin {
        IERC20(revenueToken).approve(address(router), revenueAmount);
        
        uint256[] memory amounts = router.swapExactTokensForTokens(
            revenueAmount,
            minTokenOut,      // slippage protection
            path,
            address(this),
            block.timestamp + 300
        );
        
        uint256 tokensBought = amounts[amounts.length - 1];
        ERC20Burnable(token).burn(tokensBought);
        
        emit BuybackExecuted(revenueAmount, tokensBought);
    }
}

Slippage и MEV. Крупный buyback виден в mempool — front-runners покупают перед вами, вы покупаете дороже, они продают. Решения: использовать DEX aggregator (1inch), private mempool (Flashbots Protect), разбивать buyback на мелкие части через TWAP.

Подробнее о защите от MEVНа практике мы рекомендуем комбинировать Flashbots с TWAP-распределением на 24 часа. Это снижает вероятность атаки на 95%. В одном из проектов мы реализовали такую защиту, и buyback проходил без потерь на sandwich.

Deflationary transfer tax

Каждый transfer сжигает X% — popularized мемкоинами. Проблема transfer tax: несовместим с большинством DeFi протоколов. Uniswap V2 не поддерживает fee-on-transfer токены корректно без специальных параметров. Uniswap V3 не поддерживает вовсе. Aave, Compound — не принимают fee-on-transfer как collateral. Это фундаментальное ограничение: transfer tax изолирует токен от DeFi экосистемы.

Burn schedule: дискретный vs непрерывный

Дискретный burn (quarterly buyback, epoch-based burn): предсказуемый, создаёт ожидаемые события на рынке. Риск: front-running перед известными датами.

Непрерывный burn (fee burn при каждой транзакции): более предсказуемый supply deflation, нет временных аномалий. Но требует постоянной активности протокола.

Экономическое моделирование

Перед внедрением burn механизма нужна quantitative модель. Минимальные параметры:

Параметр Описание
Annual burn rate % total supply сжигаемый в год при текущей активности
Break-even activity Уровень активности при котором burn = emission
Supply в horizon 5 лет При текущих параметрах
Sensitivity Как меняется burn при 2x/10x росте объёма

Инструмент: TokenTerminal, Dune Analytics для моделирования на исторических данных похожих протоколов. Spreadsheet модель с Monte Carlo для чувствительности.

Процесс работы

  1. Экономический дизайн (1–2 недели). Определяем тип механизма под конкретную модель протокола. Строим количественную модель supply dynamics.
  2. Разработка (1–3 недели). Burn механизм в токен контракте или отдельный Burner контракт. Тесты на edge cases: burn 0 amount, burn больше balance, reentrancy в fee collection.
  3. Аудит-фокус. Проверить: нет ли возможности через burn манипулировать ценой оракула (если totalSupply используется в расчётах), корректность permission на вызов burn, защита buyback от sandwich атак.

Сроки и стоимость

Сроки: от 3 до 6 недель в зависимости от сложности механизма. Стоимость рассчитывается индивидуально — оценим проект после брифа. Гарантируем аудит-качество: наши контракты проходят проверку Slither и фаззинг Echidna. Опыт команды — 10+ блокчейн-проектов в продакшене. Закажите консультацию, чтобы обсудить ваш проект.

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

  • Экономическая модель с Monte Carlo
  • Исходный код смарт-контрактов (Solidity 0.8.x)
  • Набор тестов (Hardhat, мокко)
  • Документация по интеграции
  • Аудит-фокус и рекомендации по защите
  • Поддержка при развёртывании

Получите консультацию — пишите, обсудим ваш токеномикс и подберём подходящий механизм сжигания под ключ.

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