Ми розробляємо 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.