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

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

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

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

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

После London hard fork (2021) Ethereum сжигает base fee каждого блока. Механизм elegant: пользователи платят base_fee (динамический, зависит от загрузки сети) + priority_fee (miners/validators). Base fee сжигается — навсегда выходит из обращения. Priority fee уходит validator.

ETH monetary policy после EIP-1559:
Issuance (staking rewards) - Burned (base fees) = Net change in supply

При высокой нагрузке сети: burn > issuance → дефляция
При низкой нагрузке: issuance > burn → инфляция
Neutral point: ~15M gas/block utilization

Это правильная конструкция: burn напрямую связан с utility токена (газ для исполнения транзакций). Больше активности → больше burn.

Реализация 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.

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.

Deflationary transfer tax

Каждый transfer сжигает X% — popularized мемкоинами. Технически:

function _transfer(address from, address to, uint256 amount) internal override {
    uint256 burnAmount = (amount * burnRate) / 10000; // burnRate в basis points
    uint256 transferAmount = amount - burnAmount;
    
    super._transfer(from, address(0), burnAmount);   // burn
    super._transfer(from, to, transferAmount);       // реальный transfer
    
    totalSupply -= burnAmount; // или через _burn для корректности
}

Проблема 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, нет временных аномалий. Но требует постоянной активности протокола.

Программируемый halving burn: burn rate снижается со временем по расписанию. Создаёт убывающую дефляцию.

// Динамический burn rate на основе времени
function currentBurnRate() public view returns (uint256) {
    uint256 elapsed = block.timestamp - deployTimestamp;
    uint256 periods = elapsed / PERIOD_DURATION; // например, квартал
    
    // Начальный rate 1%, снижается на 10% каждый период
    // После 10 периодов стабилизируется на минимуме
    uint256 rate = INITIAL_RATE;
    for (uint256 i = 0; i < periods && i < 10; i++) {
        rate = (rate * 90) / 100; // -10% каждый период
    }
    return rate > MIN_RATE ? rate : MIN_RATE;
}

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

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

Инструмент: 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 атак.