Розробка системи делегування голосів DAO з мультипідписом

Як побудувати систему делегування голосів 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 підписи дешевші — тільки виконуючий платить газ.

Параметри налаштування

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. Це поєднує безкоштовне голосування з безпечним виконанням.

Порівняння підходів

Як проходить розробка під ключ?

1. Аналітика: оцінка поточної архітектури, вибір стеку (Ethereum/Polygon/Arbitrum), визначення параметрів делегування.
2. Проектування: схема Governor → Safe, вибір модулів, конфігурація threshold.
3. Реалізація: деплой контрактів, налаштування Snapshot, інтеграція з SafeSnap (якщо потрібно).
4. Тестування: unit-тести (Foundry), інтеграційні тести на testnet, аудит безпеки (Slither, Mythril).
5. Деплой та документація: 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-систем, робота з провідними протоколами. Отримайте консультацію: зв'яжіться з нами для обговорення вашого проекту.

Розробка 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 подібних проєктів і знаємо, де приховуються ризики. Отримайте консультацію щодо вашої поточної конфігурації або параметрів для нового протоколу.