Як побудувати систему делегування голосів DAO
Проблема низької участі в управлінні DAO відома: менш ніж 5% власників токенів голосують. Делегування вирішує це, але потребує надійної архітектури. Розробляємо системи управління DAO під ключ, включаючи делегування голосів, безпечне казначейство на базі мультипідпис-гаманців. За 5+ років впровадили рішення для 30+ проектів, включаючи інтеграцію з Governor, Snapshot та модулями безпеки. Для DeFi-протоколів управління через DAO критичне — делегування підвищує активність спільноти.
Як працює механізм делегування?
Делегування реалізується через смарт-контракти стандарту ERC-20Votes (EIP-5805). Стандарт EIP-5805 описує облік делегованих голосів. Контракт веде облік делегованих голосів. При кожному голосуванні вага голосу делегата дорівнює сумі його власних токенів та всіх делегованих йому. Транзакція делегування газова, але виконується один раз. Оптимізація газу (gas optimization) – ключовий момент: ми використовуємо batch-делегування та off-chain підписи для зниження витрат. Середня вартість транзакції делегування на Ethereum в пік складає ~$30-50, що суттєво для активних спільнот — економія на газі при off-chain голосуванні може досягати $2000 на місяць.
// Приклад контракту делегування contract MyGovernor is Governor { constructor(IVotes _token) Governor("MyDAO", _token) {} function proposalThreshold() public pure override returns (uint256) { return 10000e18; // 10,000 токенів для створення proposal } } Делегати можуть голосувати off-chain (Snapshot) з подальшим on-chain виконанням через SafeSnap, що економить газ. Або повністю on-chain через Governor — тоді кожна транзакція голосування платна. Вибір залежить від активності спільноти та бюджету на газ.
Чому мультипідпис-казначейство — фундамент безпеки?
Без мультипідпису treasury — це EOA однієї людини: один приватний ключ, повний контроль. Gnosis Safe вирішує це через M-of-N схему: транзакція виконується тільки за наявності M підписів з N призначених. Safe — де-факто стандарт: понад $100B зберігається в Safe гаманцях, найбільші DAO (Uniswap, ENS, Aave) використовують його.
Архітектура Safe
Safe — смарт-контракт, не EOA. Власники (owners) — список адрес, threshold — мінімальна кількість підписів. Транзакція проходить етапи: propose, sign (off-chain/on-chain), execute. Off-chain підписи дешевші — тільки виконуючий платить газ.
Параметри налаштування
| Розмір DAO | Owners | Threshold | Логіка |
|---|---|---|---|
| Маленький (core team) | 5 | 3 | 3-of-5 |
| Середній | 7-9 | 5 | 5-of-7 або 5-of-9 |
| Великий (subDAO) | 11-13 | 7 | 7-of-11 |
Threshold не повинен бути надто низьким (2-of-10 — ризик) або надто високим (блокування при втраті ключів). Ротація owners раз на 6-12 місяців — практика.
Guard-контракти та модулі
Guard — викликається до та після кожної транзакції: дозволяє ліміти, whitelist, затримки. Модулі (наприклад, Zodiac Roles) делегують виконання обмеженим операторам без повного доступу.
interface IGuard { function checkTransaction( address to, uint256 value, bytes memory data, Enum.Operation operation ) external; function checkAfterExecution(bytes32 txHash, bool success) external; } Як інтегрувати Governor з Snapshot?
Чистий Safe — тільки мультипідпис. Для тисяч власників токенів потрібен Governor (пропорційне голосування). Типова архітектура: Governor → Timelock → Safe. SafeSnap (Snapshot + Safe) з'єднує off-chain голосування з on-chain виконанням через оракул Reality.eth. Це поєднує безкоштовне голосування з безпечним виконанням.
Приклад конфігурації SafeSnap
Налаштування включає розгортання Snapshot простору, модуля SafeSnap та оракула Reality.eth. Модуль перевіряє, що результат голосування підтверджений оракулом, потім виконує транзакцію через Safe. Весь процес on-chain займає ~1 годину при стандартних налаштуваннях.
Порівняння підходів
| Підхід | Голосування | Виконання | Газові витрати | Безпека |
|---|---|---|---|---|
| Повністю on-chain | Governor on-chain | Safe | Високі (~$50 за транзакцію) | Максимальна |
| Snapshot + SafeSnap | Snapshot off-chain | Safe + Reality.eth | Низькі (~$10 за виконання) | Залежить від оракула |
Як проходить розробка під ключ?
- Аналітика: оцінка поточної архітектури, вибір стеку (Ethereum/Polygon/Arbitrum), визначення параметрів делегування.
- Проектування: схема Governor → Safe, вибір модулів, конфігурація threshold.
- Реалізація: деплой контрактів, налаштування Snapshot, інтеграція з SafeSnap (якщо потрібно).
- Тестування: unit-тести (Foundry), інтеграційні тести на testnet, аудит безпеки (Slither, Mythril).
- Деплой та документація: mainnet деплой, процедури ротації owners, recovery passphrase, навчання команди.
Що входить у роботу
- Проектування та деплой смарт-контрактів (Safe, Governor, модулі)
- Налаштування Snapshot простору та SafeSnap модуля
- Інтеграція з Timelock (при необхідності)
- Написання та розгортання кастомних Guards
- Повне тестування (testnet + audit-like перевірки)
- Документація процедур (ротація, відновлення, екстрені дії)
- Пост-деплой підтримка 1 місяць
Терміни та вартість
Терміни: від 4 до 6 тижнів залежно від складності (кастомні модулі, аудит). Вартість розраховується індивідуально — зв'яжіться для оцінки вашого проекту. Ми гарантуємо дотримання термінів та безпеку контрактів. Отримайте консультацію: напишіть нам для обговорення.
Часті помилки та рекомендації
- Надто низький threshold: 2-of-10 — один скомпрометований ключ майже не заважає атаці. Рекомендується не менше 50%+1 від owners.
- Зберігання seed phrases у хмарі: використовуйте hardware wallets та фізично розділені локації.
- Відсутність ротації owners: процедуру ротації потрібно заздалегідь протестувати. Рекомендується раз на півроку.
- Невикористання Guards: без guard будь-яка транзакція може бути виконана при threshold. Додайте ліміти за сумою та whitelist.
- Ігнорування соціальної інженерії: всі термінові запити перевіряти в офіційних каналах.
Наш досвід: 5+ років у Web3, 30+ реалізованих DAO-систем, робота з провідними протоколами. Отримайте консультацію: зв'яжіться з нами для обговорення вашого проекту.