Проектування механізмів спалювання токенів

Проектування механізму спалювання токенів

Спалювання токенів — це не самостійна мета, а інструмент управління пропозицією. Проблема більшості проектів: burn механізм додається як маркетинговий хід без зв'язку з економічною моделлю. Токени спалюються, пропозиція падає, ціна... не обов'язково зростає, якщо попит не зростає разом з нею.

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

EIP-1559: Канонічний приклад fee burn

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

ETH грошово-кредитна політика після EIP-1559:
Issuance (staking rewards) - Burned (base fees) = Чистісна зміна в пропозиції

При високому навантаженні мережі: burn > issuance → дефляція
При низькому навантаженні: issuance > burn → інфляція
Нейтральна точка: ~15M gas/block utilization

Це правильна конструкція: 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(): спалює з дозволом (для протокольного використання)
}

_burn в ERC-20: зменшує balanceOf[account] та totalSupply. Токени відправляються на address(0) — null адреса. Це домовленість, не криптографічне знищення, але еквівалентно: ніхто не володіє ключами до address(0).

Fee burn у протоколі

contract Protocol {
    IERC20 public token;
    uint256 public constant FEE_BPS = 50; // 0.5%
    uint256 public constant BURN_SHARE = 50; // 50% комісії спалюється
    
    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);
        
        // Спалювання частини комісії
        ERC20Burnable(address(token)).burn(burnAmount);
        
        // Залишок в казну
        token.transfer(treasury, treasuryAmount);
        
        // Логіка дії з (amount - fee)
        _executeCore(amount - fee);
    }
}

Дизайнерське рішення: який відсоток комісій спалювати vs відправляти в казну. 100% burn максимально дефляційний, але позбавляє протокол доходів. BNB Auto-Burn спалює 100% комісій BNB Chain щоквартально через buyback.

Buyback-and-Burn

Протокол накопичує дохід (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
            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), приватний mempool (Flashbots Protect), розбивати buyback на дрібні частини через TWAP.

Дефляційний transfer tax

Кожен transfer спалює X% — популяризовано мемкоїнами. Технічно:

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 як забезпечення. Це фундаментальне обмеження: transfer tax ізолює токен від DeFi екосистеми.

Burn schedule: Дискретний vs безперервний

Дискретний burn (квартальний 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 механізму потрібна кількісна модель. Мінімальні параметри:

Інструменти: TokenTerminal, Dune Analytics для моделювання на історичних даних подібних протоколів. Spreadsheet модель з Monte Carlo для чутливості.

Процес роботи

Економічний дизайн (1-2 тижні). Визначити тип механізму під конкретну модель протоколу. Побудувати кількісну модель динаміки пропозиції.

Розробка (1-3 тижні). Burn механізм у токен контракті або окремий Burner контракт. Тести на edge cases: burn 0 amount, burn більше balance, reentrancy у fee collection.

Аудит-фокус. Перевірити: немає способу через burn маніпулювати ціною оракула (якщо totalSupply використовується в розрахунках), коректність permission на вызов burn, захист buyback від sandwich атак.