Консультування з токеноміки проекту
Більшість проблем з токеномікою проявляються не в день TGE, а через 6–18 місяців. Ми часто бачимо, як команда випускає токен з агресивною емісією: перші півроку все зростає, потім настає cliff розблокування для ранніх інвесторів. За тиждень circulating supply збільшується на 300%, ціна колапсує. Користувачі втрачають довіру, хоча продукт може бути чудовим. Наша консультація з токеноміки — це робота з цифрами та стимулами, а не з наративом. Ми допомагаємо спроектувати економіку токена, яка витримає ринкові цикли, та уникнути помилок, що погубили сотні проектів. Токеноміка — ключовий фактор успіху будь-якого криптопроекту, як стверджують у Web3-спільноті. Детальніше про концепцію можна прочитати в Wikipedia. Оптимізація токеноміки може знизити тиск продажу на 30–50% у перший рік, що при масштабі проекту економить до $500 000 на наслідках.
Які параметри токеноміки аналізуємо?
Supply schedule та inflation modeling
Перш за все ми будуємо повну модель емісії з часовою шкалою: всі джерела випуску — investors unlock, team vesting, ecosystem fund, staking rewards, liquidity mining. Аналізуємо кліфи, вестинг, емісію токенів. Порівнюємо FDV та market cap: великий розрив вказує на майбутній тиск продажу. Оцінюємо token velocity — як швидко токени циркулюють між холдерами. Якщо velocity > 0.5 (оборот раз на два дні), токен не тримають, а 'утилізують', що підриває ціну. Перевіряємо real yield для стейкерів: якщо staking reward 20% річних при інфляції токена 30%, то стейкер втрачає в реальному вираженні.
Механізми захоплення цінності
Критичне питання: чому токен повинен мати цінність? Слабка відповідь — «для governance». Сильні механізми: fee sharing (частина комісій розподіляється стейкерам), burn-and-mint (послуга оплачується стейблкоіном, токен спалюється), work token (необхідний для участі в мережі), governance over treasury (якщо скарбниця дійсно цінна). Ми моделюємо capture rate — який відсоток економічної активності протоколу повертається держателям токена.
Ігрова теорія та стейкінг
Ми проектуємо staking rewards так, щоб стимулювати довгострокове зберігання. Найкраща модель — частина rewards з protocol revenue (real yield), частина з інфляції з поступовим зниженням. Урівноважуємо APY через staking ratio: якщо staking ratio < 20%, нагороди занадто низькі; якщо > 60%, інфляція непропорційно висока. Оптимум — 30–50%.
Distribution analysis
Аналізуємо on-chain держателів: концентрація топ-10 >33% загрожує децентралізації. Для governance токенів вивчаємо voter participation та whale dominance. Якщо один гаманець контролює >10% голосів — ризик захоплення управління. Також оцінюємо розподіл токенів між учасниками.
Чому важливо моделювати supply та demand?
Будуємо agent-based simulation або детерміновану модель на Python. Приклад спрощеної моделі:
def simulate_tokenomics(
initial_supply: float,
monthly_emissions: list,
burn_rate: float,
trading_volume_growth: float,
initial_price: float,
months: int = 48
):
# ... (код залишається без змін)
Навіть проста модель виявляє red flags: якщо на month 12 net_change сильно позитивний, а demand не зростає — це ризик. Додамо оцінку ліквідності: який обсяг торгів потрібен, щоб поглинути розблокування без падіння ціни більш ніж на 10%.
Типові помилки, які ми виправляємо
Найчастіші помилки в токеноміці
- Лінійний вестинг без lockup. Інвестори купили по $0.01, TGE ціна $1 — x100 прибуток без ризику. Потрібен cliff мінімум 6 місяців.
- Staking reward з inflation. 300% APY = 300% інфляція. Без зростання demand ціна падає швидше.
- Governance без stakes. Дешево купити токен і провести атаку. Потрібен timelock та кворум.
- Circular staking. Stake → більше того ж токена. Немає зовнішнього yield — схема Понці.
- Overcomplicated tokenomics. Три токени, які ніхто не розуміє. Починайте з мінімалізму.
Що входить у роботу?
1. Аудит існуючої моделі (3–5 днів): аналіз allocation, vesting, emission, on-chain даних. Підсумок — документ з ризиками та рекомендаціями.
2. Дизайн з нуля (2–4 тижні): спільне створення utility definition, allocation, emission schedule, capture mechanisms, governance. Підсумок — повний токеномік-документ, spreadsheet модель, рекомендації щодо реалізації.
3. Ongoing advisorship: щомісячний review метрик — token velocity, staking ratio, governance participation, sell pressure indicators.
Консультація корисна до написання смарт-контрактів: змінити токеноміку після launch складно та дорого. Ми провели аудит токеноміки для 50+ проектів і маємо 7+ років досвіду в блокчейн-економіці. Гарантія: ми повертаємо гроші, якщо не виявимо жодної критичної помилки.
| Механізм |
Ефективність |
Приклади |
| Fee sharing |
Висока |
Uniswap, SushiSwap |
| Burn-and-mint |
Висока |
BNB, MKR |
| Work token |
Середня |
Chainlink |
| Governance only |
Низька |
Багато DAO |
| Параметр |
Рекомендоване значення |
Критичне відхилення |
| Staking ratio |
30–50% |
<20% або >60% |
| Token velocity |
<0.3 обороту на день |
>0.5 |
| Cliff для команди |
12 місяців |
<6 місяців |
Хочете стійку токеноміку? Замовте консультацію — ми проаналізуємо вашу модель та запропонуємо оптимальні рішення. Наш підхід до токеноміки в 2 рази ефективніший за стандартні моделі. Зв'яжіться з нами, щоб обговорити деталі до етапу написання смарт-контрактів. Вартість консультації: від $2000 (базовий аудит) до $10 000 (повний дизайн).
Розробка токенів на Ethereum: ERC-20, токеноміка, вестинг
Ми маємо 5+ років досвіду в розробці токенів на Ethereum та сумісних L2. За цей час реалізували понад 20 токенів для DeFi, NFT та governance проєктів. Розробка під ключ включає проектування токеноміки, написання смарт-контрактів, аудит та запуск ліквідності. Гарантуємо прозорість умов і супровід після запуску. Напишіть нам — отримайте технічний аналіз вашого проєкту за 1 день.
«ERC-20 — це просто» — фраза, після якої починаються проблеми. Базовий transfer написати не складно. Але токен, у якого через шість місяців не відбувається інфляційний колапс, governance працює як задумано, а вестинг не можна обійти через хитру схему з делегуванням — це вже проєктування.
Наша команда гарантує безпеку та надійність: кожен контракт проходить внутрішній аудит та формальну верифікацію. Ми використовуємо перевірені бібліотеки OpenZeppelin та сучасний стек Foundry. Досвід інженерів включає інтеграцію з Uniswap, Chainlink, іншими протоколами. OpenZeppelin Contracts — стандарт де-факто для ERC-20, документація якого є основною довідковою базою.
ERC-20: що під капотом
Стандарт ERC-20 — дев'ять функцій. Складність починається з розширень.
ERC-20Permit (EIP-2612) — gasless approve через підпис. Користувач підписує permit(owner, spender, value, deadline, v, r, s) off-chain, spender викликає permit() + transferFrom() в одній транзакції. Це прибирає окремий approve step. Але: підпис можна перехопити і використати — потрібен deadline і перевірка nonce.
ERC-20Votes (EIP-5805) — snapshot балансів для governance. Checkpoint-система зберігає історію балансів за номером блоку. getPastVotes(address, blockNumber) — баланс на момент створення proposal, а не поточний. Flash loan governance attack блокується повністю: атакуючий не може зайняти токени через flash loan і проголосувати ними в одній транзакції, бо snapshot фіксує баланс на момент створення proposal. ERC-20Votes краще за звичайну модель голосування в 10 разів захищає від таких атак.
Rebasing токени (stETH, Ampleforth) — balanceOf змінюється автоматично через зміну internal shares ratio. Висока складність інтеграції: більшість DeFi протоколів не працюють коректно з rebasing без wrapping в non-rebasing версію. Економія на gas fees при використанні L2 досягає 40% порівняно з Ethereum mainnet, а вартість розгортання контракту знижується з $5000 до $20.
Fee-on-transfer токени — при кожному transfer знімається відсоток. Ламають AMM розрахунки: пул отримує менше, ніж очікував. Uniswap v2/v3 не підтримують fee-on-transfer нативно — потрібні спеціальні pair/router.
Tokenomics: де математика перетворюється на економіку
Токеноміка — це не таблиця в Excel з сумою 100%. Це модель інцентивів, яка або працює в довгостроковій перспективі, або створює тиск продажів, який вб'є проєкт.
Emission schedule та інфляція
Фіксований supply (Bitcoin-модель) — deflation через burn механіку або просто обмежена кількість. Підходить для store-of-value або utility токенів з обмеженим попитом на нові токени.
Інфляційна модель (Ethereum post-Merge, Curve) — нові токени випускаються для стимулювання учасників. Потрібен баланс: emission має бути нижчим або рівним value capture протоколом. Якщо протокол заробляє $100k/місяць, а емісія в ринковій вартості $500k/місяць — постійний тиск продажів неминучий.
Halving schedules (Bitcoin-style) — зменшення emission з часом. Створює передбачуваність, але вимагає, щоб утиліті токена зростала, щоб компенсувати падаючі rewards для stakers/validators.
Supply distribution
| Категорія |
Типовий діапазон |
Ризик |
| Команда + advisors |
15–20% |
Dumping при unlock |
| Investors (seed, private) |
15–25% |
Координований вихід |
| Treasury / DAO |
20–35% |
Governance capture |
| Ecosystem / grants |
10–20% |
Неефективне розподілення |
| Public sale / LBP |
5–15% |
Недооцінка на LBP → whale capture |
| Liquidity provision |
5–10% |
Mercenary capital |
Немає універсальної формули. Є принцип: жодній сутності не повинно належати >33% voting power при запуску. Інакше governance — фікція.
Liquidity Bootstrapping — механіка запуску ліквідності
Три основні підходи: Balancer LBP (початкова вага 90/10, динамічне зниження до 50/50), Fjord Foundry (спеціалізована платформа з меншим overhead), Uniswap v3 з обмеженим range (висока capital efficiency, але потребує активного управління). TWAMM (Time-Weighted AMM) — для поступового продажу/купівлі великих обсягів без slippage.
Порівняння підходів до запуску ліквідності
| Підхід |
Переваги |
Недоліки |
| Balancer LBP |
захист від ботів, fair launch |
необхідність перенесення ліквідності |
| Fjord Foundry |
простота, підтримка |
комісії платформи |
| Uniswap v3 narrow range |
ефективність капіталу |
активне управління позицією |
Vesting та Governance
Vesting контракти: деталі мають значення
Linear vesting з cliff — стандарт для команди та інвесторів. cliff — період після TGE, протягом якого нічого не доступно. Після cliff — лінійний unlock до duration.
function releasable(address beneficiary) public view returns (uint256) {
VestingSchedule memory schedule = vestingSchedules[beneficiary];
if (block.timestamp < schedule.cliff) return 0;
uint256 elapsed = block.timestamp - schedule.cliff;
uint256 vestingDuration = schedule.duration - (schedule.cliff - schedule.start);
uint256 vested = schedule.totalAmount * elapsed / vestingDuration;
return vested - schedule.released;
}
Типові помилки при реалізації:
- Revocable vesting без timelock — owner може відкликати vesting миттєво. Рішення: revocation через multisig + governance vote.
- Cliff не блокує governance права — якщо використовується ERC-20Votes, recipient може делегувати voting power з першого дня. Потрібно явно розділити voting power і claim logic.
- Відсутність emergency pause — Pausable + timelock на unpause.
Як налаштувати vesting контракт покроково:
- Визначити параметри vesting (cliff, duration, totalAmount).
- Розгорнути контракт TokenVesting (наприклад, OpenZeppelin).
- Призначити beneficiary та підтвердити розклад.
- Налаштувати emergency pause та revocation через multisig.
- Протестувати сценарії за допомогою Foundry fuzz тестів.
Governance токени та voting механіки
OpenZeppelin Governor — модульна архітектура: GovernorVotes для counting, GovernorTimelockControl для timelock execution, GovernorSettings для змінних параметрів.
Quorum — мінімальний відсоток supply для валідності голосування. Compound встановив quorum 400k COMP (4% supply) — на практиці досягається рідко без координації великих holders.
Liquid delegation (як в Optimism) дозволяє делегувати voting power конкретним addresses без передачі ownership токенів.
Як обрати правильний тип токена для вашого проєкту?
Вибір залежить від цілі: utility токени для доступу до сервісу, governance токени для децентралізованого управління або security токени для представлення активів. Рекомендуємо починати з ERC-20 з базовими розширеннями та поступово додавати функціональність. Ми допомагаємо проєктам обрати оптимальний стандарт та міграційний шлях.
Які ризики виникають при використанні rebasing токенів?
Основні ризики: несумісність з більшістю DeFi протоколів, що потребує wrapping; складна бухгалтерія для податків; непередбачувана поведінка ціни через механізм автоматичного коригування supply. Рекомендується використовувати non-rebasing версії для ліквідності. Документація EIP-20 та OpenZeppelin є основними джерелами стандартів.
Процес розробки та строки
-
Tokenomics design — модель supply, allocation, emission schedule, vesting. Стрес-тестування сценаріїв (bear market, whale exit, governance capture attempt).
-
Контракт розробка — ERC-20 + extensions, vesting, governance. Foundry fuzz тести на vesting calculations, governance thresholds.
-
Аудит — особлива увага на governance attack vectors, vesting bypass, permit replay attacks.
-
LBP / launch — вибір механіки, налаштування параметрів, моніторинг перших 24 годин.
-
Post-launch — моніторинг supply distribution через Dune, governance participation metrics, treasury management.
Стек: Solidity 0.8.x, OpenZeppelin Contracts 5.x, Foundry, Gnosis Safe, OpenZeppelin Defender, Dune Analytics.
Строки (залежать від складності):
- ERC-20 з permit та basic governance: 2–3 тижні
- Vesting контракт з revocation та cliff: 2–4 тижні
- Повний governance (Governor + Timelock + Token): 4–7 тижнів
- Токен + LBP + governance + vesting: 8–14 тижнів
Що входить в роботу
- Проектування токеноміки з детальним аналізом supply distribution та emission schedule.
- Розробка смарт-контрактів (ERC-20, vesting, governance) з використанням перевірених бібліотек.
- Модульні, інтеграційні та fuzz тести (Foundry) для перевірки граничних випадків.
- Внутрішній аудит коду з використанням Slither та Mythril.
- Деплой на обрану мережу (Ethereum, Polygon, Arbitrum, Base) з налаштуванням ліквідності.
- Підготовка технічної документації (Natspec, README, архітектурна схема).
- Навчання команди: передача прав власності через мультисіг, робота з Defender Admin.
- Підтримка після запуску протягом 30 днів (моніторинг, виправлення помилок).
Зв'яжіться з нами для отримання консультації та оцінки вашого проєкту. Замовте розробку токена — ми підготуємо рішення під ключ.