Проектирование механизма сжигания токенов
Сжигание токенов — не самостоятельная цель, а инструмент управления предложением. Проблема большинства проектов: 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–2 недели). Определяем тип механизма под конкретную модель протокола. Строим количественную модель supply dynamics.
- Разработка (1–3 недели). Burn механизм в токен контракте или отдельный Burner контракт. Тесты на edge cases: burn 0 amount, burn больше balance, reentrancy в fee collection.
- Аудит-фокус. Проверить: нет ли возможности через burn манипулировать ценой оракула (если totalSupply используется в расчётах), корректность permission на вызов burn, защита buyback от sandwich атак.
Сроки и стоимость
Сроки: от 3 до 6 недель в зависимости от сложности механизма. Стоимость рассчитывается индивидуально — оценим проект после брифа. Гарантируем аудит-качество: наши контракты проходят проверку Slither и фаззинг Echidna. Опыт команды — 10+ блокчейн-проектов в продакшене. Закажите консультацию, чтобы обсудить ваш проект.
Что входит в работу
- Экономическая модель с Monte Carlo
- Исходный код смарт-контрактов (Solidity 0.8.x)
- Набор тестов (Hardhat, мокко)
- Документация по интеграции
- Аудит-фокус и рекомендации по защите
- Поддержка при развёртывании
Получите консультацию — пишите, обсудим ваш токеномикс и подберём подходящий механизм сжигания под ключ.







