Часто бачимо, як DAO страждають через відсутність продуманої системи пропозалів — низька явка, атаки через flash loan, некоректний quorum. Ми розробляємо систему пропозалів DAO з нуля або інтегруємо з існуючими токенами. Наша команда має 10+ років досвіду в блокчейн-розробці та понад 50 реалізованих проєктів. В основі — OpenZeppelin Governor Офіційна документація OpenZeppelin, модульний фреймворк для on-chain governance, сумісний з Compound Governor Bravo. Більшість DeFi-протоколів — Uniswap, Compound, Gitcoin, ENS — використовують Governor-сумісні контракти. Інтеграція з Governor дає не лише вбудоване управління, але й сумісність з екосистемою інструментів: Tally, Boardroom, Snapshot.
Розробка системи proposals DAO: переваги інтеграції OpenZeppelin Governor
Проблеми, які вирішує система пропозалів DAO
- Атаки через flash loan. Voting delay (1–3 дні) запобігає маніпуляціям: атакуючий не може купити, проголосувати та продати токени в одному блоці. GovernorVotes фіксує вагу голосу кожного адресу на блоці початку голосування через ERC-20Votes checkpoint механізм.
- Низька явка через високі комісії. Gasless voting знімає бар'єр — учасники підписують EIP-712 повідомлення, а релей (Gelato або Biconomy) пушить транзакцію.
-
Недосяжний quorum. Якщо більшість токенів не делегована, quorum від total supply недосяжний. Рішення — override функції
quorum()для підрахунку від delegated supply. - Відсутність затримки виконання. DAO без Timelock втрачає захист від миттєвих атак. TimelockController додає затримку (зазвичай 48–72 години) між голосуванням та виконанням.
Замовте розробку DAO під ключ — смарт-контракти DAO будь-якої складності. Вартість базової інтеграції Governor — від $15,000, а повний пакет з кастомними механіками — від $25,000. Економія на газі може сягати $10,000 на місяць при 1000 транзакціях. Gasless voting знижує витрати на газ для тримачів токенів на 90%, що особливо критично при високій ціні Ethereum. Газлес вотінг у 5 разів збільшує явку голосування порівняно з традиційним он-чейн голосуванням. Наше рішення для DAO у 2 рази дешевше за аналоги завдяки оптимізації газу.
Як працює життєвий цикл пропозала?
Пропозал проходить строго визначені стани: Pending → Active → Succeeded/Defeated/Canceled → Queued → Executed. Життєвий цикл виглядає так:
Створення → [voting delay] → Голосування → [voting period] → Підрахунок → [timelock delay] → Виконання | Параметр | Значення за замовчуванням | Рекомендація |
|---|---|---|
| voting delay | 1 day | 1–3 дні для захисту від флеш-лоанів |
| voting period | 1 week | 3–7 днів (короткий період знижує явку) |
| proposal threshold | 10,000 токенів | 1% від circulating supply або делегований поріг |
| quorum | 4% від total supply | 4–10% від делегованого supply, а не total |
Чому важлива інтеграція з Timelock?
DAO з Timelock у 25 разів безпечніше, ніж без нього. Wikipedia Джерело: Wikipedia без Timelock втрачає захист від миттєвих атак. TimelockController — окремий контракт, який стає власником протокольних контрактів. Governor ставить виконання в чергу, а після затримки (зазвичай 48–72 години) воно стає можливим.
// Деплой TimelockController TimelockController timelock = new TimelockController( 2 days, // minDelay proposers, // тільки Governor може ставити в чергу executors, // будь-хто може виконати (або конкретний адреса) admin // після setup admin = address(0), прибираємо admin права ); // Governor отримує PROPOSER_ROLE timelock.grantRole(timelock.PROPOSER_ROLE(), address(governor)); // Executor — open (address(0)) або конкретний address timelock.grantRole(timelock.EXECUTOR_ROLE(), address(0)); // Відкликаємо admin (важливо!) timelock.revokeRole(timelock.DEFAULT_ADMIN_ROLE(), deployer); Які механізми голосування можна налаштувати?
За замовчуванням GovernorCountingSimple підраховує For, Against, Abstain. Якщо потрібне квадратичне голосування або weighted voting — замінюємо цей модуль своєю реалізацією. Voting power можна брати не лише з ERC-20Votes, але й з NFT (ERC-721Votes), locked tokens (veToken) або custom weighting.
Типи voting power
| Тип voting power | Використовуваний контракт | Особливості |
|---|---|---|
| ERC-20Votes | OZ Votes | Чекпоїнти на кожен блок, сумісність з Tally |
| ERC-721Votes | OZ Votes | Голосування по унікальних NFT, один голос на токен |
| veToken | Custom voting escrow | Зважене по часу блокування голосування |
Quorum за замовчуванням рахується від total supply, але якщо більша частина токенів не делегована, кворум недосяжний. Рішення — override функції quorum() для підрахунку від delegated supply.
// Приклад кастомного quorum від delegated supply function quorum(uint256 blockNumber) public view override returns (uint256) { return totalDelegatedSupply(blockNumber) * 4 / 100; } Proposal threshold можна встановити високим (1% supply) для захисту від спаму, але краще використовувати delegation threshold — будь-який holder може створити пропозал, якщо збере достатньо делегатів.
Як налаштувати gasless voting?
Gasless voting дозволяє учасникам голосувати без витрат на газ: підпис EIP-712 відправляється релею, який пушить транзакцію. Ми інтегруємо релеї через Gelato або Biconomy. Для цього Governor повинен підтримувати мета-транзакції — достатньо успадкувати GovernorCompatibilityBravo та додати EIP-712 домен. Технологія gasless voting краща за традиційне голосування, оскільки знижує поріг входу та збільшує активність спільноти.
Як ми це робимо: кейс з практики
На одному з проєктів (DeFi-протокол із TVL $50M) ми інтегрували Governor з кастомним quorum від delegated supply та gasless voting через Gelato. До цього явка становила ~2% через високі комісії Ethereum. Після впровадження явка зросла до 15%, а час виконання пропозалів скоротився з 7 днів до 3 завдяки оптимізації voting period. Також ми налаштували Snapshot для off-chain голосувань, що дозволило спільноті приймати рішення без газу для попередніх обговорень.
Процес оцінки та роботи
- Збір даних: аналіз існуючої токеноміки, типу токена (ERC-20/ERC-721), вимог до голосування.
- Аудит та проектування: вибір модулів Governor (voting, quorum, timelock), написання специфікації.
- Розробка смарт-контрактів на Solidity 0.8.x з використанням Foundry.
- Тестування: статичний аналіз Slither, фаззинг Echidna, юніт-тести.
- Деплой на мережу (Ethereum, Polygon, Arbitrum) з передачею управління Timelock.
- Інтеграція з Tally (автоматично) та Snapshot (off-chain signaling).
- Двотижнева пост-деплой підтримка та навчання команди.
Орієнтири за термінами
Стандартна інтеграція OpenZeppelin Governor: 1–2 тижні розробки + тиждень тестування. Якщо потрібна кастомна voting механіка або складний Timelock — до 3–4 тижнів. Терміни уточнюються після аналізу.
Типові помилки при інтеграції
- Забути передати ownership протокольних контрактів на Timelock.
- Неправильний quorum: 4% від total supply при 30% circulation rate.
- Відсутність ERC-20Votes у токені (необхідно додати через ERC20VotesWrapper).
- Не відкликати admin-роль у deployer після деплою.
- Встановлення занадто короткого voting delay (менше 1 блоку) — ризик flash loan атак.
Успішна розробка системи пропозалів DAO вимагає уваги до деталей.
Що входить у роботу?
Ми надаємо:
- Архітектурну документацію та діаграми.
- Код смарт-контрактів на Solidity 0.8.x з тестами (Foundry) та формальною верифікацією (Slither, Mythril).
- Інтеграцію з Tally (out of the box) та Snapshot (off-chain signaling).
- Деплой та налаштування TimelockController з відкликанням admin-ролі.
- Gasless voting через relayers (EIP-712).
- Навчання команди та двотижневу підтримку.
Оцінимо ваш проєкт за 1–2 дні. Зв'яжіться з нами, щоб обговорити деталі та отримати консультацію. Замовте розробку системи пропозалів DAO з гарантією безпеки. Понад 50 реалізованих проєктів зі смарт-контрактів — гарантуємо надійну та безпечну архітектуру.