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

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

Спалювання токенів — не самостійна мета, а інструмент управління пропозицією. Проблема більшості проєктів: 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% при високій активності.

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

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

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 модель. Мінімальні параметри:

Інструмент: 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, мокко)
• Документація з інтеграції
• Аудит-фокус та рекомендації щодо захисту
• Підтримка при розгортанні

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