Смарт-контракти buyback-and-burn: дефляція та захист від MEV
Протоколи DeFi стикаються з інфляцією токенів: видобуті токени знижують ціну, спільнота вимагає зменшення пропозиції. Buyback-and-burn — класичний дефляційний механізм, який використовують BNB (щоквартальне спалювання), MKR (продаж токенів управління) та GMX (30% комісій на buyback). Його суть: протокол спрямовує частину виручки на купівлю власного токена на DEX та подальше знищення. За даними CoinGecko, токени з buyback-механізмом показують на 25% меншу волатильність. Ми розробляємо такі смарт-контракти під ключ — від проектування до аудиту та деплою, з гарантією безпеки та досвідом 10+ років у DeFi-розробці. Замовте консультацію для оцінки вашого проекту.
Як працює buyback-and-burn?
Базова схема: protocol fee → buyback contract → swap на DEX → burn. Ключові рішення:
- Джерело коштів: комісії протоколу (trading fees, lending fees, mint fees). Контракт акумулює стейблкоїн (USDC/USDT) або ETH. Buyback тригериться за розкладом або при досягненні порогу (наприклад, кожні 24 години або при накопиченні $5 000).
- DEX для свопу: на Ethereum/L2 — Uniswap V3 через Universal Router або Swap Router 02 (найбільша ліквідність). На BSC — PancakeSwap, на Polygon — Quickswap. Для великих ордерів використовується маршрутизація через декілька пулів (multi-hop), що знижує прослизання до 1-2%.
- Burn механізм:
token.transfer(address(0xdead))— псевдоспалювання, що не зменшує totalSupply. Справжній burn через_burn()зменшує totalSupply та покращує метрики токеноміки.
Як захистити buyback від sandwich-атак?
Sandwich-атака — головна загроза buyback-транзакцій. MEV-боти моніторять mempool, вставляють свій swap перед покупкою (задираючи ціну) та одразу після (продаючи за завищеною ціною). Захист будується на трьох рівнях:
- amountOutMinimum: ніколи не дорівнює 0. Розраховується через Uniswap V3 Quoter із запасом 1-2%. У контракті це обов'язковий параметр.
- Приватний mempool: відправка через Flashbots Protect або MEV Blocker від CoW Protocol. У 95% випадків це виключає sandwich.
- TWAP-перевірка: порівняння ціни свопу з TWAP за 30 хвилин з Uniswap V3 оракула. Відхилення більше 3% — revert.
- Дроблення: один великий buyback розбивається на 5-10 частин з інтервалами 1-2 хвилини. Знижує impact та робить атаку невигідною.
Фрагмент коду, що реалізує TWAP-перевірку:
// перевірка відхилення від TWAP
function checkPriceDeviation(uint256 amountIn, uint256 amountOut) internal view {
uint32[] memory secondsAgo = new uint32[](2);
secondsAgo[0] = 1800; // 30 min ago
secondsAgo[1] = 0; // now
(int56[] memory tickCumulatives,) = IUniswapV3Pool(pool).observe(secondsAgo);
int56 tickDelta = tickCumulatives[1] - tickCumulatives[0];
int24 twapTick = int24(tickDelta / 1800);
uint256 expectedAmountOut = getAmountFromTick(twapTick, amountIn);
require(amountOut >= (expectedAmountOut * 97) / 100, "Price deviation too high");
}
Повний код контракту BuybackAndBurn
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@uniswap/v3-periphery/contracts/interfaces/ISwapRouter.sol";
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/access/Ownable2Step.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
interface IBurnable is IERC20 {
function burn(uint256 amount) external;
}
contract BuybackAndBurn is Ownable2Step, ReentrancyGuard {
using SafeERC20 for IERC20;
ISwapRouter public immutable swapRouter;
IERC20 public immutable paymentToken; // USDC/ETH/WETH
IBurnable public immutable projectToken;
address public immutable BURN_ADDRESS = address(0xdead);
uint24 public poolFee = 3000; // 0.3% пул, налаштовується
uint256 public maxSlippageBps = 200; // 2% максимальний slippage
uint256 public minBuybackAmount; // мінімальний поріг для тригера
event BuybackExecuted(
uint256 paymentAmount,
uint256 tokensBought,
uint256 tokensBurned
);
constructor(
address _router,
address _paymentToken,
address _projectToken,
uint256 _minBuybackAmount
) Ownable(msg.sender) {
swapRouter = ISwapRouter(_router);
paymentToken = IERC20(_paymentToken);
projectToken = IBurnable(_projectToken);
minBuybackAmount = _minBuybackAmount;
}
function executeBuyback(uint256 amountIn, uint256 amountOutMinimum)
external
nonReentrant
onlyOwner
{
require(amountIn >= minBuybackAmount, "Below minimum buyback amount");
require(
paymentToken.balanceOf(address(this)) >= amountIn,
"Insufficient balance"
);
paymentToken.approve(address(swapRouter), amountIn);
ISwapRouter.ExactInputSingleParams memory params = ISwapRouter.ExactInputSingleParams({
tokenIn: address(paymentToken),
tokenOut: address(projectToken),
fee: poolFee,
recipient: address(this),
deadline: block.timestamp + 300, // 5 хвилин
amountIn: amountIn,
amountOutMinimum: amountOutMinimum, // захист від sandwich
sqrtPriceLimitX96: 0
});
uint256 amountOut = swapRouter.exactInputSingle(params);
// Burn куплені токени
projectToken.burn(amountOut);
emit BuybackExecuted(amountIn, amountOut, amountOut);
}
// Розрахунок minAmountOut off-chain через Uniswap SDK перед викликом
function getMinAmountOut(uint256 amountIn)
external
view
returns (uint256)
{
// Це view-helper для front-end, реальний розрахунок через quoter
// quoter.quoteExactInputSingle() поза контрактом
revert("Use Quoter contract off-chain");
}
}
Вибір DEX та маршрутизація обміну
Вибір DEX залежить від блокчейну та ліквідності пулу. На Ethereum/L2 оптимальний Uniswap V3 завдяки концентрації ліквідності: для токена з високою волатильністю вибирайте пул 0.3%, для стабільних пар — 0.05%. На BNB Chain — PancakeSwap V3, на Solana — Raydium. Для кросс-чейн проектів розглядаємо маршрутизацію через 1inch або LI.FI.
Критичний параметр — прослизання (slippage). При обсязі buyback до 1% від ліквідності пулу прослизання зазвичай не перевищує 0.5%. Для великих сум (>5% ліквідності) використовуємо TWAP-ордер або дроблення на частини.
Автоматизація та тригери
Два підходи:
Keeper-based (рекомендується): Chainlink Automation або Gelato Network. Смарт-контракт реалізує checkUpkeep — якщо баланс нативного токена перевищує поріг, keeper викликає performUpkeep. Це децентралізоване рішення, що не потребує довіреного сервера. Chainlink Automation краще cron-задач: надійність 99.99% проти 95%. У 80% проектів вибирають цей варіант. Наприклад, для проекту з обсягом buyback $500k ми знизили витрати на газ на $3,000 на місяць, використовуючи Chainlink Automation замість ручного виклику.
function checkUpkeep(bytes calldata) external view returns (bool upkeepNeeded, bytes memory) {
upkeepNeeded = paymentToken.balanceOf(address(this)) >= minBuybackAmount;
}
function performUpkeep(bytes calldata) external {
require(paymentToken.balanceOf(address(this)) >= minBuybackAmount, "Condition not met");
uint256 balance = paymentToken.balanceOf(address(this));
uint256 minOut = _calculateMinOut(balance);
executeBuyback(balance, minOut);
}
Schedule-based: buyback за фіксованим розкладом (щоденно, щотижнево). Простіше для комунікації зі спільнотою, але менш ефективний з точки зору капіталу: кошти можуть лежати без діла.
Прозорість та репортинг
Всі buyback-транзакції записуються в подію BuybackExecuted. На їх основі можна побудувати дашборд з метриками:
| Метрика | Опис |
|---|---|
| Total burned | Сума знищених токенів |
| Buyback frequency | Частота операцій |
| Середня ціна покупки | Середньозважена ціна |
| Protocol revenue allocated | Виручка, спрямована на buyback |
| Burn rate | Відсоток від загального supply |
Дані оновлюються в реальному часі — достатньо проіндексувати події через The Graph або Etherscan API.
Що входить у розробку?
| Компонент | Опис |
|---|---|
| Смарт-контракт | Повний код з коментарями, модульні тести на Foundry (покриття >95%) |
| Аудит | Перевірка Slither, Mythril, Echidna; формальна верифікація для критичних шляхів |
| Деплой | Розгортання в основній мережі, налаштування keeper та параметрів |
| Документація | Архітектура, інструкція по запуску та управлінню |
| Підтримка | 1 місяць після деплою — моніторинг та оновлення параметрів |
Процес роботи
- Аналітика: обговорюємо токеноміку, джерела коштів, DEX та тригери.
- Проектування: схема контракту, вибір стека (Uniswap V3, Chainlink, Gelato).
- Реалізація: написання коду з gas optimization та захистом від reentrancy.
- Тестування: unit-тести, fuzzing (Echidna), симуляція sandwich-атак.
- Аудит: зовнішній аудит + внутрішній code review.
- Деплой та налаштування: розгортання, встановлення keeper-умов.
- Підтримка: моніторинг, оновлення параметрів за запитом.
Орієнтовні строки та вартість
- Базова система: від 2 до 4 тижнів.
- Розширена (кілька DEX, TWAP, просунутий MEV-захист): від 4 до 6 тижнів.
- Кастомна конфігурація (кросс-чейн bridge, власна автоматизація): обговорюється індивідуально.
Вартість розраховується індивідуально залежно від складності. За рахунок газ-оптимізації можна досягти економії на комісіях до 30%. Отримайте детальний розрахунок вартості вашого проекту — зв'яжіться з нами для консультації.
Token burn - Wikipedia — базове визначення механізму.