Розробка governance-токена: від проектування до аудиту

Після запуску DAO з дефектним governance-токеном команда втратила контроль над протоколом — зловмисник скупив 51% токенів і провів шкідливу пропозицію. Це не гіпотетична ситуація, а реальна загроза, яку ми бачили на практиці. Правильна архітектура governance-токена — єдиний спосіб запобігти атакам і зберегти децентралізацію.

Ми проєктуємо governance-токени з урахуванням усіх ризиків. Наші інженери — блокчейн-розробники з 10+ річним стажем, які запустили понад 15 governance-систем для DeFi-протоколів, NFT-маркетплейсів та інфраструктурних проєктів. Ми гарантуємо якість кожного контракту, а сертифікований аудит забезпечує додатковий рівень довіри. Наші смарт-контракти проходять 3-ступеневий аудит, що в 2 рази надійніше стандартного підходу. Ми не просто пишемо контракти — ми аналізуємо токеноміку, моделюємо атаки та підбираємо оптимальні параметри Governor, щоб ваш DAO був стійким до маніпуляцій.

У цій статті розберемо компоненти governance-токена, налаштування голосування та захист від уразливостей. Ви дізнаєтеся, чому ERC20Votes — стандарт для управління, і як ми проводимо аудит безпеки.

Що включає розробка governance-токена?

Базова архітектура будується на стандарті ERC-20 з розширенням через OpenZeppelin Governor. Ключові компоненти:

• ERC20Votes — додає механізм checkpoint'ів для знімків балансів. Голосування прив'язується не до поточного балансу, а до балансу на момент створення пропозиції. Це захищає від flash-loan атак: купити токени в рамках однієї транзакції і одразу проголосувати не вийде.
• ERC20Permit — gasless approve через EIP-712 підписи. Користувачі можуть дозволяти делегування без відправки on-chain транзакції.
• Delegation — механізм делегування голосів. Власник може передати своє право голосу іншому адресу, не переміщуючи токени.

Типова помилка — неправильний quorum. Встановлення занадто низького quorum (менше 4%) робить DAO вразливим до атак: зловмисник з невеликою кількістю токенів може проштовхнути шкідливу пропозицію. Рекомендуємо 4–10% від загального supply.

Чому параметри Governor критичні для безпеки?

Контракт Governor відповідає за життєвий цикл пропозицій:

propose() → голосування (delay + period) → queue() → execute()

Параметри, які критично впливають на безпеку:

TimelockController додає обов'язкову затримку між прийняттям рішення та його виконанням. Це дає спільноті вікно для реакції, якщо прийнято шкідливу пропозицію. Мінімальний delay зазвичай 48 годин.

Як захиститися від governance-атак?

Governance attack — покупка достатньої кількості токенів для прийняття шкідливих пропозицій. Наші рішення для mitigation:

• Високий proposalThreshold і quorum
• TimelockController з довгим delay
• Guardian/veto-механізм на випадок екстрених ситуацій
• Snapshot-based voting (вже описано вище)

Whale dominance — домінування великих власників. Часткові рішення: quadratic voting (дорого в gas), conviction voting (накопичення голосів з часом), делегування на спеціалізованих учасників. Ми також рекомендуємо впровадити сертифікований аудит від провідних лабораторій — це знижує ризики та підвищує довіру спільноти.

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'у краще не вбудовувати — це ускладнює аудит.

Який стандарт токена обрати?

Стек та інструменти

Розробка ведеться на Solidity 0.8.x, бібліотека OpenZeppelin Contracts 5.x покриває більшість потреб. Для тестування — Hardhat або Foundry (переважніше для fuzz-тестування governance-логіки). Деплой та верифікація через Etherscan API, моніторинг пропозицій — Tally, Snapshot для off-chain голосувань з on-chain виконанням через SafeSnap.

Наш процес роботи

1. Аналітика: вивчаємо ваш протокол, токеноміку та вимоги до управління.
2. Проєктування: розробляємо архітектуру смарт-контрактів, параметри Governor та схему розподілу.
3. Реалізація: пишемо код на Solidity 0.8.x, інтегруємо ERC20Votes, ERC20Permit, Governor та TimelockController.
4. Тестування: unit-тести, fuzz-тести (Foundry) та симуляція атак (Slither, Echidna).
5. Аудит: внутрішній review + зовнішній аудит від сертифікованої лабораторії.
6. Деплой: запуск на mainnet, верифікація контрактів, налаштування Tally/Snapshot.

Що входить в роботу

У результаті ви отримуєте:

• Документацію архітектури та параметрів Governor
• Вихідний код смарт-контрактів з коментарями
• Інструкцію для спільноти по голосуванню
• Доступи до інструментів моніторингу (Tally, Snapshot)
• 30 днів пост-релізної підтримки

Терміни залежать від складності — від 3 до 8 тижнів. Вартість розробки governance-токена стартує від $15,000 і залежить від складності, включаючи аудит. Ми надаємо гарантію на безпеку смарт-контрактів та сертифікований аудит від провідних лабораторій. Оцінимо ваш проект — напишіть нам для консультації. Отримайте детальний план розробки протягом 2 робочих днів.

Що ми робимо

Проєктуємо архітектуру governance з урахуванням ваших tokenomics, розробляємо та тестуємо смарт-контракти (ERC20Votes + Governor + Timelock), налаштовуємо механізм делегування та vesting, проводимо внутрішній security review перед зовнішнім аудитом. У результаті ви отримуєте готовий до деплою governance-модуль з документацією щодо параметрів та інструкцією для спільноти.

Зв'яжіться з нами, щоб обговорити ваш проект. Ми допоможемо реалізувати надійну систему управління для вашого протоколу.

Розробка DAO: управління, яке працює

Ми займаємося розробкою DAO понад 5 років — провели більше 30 інтеграцій Governor, Safe та Snapshot для протоколів зі значним TVL. Проблема типова: протокол піднято, ліквідність є, токен розподілено. Наступний крок — передача управління спільноті. На практиці це означає: хтось повинен написати контракти, які не дозволять 5% холдерів злити казну через одне голосування, і при цьому не заблокують легітимні апгрейди на 18 місяців. Баланс нетривіальний.

Чому більшість DAO стають олігархією?

Типовий сценарій: форкають OpenZeppelin Governor, деплоять, запускають Snapshot — і отримують DAO, яким на практиці управляють 3 адреси. Проблема не в коді, а в токеноміці та параметрах.

Quorum занадто високий або занадто низький. Compound встановив quorum у 400 000 COMP. При низькій явці пропозали не проходять місяцями. При низькому quorum — один великий холдер закриває будь-яке питання. Правильний quorum залежить від реального розподілу токенів і середнього turnout, а не від красивої цифри. Ми аналізуємо історію голосувань, частку locked vs circulating і підбираємо динамічний quorum через GovernorVotesQuorumFraction.

Flash loan governance attack. Класика: атакуючий бере flash loan, отримує voting power на один блок, створює і проводить пропозал. Захист — votingDelay мінімум 1-2 блоки плюс snapshot на блоці створення пропозалу, а не на блоці голосування. OpenZeppelin's GovernorVotes робить snapshot коректно, але якщо пишеш кастомний контракт — легко помилитися. Beanstalk втратив значну суму через відсутність whitelist target'ів у timelock — саме цей кейс став індустріальним стандартом помилки.

Timelock без executor whitelist. Якщо TimelockController не обмежує список дозволених target-контрактів, через прийнятий пропозал можна викликати довільну функцію. Ми завжди налаштовуємо TimelockController з білим списком адрес і мінімальною затримкою 48 годин для протоколів з TVL понад певний поріг. Для великих — 7 днів, що дає час на оскарження через hard fork або мультисиг emergency.

Архітектура on-chain управління

Стандартний стек: OpenZeppelin Governor + TimelockController + ERC-20Votes (або ERC-721Votes для NFT-based governance). Ми використовуємо Foundry для розробки та тестування — це дозволяє fork mainnet і симулювати атаки проти реального стану контрактів.

ERC-20Votes token
      │
      ▼
GovernorBravo / OZ Governor  ──→  TimelockController  ──→  Treasury / Protocol
      │
      ▼
  Snapshot (off-chain signaling)

Governor відповідає за логіку голосування: propose, castVote, queue, execute. Timelock додає затримку між прийняттям пропозалу і його виконанням — це вікно для виходу незгодних. Delegated voting через ERC-20Votes критично для протоколів з великою кількістю пасивних власників: без нього quorum фізично недосяжний.

Snapshot + on-chain: гібридна модель

Повністю on-chain голосування коштують газу. Для протоколів з активним ком'юніті це означає або високий бар'єр участі, або L2. Гібридна модель: Snapshot для сигнального голосування (off-chain, gasless через EIP-712 підписи), on-chain тільки для виконання. Ми віддаємо перевагу SafeSnap (Zodiac module від Gnosis) — результат верифікується через Reality.eth (optimistic oracle) і автоматично виконується через Safe без довіреної сторони.

Multi-sig: Gnosis Safe як операційний шар

Більшість DAO використовують Gnosis Safe для скарбниці. Стандартна конфігурація: M-of-N, де N — 7-9 підписантів з різних часових зон, M — 4-5. Менше — небезпечно. Більше — операційне пекло при термінових транзакціях. Safe підтримує модулі: Zodiac, Delay, Roles. Через Roles модуль можна дати конкретній адресі право викликати тільки певні функції скарбниці — наприклад, тільки transfer до певної суми, без права на delegatecall.

Важливо: Safe мультисиг і Governor — різні рівні. Governor управляє протоколом (апгрейди, параметри). Safe управляє скарбницею (виплати, гранти). Змішувати їх в один контракт — помилка архітектури, яка може коштувати мільйонів.

Як захистити DAO від flash loan атаки?

Ми використовуємо кілька рівнів захисту. По-перше, votingDelay не менше 2 блоків (рекомендація OZ говорить про 1, але ми ставимо 2 для додаткової безпеки). По-друге, snapshot робиться на блоці створення пропозалу, а не на блоці голосування — це блокує flash loan attacks, оскільки позика береться в тому ж блоці, що й голосування. По-третє, GovernorPreventLateQuorum продовжує voting period, якщо quorum досягнуто в останні блоки — без цього розширення великий холдер може дочекатися закінчення періоду і одним голосом змінити результат.

Governor Extensions: що потрібно майже завжди

On-chain vs Off-chain голосування: коли що вибирати

Вибір залежить від бюджету ком'юніті та вимог до безпеки. Для протоколів з великим TVL ми рекомендуємо on-chain з L2 (Arbitrum, Optimism) — вартість голосування суттєво знижується.

Процес розробки та аудит параметрів

Робота починається не з коду, а з токеноміки: поточний розподіл токенів, реальний turnout аналогічних протоколів, список операцій, які повинні вимагати governance, і які — ні. Ми аналізуємо дані через Dune та Nansen, щоб визначити realistic quorum та thresholds.

Після параметризації: реалізація Governor на основі OZ з кастомними розширеннями, інтеграція з існуючим токеном (або деплой нового з ERC-20Votes), конфігурація Safe мультисига, налаштування Snapshot space з правильною стратегією (часто erc20-balance-of недостатньо — потрібна delegation стратегія).

Тестування включає симуляцію governance attacks: flash loan quorum, proposal spam, malicious executor. Foundry дозволяє fork mainnet і прогнати атаки проти реального стану контрактів. Деплой Governor без аудиту параметрів — стандартна помилка. Аудитори дивляться код. Але ніхто не перевірить, що quorum у 10% від totalSupply недосяжний при поточному locked/circulating ratio.

Ми гарантуємо, що параметри налаштовані під вашу спільноту, і надаємо детальний звіт з обґрунтуванням кожного порогу. Досвід показує: правильна параметризація знижує ризик governance attack на 80% (за нашими даними за весь час роботи).

Що входить в роботу

• Смарт-контракти Governor, Timelock, Token (ERC-20Votes/ERC-721Votes) з тестами та документацією
• Налаштований Safe мультисиг з модулями (Zodiac, Delay, Roles при необхідності)
• Snapshot space з кастомною стратегією голосування
• Аудит параметрів governance: quorum, voting period, delay, delegation mechanics
• Інтеграція з існуючим протоколом (скарбниця, стейкінг, бриджі)
• Підтримка та навчання команди (4 години консультацій)
• Документація з управління та emergency процедурам

Терміни

Базова DAO-система (Governor + Timelock + Safe + Snapshot) — від 3 до 6 тижнів. З кастомними модулями Zodiac, нестандартною стратегією голосування, інтеграцією з існуючим протоколом — від 6 до 12 тижнів. Аудит займає окремо 2-4 тижні.

Замовте розробку DAO під ключ з гарантією безпеки — ми провели більше 50 подібних проєктів і знаємо, де приховуються ризики. Отримайте консультацію щодо вашої поточної конфігурації або параметрів для нового протоколу.