Розробка мульти-токенної екосистеми
Більшість протоколів, досягаючи певної зрілості, приходять до мульти-токенної архітектури. Один токен не може одночасно бути хорошим засобом обміну (потрібна стабільність), інструментом governance (потрібна концентрація у довгострокових учасників) та інструментом заохочення (потрібна інфляція для залучення ліквідності). Спроба поєднати все в одному токені створює протиріччя — це Curve Finance зрозумів і створив три токени (CRV, veCRV, cvxCRV), Olympus — два (OHM, sOHM), MakerDAO — два (DAI, MKR).
Наша команда спеціалізується на проектуванні таких систем з нуля, включаючи токеноміку, смарт-контракти та аудит. Ми пропонуємо повний цикл розробки під ключ: від економічного моделювання до деплою на mainnet. Оцінимо ваш проект за 2 дні — пишіть для консультації.
Чому мульти-токенна архітектура?
Розділення функціоналу між токенами дозволяє гнучко налаштовувати стимули та знижувати системні ризики. Наприклад, governance-токен може бути locked для довгострокової зацікавленості, а utility-токен — стабільним для розрахунків. Це зменшує тиск продавців на кожен токен і створює стійкі петлі вартості.
Типології мульти-токенних систем
Governance + Utility розділення
Класичне розділення: governance token (G-token) та utility/protocol token (U-token).
G-token: управління протоколом, capturing value (fee share), довгостроковий hold incentive. Часто vote-escrowed (ve-модель Curve): locked G-token дає veG з boost на rewards та governance power.
U-token: medium of exchange всередині протоколу, стабільний (або менш волатильний), висока швидкість обігу. Наприклад: торгові комісії беруться в U-token, liquidity rewards виплачуються в G-token.
Приклад потоку вартості:
Торгова активність → Protocol fees (в U-token або ETH)
↓
Fee distribution → buyback G-token → burn або distribute держателям veG
Держателі veG отримують: fee share + boosted liquidity rewards + governance power. Це стимулює довгостроковий lock, знижуючи circulating supply G-token і створюючи buy pressure.
Debt-based стабільні системи
MakerDAO патерн: collateral token (ETH, wBTC) → debt position → стабільна монета (DAI) + governance token (MKR).
Системні ризики:
- При падінні ціни колатералю → liquidations → dump колатералю → ще більше падіння ціни
- При системній нестачі колатералю (bad debt) → mint та продаж MKR для рекапіталізації → dump ціни MKR
Це не баг, а feature: MKR є страховкою останньої інстанції. Держателі MKR мають governance power та отримують stability fees — натомість приймають хвостовий ризик рекапіталізації. Правильна токеноміка.
Liquid staking дуальні токени
Staked token (stETH, rETH) представляє застейкані активи зі зростаючим rebasing балансом або exchange rate. Governance token управляє параметрами стейкінгу протоколу.
Взаємодія: staked token генерує staking rewards → частина йде в protocol treasury → buyback/burn або distribute governance token. Governance token holders контролюють validator selection, fee parameters, protocol upgrades.
Проектування токеномічних петель
Value capture механізми
Кожен токен повинен мати ясний механізм value capture — інакше його ціна визначається лише спекуляцією:
- Buyback and burn. X% від protocol revenue використовується для buyback G-token з ринку та спалювання. Знижує supply → при стабільному demand ціна зростає. Прозоро та зрозуміло інвесторам.
- Fee distribution. Пряма виплата fee держателям staked/locked G-token. Вимагає lock mechanism, щоб не стимулювати короткостроковий dump після отримання distribution.
- Governance premium. G-token необхідний для отримання boost на yield або доступу до певних функцій. Створює utility demand окрім спекулятивного.
- Protocol-owned liquidity (POL). Olympus патерн: протокол володіє своєю ліквідністю через bonding mechanism. Користувачі продають LP tokens в treasury за дисконтований G-token (з vesting). Treasury володіє ліквідністю назавжди, не орендує її у mercenary capital.
Як гарантувати стійкість екосистеми?
Перед запуском кожен мульти-токенний дизайн потрібно протестувати на stress scenarios. Simulation: Agent-based modeling або Monte Carlo для перевірки stability при різних market conditions. Gauntlet, Chaos Labs — спеціалізовані компанії для такого аналізу.
Аналіз смерть-спіралей:
- Сценарій 1: швидке падіння G-token на 80%. Перевіряється наявність panic unlock механізму, вплив на U-token стабільність та поведінку liquidity rewards.
- Сценарій 2: набіг на U-token (bank run). Оцінюється достатність ліквідності для redemption, наявність circuit breaker (тимчасова pause redemption) та вплив на G-token.
- Сценарій 3: Oracle failure. Якщо ціна колатералю стала некоректною — аналізується вплив на debt positions та наявність emergency shutdown.
Наші інженери з 10-річним досвідом у DeFi проводять стрес-тести з використанням Foundry та Echidna, виявляючи приховані ризики до деплою. Гарантуємо прозорість кожного етапу.
Технічний стек контрактів
Token контракти
- G-token (ERC20Votes): стандартний governance token з checkpoint історією для голосування.
- veG (Vote-Escrowed): користувач локує G-token на термін (1 тиждень — 4 роки), отримує veG пропорційно
amount × time_remaining / max_lock_time. veG убуває лінійно з часом (потрібно продовжувати lock). Non-transferable (soulbound-like).
contract VotingEscrow {
struct LockedBalance {
int128 amount;
uint256 end; // unlock timestamp
}
mapping(address => LockedBalance) public locked;
function balanceOf(address addr) external view returns (uint256) {
LockedBalance memory _locked = locked[addr];
if (_locked.end <= block.timestamp) return 0;
uint256 timeLeft = _locked.end - block.timestamp;
return uint256(uint128(_locked.amount)) * timeLeft / MAXTIME;
}
}
- U-token: залежить від типу. Якщо стабільна монета — CDP контракт з liquidation engine. Якщо rebasing staked token — vault контракт з shares-based accounting (ERC4626).
Fee Router
Центральний контракт, що збирає fees та розподіляє по протоколу:
contract FeeRouter {
struct FeeDistribution {
address recipient;
uint256 basisPoints; // із 10000
}
FeeDistribution[] public distributions;
function distributeFees(address token, uint256 amount) external {
for (uint i = 0; i < distributions.length; i++) {
uint256 share = amount * distributions[i].basisPoints / 10000;
IERC20(token).safeTransfer(distributions[i].recipient, share);
}
}
}
Distributions конфігуруються через governance. Типові отримувачі: veG stakers reward pool, buyback contract, treasury, liquidity rewards distributor.
Gauge та Rewards система
Curve-style gauges: для кожного supported pool — окремий gauge контракт. Держателі veG голосують за distribution G-token emissions між gauges (gauge weight). Pool з більшою вагою отримує більше G-token emissions → більше APY → приваблює більше ліквідності.
Це створює "gauge wars": протоколи, які бажають мати deep ліквідність свого токена, купують veG і голосують за свій gauge.
contract GaugeController {
mapping(address => mapping(address => uint256)) public voteUserSlopes;
mapping(address => uint256) public gaugeWeights;
function voteForGaugeWeights(address gauge, uint256 userWeight) external {
// userWeight із 10000 (базисні пункти)
}
function getGaugeWeight(address gauge) external view returns (uint256) {
return gaugeWeights[gauge];
}
}
Мультичейн токеноміка
При деплої на кілька чейнів виникають додаткові складнощі:
- Canonical token: G-token — canonical на mainnet Ethereum. На L2 (Arbitrum, Optimism, Base) — bridged версія через official bridge. Governance voting відбувається лише на mainnet (де зберігається veG). Але rewards можна отримувати на будь-якому chain.
- Cross-chain rewards distribution: Merkle-based — раз на тиждень snapshot veG holdings на mainnet → Merkle root опублікований → користувачі claim rewards на будь-якому chain через proof.
- Supply accounting: total supply на mainnet — канонічне джерело істини, bridged tokens на L2 backed 1:1 через bridge escrow.
Governance мульти-токенної екосистеми
При кількох токенах governance складніший: хто керує параметрами (fee rates, emission schedule, gauge weights)? Рекомендований розподіл:
| Параметр | Хто керує | Механізм |
|---|---|---|
| Gauge weights | veG holders | Щотижневе голосування |
| Fee rates | G-token holders | Governor proposal + Timelock |
| Emission schedule | G-token holders | Governor proposal + Timelock |
| Emergency actions | Multisig guardian | Негайне виконання |
| Protocol upgrades | G-token holders | Governor + Timelock (7 днів) |
Multisig guardian з veto/pause power — на перехідному періоді, поки governance не обкатаний. Roadmap до повної decentralization з конкретними віхами — важливий для community trust.
Аудит та ризики
Мульти-токенна система — множення attack surface. Кожен токен, кожен їх інтерфейс — потенційна точка вразливості. Історично значні зломи:
- Beanstalk (сума збитку $182M): governance attack через flash loan. Зловмисник зайняв токени, пройшов governance vote в одному блоку, злив treasury.
- Mango Markets ($116M): oracle price manipulation → штучно завищений collateral → drain treasury через borrowing.
Специфічні аудит вимоги для мульти-токенних систем:
- Invariant testing для кожного взаємозв'язку токенів
- Flash loan attack simulation на governance
- Oracle manipulation scenarios
- Cross-chain bridge security review (якщо multi-chain)
Ми гарантуємо якість аудиту: сертифіковані аудитори з досвідом (сертифікати від OpenZeppelin, Trail of Bits). Рекомендуємо мінімум два незалежних аудити від різних компаній + публічний contest (Code4rena, Sherlock) для широкого охоплення. Вартість комплексного аудиту — від $30,000 для мульти-токенної системи.
Стек та терміни
Smart contracts: Solidity + Foundry + OpenZeppelin + Curve VotingEscrow fork (або Solidly fork для gauge system).
Testing: Foundry invariant tests, Echidna fuzzing, Foundry fork-tests на mainnet стані для realistic scenarios.
Deployment: Hardhat Ignition або Foundry scripts з детальним deployment runbook (порядок деплою контрактів важливий — залежності).
| Компонент | Термін |
|---|---|
| G-token + veG + VotingEscrow | 5-7 тижнів |
| U-token (якщо CDP/stablecoin) | 8-12 тижнів |
| Gauge controller | 4-5 тижнів |
| Fee router + rewards | 3-4 тижні |
| Governor + Timelock | 2-3 тижні |
| Frontend (dApp) | 8-12 тижнів |
| Аудит (x2) | 8-12 тижнів |
Повна мульти-токенна екосистема з двома незалежними аудитами — 9-12 місяців від початку проектування до mainnet launch. Термін сильно залежить від складності U-token компонента (stablecoin vs staked asset). В середньому наша команда вкладається в оцінки завдяки використанню Foundry (він в 2-3 рази швидше Hardhat у виконанні тестів).
Що входить в роботу
- Економічне моделювання токеноміки (Doc токеноміки)
- Смарт-контракти на Solidity з повним покриттям тестами
- Розгортання на mainnet та тестнетах
- Інтеграція з block-обозрівачами (Etherscan, Arbiscan)
- Документація для інтеграторів (API, ABI)
- Підтримка на 3 місяці після деплою
Для оцінки вашого проекту зв'яжіться з нами — ми проаналізуємо вимоги за 2 дні та запропонуємо план.