Розробка токенів на 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 днів (моніторинг, виправлення помилок).
Зв'яжіться з нами для отримання консультації та оцінки вашого проєкту. Замовте розробку токена — ми підготуємо рішення під ключ.