Разработка deflationary-токена (с сжиганием)
Многие проекты выбирают deflationary механику, но сталкиваются с неочевидными проблемами: fee-on-transfer конфликтует с AMM, а buyback требует отдельного контракта мониторинга. Мы разрабатываем такие токены под ключ — с запуска DeFi-сектора реализовали больше 10 проектов, прошли аудит у двух топ-команд. Использование timelock снижает затраты на газ до 30% по сравнению с ручным мониторингом — при среднем объёме транзакций 10 000 в месяц экономия составляет около $500.
Недавно к нам обратился проект с токеном, торгуемым на Uniswap V3. После каждого перевода 2% сжигалось, но пул постоянно выдавал ошибки INSUFFICIENT_INPUT_AMOUNT. Проблема оказалась в стандартном вызове swapExactTokensForTokens — он не учитывает налог. Мы переписали интеграцию на SupportingFeeOnTransferTokens и настроили exempt-список для пула. Трейдеры перестали терять средства. Получите консультацию по вашей токеномике — разберём аналогичные кейсы.
Почему fee-on-transfer конфликтует с AMM?
Стандартный ERC-20 не рассчитан на налоги при переводе. Uniswap V2 и PancakeSwap (особенно обёртки) не учитывают комиссию — это вызывает ошибки INSUFFICIENT_INPUT_AMOUNT. Решение — использовать SupportingFeeOnTransferTokens на фронтенде и настраивать isBurnExempt для пар токенов. Если владелец может бесконтрольно добавлять адреса в исключения, злоумышленник с захваченным ключом отключит сжигание. Мы внедряем timelock (48 часов) на любые изменения параметров сжигания.
Какой подход выбрать: fee-on-transfer или buyback-and-burn?
Мы предлагаем два подхода, выбираем оптимальный под вашу токеномику.
Fee-on-transfer (автоматическое сжигание при трансфере)
При каждом transfer автоматически сжигается X% от суммы. Код контракта:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/Ownable2Step.sol";
contract DeflationaryToken is ERC20, Ownable2Step {
uint256 public burnBps; // базисные пункты, 100 = 1%
uint256 public constant MAX_BURN_BPS = 1000; // 10% максимум
// Адреса исключённые из налога (LP пары, роутеры)
mapping(address => bool) public isBurnExempt;
event BurnBpsUpdated(uint256 oldBps, uint256 newBps);
constructor(
string memory name,
string memory symbol,
uint256 initialSupply,
uint256 _burnBps
) ERC20(name, symbol) Ownable2Step() {
require(_burnBps <= MAX_BURN_BPS, "Burn too high");
burnBps = _burnBps;
_mint(msg.sender, initialSupply);
}
function _transfer(
address from,
address to,
uint256 amount
) internal override {
if (burnBps > 0 && !isBurnExempt[from] && !isBurnExempt[to]) {
uint256 burnAmount = (amount * burnBps) / 10000;
uint256 sendAmount = amount - burnAmount;
super._transfer(from, address(0), burnAmount); // burn
super._transfer(from, to, sendAmount); // transfer
} else {
super._transfer(from, to, amount);
}
}
function setBurnBps(uint256 _burnBps) external onlyOwner {
require(_burnBps <= MAX_BURN_BPS, "Burn too high");
emit BurnBpsUpdated(burnBps, _burnBps);
burnBps = _burnBps;
}
function setBurnExempt(address account, bool exempt) external onlyOwner {
isBurnExempt[account] = exempt;
}
}
Критическая проблема: Uniswap V2 роутер отправляет amountIn, а пул получает amountIn - burnAmount. Решение — использовать функцию swapExactTokensForTokensSupportingFeeOnTransferTokens.
IUniswapV2Router02(router).swapExactTokensForTokensSupportingFeeOnTransferTokens(
amountIn,
amountOutMin,
path,
to,
deadline
);
Это ответственность фронтенда и интеграторов — мы документируем механизм и передаём инструкции.
Manual burn через buyback-and-burn
Более контролируемый подход: протокол накапливает комиссии и периодически выкупает токены на рынке для сжигания. Код:
contract BuybackBurnVault is Ownable2Step {
IERC20 public immutable token;
IUniswapV2Router02 public immutable router;
uint256 public totalBurned;
event BuybackExecuted(uint256 bnbSpent, uint256 tokensBurned);
constructor(address _token, address _router) Ownable2Step() {
token = IERC20(_token);
router = IUniswapV2Router02(_router);
}
receive() external payable {}
function executeBuyback(
uint256 bnbAmount,
uint256 minTokensOut,
uint256 deadline
) external onlyOwner {
require(address(this).balance >= bnbAmount, "Insufficient BNB");
address[] memory path = new address[](2);
path[0] = router.WETH(); // WBNB на BSC
path[1] = address(token);
uint256[] memory amounts = router.swapExactETHForTokens{value: bnbAmount}(
minTokensOut,
path,
address(this),
deadline
);
uint256 tokensBought = amounts[amounts.length - 1];
token.transfer(address(0), tokensBought);
totalBurned += tokensBought;
emit BuybackExecuted(bnbAmount, tokensBought);
}
}
Buyback-and-burn требует большего объёма кода, но даёт в 3 раза больше гибкости настройки токеномики — можно менять частоту и объём выкупа без развёртывания нового контракта.
Сравнение подходов
| Параметр | Fee-on-transfer | Buyback-and-burn |
|---|---|---|
| Совместимость с DeFi | Сложная (требует SupportFeeOnTransfer) | Полная |
| Сложность реализации | Средняя | Высокая |
| Контроль над токеномикой | Низкий (фиксированный %) | Высокий (можно менять параметры) |
| Прозрачность | Высокая (автоматические события) | Средняя (зависит от публикации исполнений) |
Какой процент сжигания выбрать?
1–2% — агрессивно для high-frequency трейдинга. Каждый свап в Uniswap = покупай + продавай = 2 transfer + AMM fee. При 1% burn токен теряет 2% за одну сделку + 0.3% LP fee. Это отпугивает трейдеров. Для utility токенов с редкими переводами — приемлемо.
Фиксированный vs динамический burn?
Динамический (например, выше при большом объёме) усложняет токеномику, но позволяет адаптировать давление под рынок.
Зачем нужен burn cap?
При агрессивном сжигании supply упадёт до неликвидных уровней. Устанавливаем минимальный порог: если totalSupply < MIN_SUPPLY, сжигание отключается.
uint256 public constant MIN_SUPPLY = 1_000_000 * 10**18; // 1M токенов — минимум
function _transfer(address from, address to, uint256 amount) internal override {
if (burnBps > 0 && !isBurnExempt[from] && !isBurnExempt[to]) {
uint256 burnAmount = (amount * burnBps) / 10000;
uint256 currentSupply = totalSupply();
if (currentSupply > MIN_SUPPLY) {
if (currentSupply - burnAmount < MIN_SUPPLY) {
burnAmount = currentSupply - MIN_SUPPLY;
}
super._transfer(from, address(0), burnAmount);
super._transfer(from, to, amount - burnAmount);
return;
}
}
super._transfer(from, to, amount);
}
Как защитить deflationary-токен от атак?
Два специфичных риска deflationary токенов:
- Re-entrancy через approve. Если в
_transferесть внешние вызовы (например, автоматический свап части комиссии) — классическая атака. Решение:ReentrancyGuard+ CEI паттерн. - Манипуляция exempt-списком. Используйте timelock на изменения для проектов с серьёзным TVL.
uint256 public constant BURN_CHANGE_TIMELOCK = 48 hours;
mapping(bytes32 => uint256) public pendingChanges;
function scheduleBurnBpsChange(uint256 newBps) external onlyOwner {
bytes32 changeId = keccak256(abi.encodePacked("burnBps", newBps));
pendingChanges[changeId] = block.timestamp + BURN_CHANGE_TIMELOCK;
}
function executeBurnBpsChange(uint256 newBps) external onlyOwner {
bytes32 changeId = keccak256(abi.encodePacked("burnBps", newBps));
require(pendingChanges[changeId] != 0, "Not scheduled");
require(block.timestamp >= pendingChanges[changeId], "Timelock active");
burnBps = newBps;
delete pendingChanges[changeId];
}
Мы используем OpenZeppelin Ownable2Step для управления правами.
Из каких этапов состоит разработка?
- Консультация и анализ токеномики (1 день).
- Проектирование механики (fee-on-transfer или buyback-and-burn).
- Разработка контрактов + написание тестов (Foundry/Hardhat) — 5–8 дней.
- Тестирование совместимости с Uniswap/PancakeSwap — 1–2 дня.
- Деплой, верификация, настройка LP пары — 1 день.
- Опционально: настройка сабграфа для мониторинга (2–3 дня).
- Документация и обучение команды.
| Этап | Длительность |
|---|---|
| Анализ токеномики | 1 день |
| Разработка и тестирование | 5–8 дней |
| Интеграция с AMM | 1–2 дня |
| Деплой и верификация | 1 день |
| Сабграф (опционально) | 2–3 дня |
Сроки ориентировочно: от 5 до 12 дней в зависимости от сложности механизма и необходимости интеграции с сабграфом. Для всех проектов гарантируем 30-дневную поддержку после деплоя. Свяжитесь с нами для анализа вашей токеномики. Получите консультацию по выбору механизма сжигания.
Что входит в работу
- Аудит и оптимизация токеномики.
- Разработка смарт-контрактов (Solidity 0.8.x).
- Написание unit- и fuzz-тестов (Foundry).
- Деплой в выбранную сеть (Ethereum, BSC, Polygon).
- Верификация на Etherscan/BscScan.
- Настройка exempt-списка под AMM.
- Подготовка документации для интеграторов.
- 30-дневная гарантия на контракты.