Розробка governance-токена
Governance-токен — це не просто ERC-20 з доданими правами голосування. Це фундамент системи управління протоколом: від того, наскільки грамотно спроектований токен, залежить стійкість DAO до атак, маніпуляцій та захоплення влади крупними власниками.
Що включає розробка governance-токена
Базова архітектура будується на стандарті ERC-20 з розширенням через OpenZeppelin Governor або сумісні контракти. Ключові компоненти:
- ERC20Votes — додає механізм checkpoint'ів для снепшотів балансів. Голосування привʼязується не до поточного балансу, а до балансу на момент створення пропозиції. Це захищає від flash-loan атак: купити токени в межах однієї транзакції та одразу проголосувати не вийде.
- ERC20Permit — безплатна затвердження через EIP-712 підписи. Користувачі можуть дозволяти делегування без відправки on-chain транзакції.
- Delegation — механізм делегування голосів. Власник може передати своє право голосу іншій адресі, не переміщуючи токени.
Механізм голосування та Governor
Контракт Governor відповідає за повний життєвий цикл пропозицій:
propose() → голосування (delay + period) → queue() → execute()
Параметри, які критично впливають на безпеку:
| Параметр | Опис | Типові значення |
|---|---|---|
| votingDelay | Затримка перед початком голосування | 1–2 дні |
| votingPeriod | Тривалість голосування | 3–7 днів |
| proposalThreshold | Мінімум токенів для створення пропозиції | 0.1–1% supply |
| quorum | Мінімальний поріг участі | 4–10% |
TimelockController додає обов'язкову затримку між прийняттям рішення та його виконанням. Це дає громаді вікно для реакції, якщо прийнято шкідливу пропозицію. Мінімальна затримка зазвичай 48 годин.
Tokenomics та розподіл
Розподіл supply безпосередньо впливає на децентралізацію управління. Концентрація більше 20–30% в одної адреси робить DAO вразливою до governance attack.
Типова структура розподілу:
- Community treasury / DAO fund: 40–50%
- Команда та радники (vesting 3–4 роки): 15–20%
- Інвестори ранніх раундів (vesting 1–2 роки): 10–15%
- Ecosystem grants та partnerships: 10–15%
- Початкова liquidity: 5–10%
Vesting реалізується через окремі контракти (TokenVesting, VestingWallet) з лінійним або cliff-механізмом. Прямо у токен-контракт логіку vesting'а краще не вбудовувати — це ускладнює аудит.
Захист від атак
Governance attack — покупка достатньої кількості токенів для прийняття шкідливих пропозицій. Mitigation:
- Високий proposalThreshold та quorum
- TimelockController з довгою затримкою
- Guardian/veto-механізм на випадок надзвичайних ситуацій
- Snapshot-based voting (уже описано вище)
Whale dominance — домінування крупних власників. Часткові рішення: quadratic voting (дорого в gas), conviction voting (накопичення голосів з часом), delegation на спеціалізованих учасників.
Стек та інструменти
Розробка ведеться на Solidity 0.8.x, бібліотека OpenZeppelin Contracts 5.x покриває більшість потреб. Для тестування — Hardhat або Foundry (бажаніше для fuzz-тестування governance-логіки).
Розгортання та верифікація через Etherscan API, моніторинг пропозицій — Tally, Snapshot для off-chain голосувань з on-chain виконанням через SafeSnap.
Що ми робимо
Проектуємо архітектуру governance з урахуванням ваших tokenomics, розробляємо та тестуємо смарт-контракти (ERC20Votes + Governor + Timelock), налаштовуємо механізм делегування та vesting, проводимо внутрішній security review перед зовнішнім аудитом. В итогу ви отримуєте готовий до розгортання governance-модуль з документацією щодо параметрів та інструкцією для громади.