Мы разрабатываем utility-токены, которые решают реальные задачи протокола, а не искусственно вставлены в tokenomics ради продажи. Utility-токен отличается от governance или security токена функционально: он нужен для чего-то конкретного внутри экосистемы. Оплата газа (ETH), вычислений (FIL в Filecoin), доступа к сервису (API credits), скидки на комиссии (BNB на Binance) — всё это примеры настоящей utility. Проблема большинства «utility» токенов: utility искусственная, токен не нужен для работы протокола. Настоящий utility-токен решает проблему, которую нельзя решить без токена: coordinated incentives для участников сети, trustless escrow, программируемые условия доступа. Наша команда имеет более 7 лет опыта в блокчейн-разработке, более 30 запущенных токенов, опыт работы в индустрии — это позволяет с первого раза спроектировать рабочую экономику.
Проектирование utility механики
Как проверить необходимость токена?
Перед проектированием токена мы проводим анализ: можно ли заменить его на USDC или ETH? Если замена возможна — собственный токен не нужен. Если нет — выявляем уникальную utility. Убедительные причины иметь собственный токен: Governance (право голоса), Staking для безопасности (валидаторы стейкают токен, слэшинг при мошенничестве — skin in the game), Protocol revenue sharing (токенхолдеры получают часть комиссий), инфляционные награды для bootstrap экосистемы. Стейкинг позволяет снизить затраты на комиссии до 20% для держателей токенов.
Capture механика
Utility-токен должен захватывать часть ценности протокола. Популярные паттерны: Fee switch (протокол берёт % от операций, часть идёт токенхолдерам или buyback/burn), Staking для доступа (провайдеры блокируют токены как гарантию), Token-denominated pricing (услуга стоит N токенов). Спрос на услугу генерирует спрос на токен.
Реализация: staking utility
Типичный utility-токен со staking для доступа к сервису:
Используем библиотеку OpenZeppelin для стандартных контрактов.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";
import "@openzeppelin/contracts/utils/ReentrancyGuard.sol";
contract UtilityToken is ERC20, ERC20Permit, AccessControl, ReentrancyGuard {
bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
bytes32 public constant SERVICE_ROLE = keccak256("SERVICE_ROLE");
uint256 public constant PROVIDER_STAKE_REQUIRED = 10_000 * 10**18; // 10k токенов
struct ProviderStake {
uint256 amount;
uint256 stakedAt;
bool active;
}
mapping(address => ProviderStake) public providerStakes;
mapping(address => uint256) public serviceCredits;
uint256 public constant CREDIT_PRICE = 1 * 10**18;
uint256 public burned;
event ProviderRegistered(address indexed provider, uint256 stake);
event ProviderSlashed(address indexed provider, uint256 amount, string reason);
event CreditsPurchased(address indexed user, uint256 amount);
constructor(address admin, address treasury, uint256 initialSupply)
ERC20("Utility Token", "UTL")
ERC20Permit("Utility Token")
{
_grantRole(DEFAULT_ADMIN_ROLE, admin);
_grantRole(MINTER_ROLE, admin);
_mint(treasury, initialSupply);
}
function stakeAsProvider() external nonReentrant {
require(!providerStakes[msg.sender].active, "Already registered");
require(
balanceOf(msg.sender) >= PROVIDER_STAKE_REQUIRED,
"Insufficient balance"
);
_transfer(msg.sender, address(this), PROVIDER_STAKE_REQUIRED);
providerStakes[msg.sender] = ProviderStake({
amount: PROVIDER_STAKE_REQUIRED,
stakedAt: block.timestamp,
active: true
});
_grantRole(SERVICE_ROLE, msg.sender);
emit ProviderRegistered(msg.sender, PROVIDER_STAKE_REQUIRED);
}
function purchaseCredits(uint256 creditAmount) external nonReentrant {
uint256 tokenCost = creditAmount * CREDIT_PRICE;
require(balanceOf(msg.sender) >= tokenCost, "Insufficient tokens");
uint256 burnAmount = tokenCost * 80 / 100;
uint256 treasuryAmount = tokenCost - burnAmount;
_burn(msg.sender, burnAmount);
burned += burnAmount;
_transfer(msg.sender, treasury, treasuryAmount);
serviceCredits[msg.sender] += creditAmount;
emit CreditsPurchased(msg.sender, creditAmount);
}
function consumeCredits(address user, uint256 amount) external onlyRole(SERVICE_ROLE) {
require(serviceCredits[user] >= amount, "Insufficient credits");
serviceCredits[user] -= amount;
emit CreditsConsumed(user, msg.sender, amount);
}
function slashProvider(
address provider,
uint256 amount,
string calldata reason
) external onlyRole(DEFAULT_ADMIN_ROLE) {
ProviderStake storage stake = providerStakes[provider];
require(stake.active, "Not active provider");
require(amount <= stake.amount, "Exceeds stake");
stake.amount -= amount;
_burn(address(this), amount);
burned += amount;
if (stake.amount < PROVIDER_STAKE_REQUIRED / 2) {
stake.active = false;
_revokeRole(SERVICE_ROLE, provider);
}
emit ProviderSlashed(provider, amount, reason);
}
}
Почему staking — основа utility-токена?
Staking создаёт обязательства у участников сети. Провайдеры услуг вынуждены держать токены как гарантию добросовестности. При нарушении — slashing. Это удерживает ценность токена внутри экосистемы. Сравнивая с buyback: стейкинг для доступа эффективнее чистого buyback-сжигания в 3–5 раз с точки зрения удержания пользователей.
Unstaking cooldown
Провайдер не должен мгновенно выводить stake. Cooldown период — защита от slash evasion:
uint256 public constant UNSTAKE_COOLDOWN = 14 days;
mapping(address => uint256) public unstakeRequestedAt;
function requestUnstake() external {
require(providerStakes[msg.sender].active, "Not active");
unstakeRequestedAt[msg.sender] = block.timestamp;
providerStakes[msg.sender].active = false;
_revokeRole(SERVICE_ROLE, msg.sender);
}
function finalizeUnstake() external nonReentrant {
require(unstakeRequestedAt[msg.sender] > 0, "No unstake request");
require(
block.timestamp >= unstakeRequestedAt[msg.sender] + UNSTAKE_COOLDOWN,
"Cooldown not elapsed"
);
uint256 amount = providerStakes[msg.sender].amount;
providerStakes[msg.sender].amount = 0;
unstakeRequestedAt[msg.sender] = 0;
_transfer(address(this), msg.sender, amount);
}
Сравнение механик удержания ценности
| Механика | Эффективность | Пример |
|---|---|---|
| Staking для доступа | Высокая | BNB, FIL |
| Buyback и burn | Средняя | Fee → buyback |
| Fee switch | Высокая | AMM протоколы |
| Инфляционные награды | Низкая (без utility) | DeFi 2.0 |
Распределение supply
Типичное распределение для utility-токена протокола:
| Аллокация | % | Vesting |
|---|---|---|
| Команда и советники | 15–20% | 4 года, cliff 1 год |
| Инвесторы | 15–25% | 2–3 года, cliff 6 мес |
| Экосистема/гранты | 20–30% | Линейно 3–5 лет |
| Liquidity/DEX | 5–10% | TGE или по необходимости |
| Treasury | 20–30% | Governance решает |
| Public sale / IDO | 5–15% | Частично TGE |
Общая сумма TGE — желательно не более 15–20% supply.
Как избежать антипаттернов utility-токена?
Бесполезный buyback — buyback токена из treasury без реального revenue не создаёт ценности. Circular dependency — токен нужен для использования протокола, а протокол — для получения токена — замкнутый круг. Governance без power — токен без права менять параметры протокола декоративен. Мы проектируем механики, каждая из которых приносит измеримую пользу. Правильная токеномика может повысить доходность поставщиков услуг на 30–50%.
Как мы работаем над проектом utility-токена
- Анализ: выясняем, нужен ли ERC20 токен, и какую utility он принесёт.
- Проектирование: разрабатываем tokenomics и экономические модели.
- Реализация: пишем смарт-контракты на Solidity с использованием OpenZeppelin.
- Тестирование: покрываем unit и fuzz тестами с помощью Foundry.
- Аудит: проверяем код на уязвимости (reentrancy, overflow и т.д.).
- Деплой и верификация на Etherscan.
- Поддержка: месяц технической поддержки после запуска.
Если вы планируете запуск токена, свяжитесь с нами — мы поможем спроектировать экономику и реализовать контракты.
Что входит в разработку utility-токена
- Токеномика: анализ и white paper
- Смарт-контракты: Solidity (ERC20, staking, burn, permit)
- Тестирование: Foundry (unit + fuzzing)
- Деплой и верификация на Etherscan
- Интеграция с кошельками (MetaMask, WalletConnect)
- Документация для команды
- Техническая поддержка 1 месяц после запуска
Свяжитесь с нами для оценки вашего проекта. Получите консультацию по tokenomics.