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

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1306 послуг
Розробка системи делегування голосів DAO
Середній
~3-5 днів
Часті запитання

Напрямки блокчейн-розробки

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1306
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1218
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    920
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1147
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    610
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    885

Розробка мультисиг казни DAO (Gnosis Safe)

Казна DAO — це спільний гаманець, яким керує не одна людина, а група. Без мультисигу казна — це EOA (externally owned account) однієї людини: один приватний ключ, одна людина, повний контроль. Gnosis Safe вирішує це через схему M-of-N: транзакція виконується тільки якщо M з N призначених підписантів її затвердять.

Safe (раніше Gnosis Safe) — де-факто стандарт мультисигу у Web3. Більше $100B зберігається в гаманцях Safe. Більшість великих DAO (Uniswap, ENS, Aave, Lido) використовують Safe для казни або як Гранді для Governor.

Як працює Safe

Архітектура контракту

Safe — це смарт-контракт гаманець, не EOA. Це фундаментально: у нього немає приватного ключа; він існує як контракт на блокчейні. Власники — це список адрес; поріг — мінімальна кількість необхідних підписів.

Транзакція Safe проходить кілька етапів:

  1. Будь-який власник пропонує транзакцію (propose)
  2. Інші власники її підписують (off-chain чи on-chain підписи)
  3. Коли зібрано поріг підписів — будь-хто може виконати (execute)
  4. Контракт Safe перевіряє підписи й викликає цільову адресу

Підписи можуть бути off-chain (типізовані дані EIP-712, зберігаються в Transaction Service Safe) або on-chain (затвердження транзакції від кожного власника). Off-chain дешевше — тільки виконавець платить газ.

Safe Transaction Service

Safe підтримує off-chain координацію через Transaction Service — централізований (але open-source) бекенд. Власники підписують транзакцію через UI Safe{Wallet} або SDK й відправляють підпис у Transaction Service. Інші власники бачать очікуючу транзакцію й підписують там же. Коли набраний поріг — виконання.

Це не on-chain: підписи зберігаються на сервері Safe. Компромісс — зручність vs. довіра до інфраструктури Safe. Для максимальної незалежності ви можете запустити власний Transaction Service (open-source).

Інтеграція Safe + Governor

Чому інтегрувати з Governor

Чистий Safe вимагає підписів M-of-N від фіксованого списку власників. Це мультисиг, не управління. Для DAO з тисячами емітентів токенів вам потрібен Governor (голосування пропорційне до холдингів).

Типова архітектура: Governor → Timelock → Safe. Пропозиція Governor при успіху ставить транзакцію в чергу Timelock. Після затримки — виконує її через Safe (або безпосередньо, якщо Safe володіє Timelock).

Більш гнучкий: Safe як Гранді для Governor. Мультисиг команда може наложити вето на пропозицію перед виконанням. Це "децентралізація з тренувальними колесами" — ранній етап протоколу, поки управління не обкатане.

SafeSnap (Snapshot + Safe)

SafeSnap з'єднує off-chain голосування (Snapshot) з on-chain виконанням (Safe) через оракул (Reality.eth):

  1. Snapshot голосування завершується — результат публічний
  2. Будь-хто може запитати Reality.eth: "Чи була пропозиція X затверджена на Snapshot?"
  3. Респонденти відповідають (з bonds); відповідь фіналізується після періоду суперечок
  4. Модуль SafeSnap у Safe дозволяє виконати транзакцію, якщо Reality.eth підтверджує результат

Це дозволяє управління без витрат газу (безкоштовне голосування Snapshot) з on-chain виконанням. Компромісс — оракул Reality.eth додає затримку (період суперечок 3-7 днів) та теоретично вразливий до маніпуляцій при малому TVL.

Налаштування Safe для DAO

Вибір параметрів

Кількість власників та поріг. Типові конфігурації:

Розмір DAO Власники Поріг Логіка
Малий (основна команда) 5 3 3-of-5
Середній 7-9 5 5-of-7 або 5-of-9
Великий (subDAO) 11-13 7 7-of-11

Поріг не повинен бути занадто низьким (2-of-10 — один скомпрометований ключ ледве ускладнює атаку) або занадто високим (8-of-9 — втрата двох ключів блокує казну).

Ротація власників. Safe підтримує додавання/видалення власників та зміну порога через safeTx. Ротація кожні 6-12 місяців — найкраща практика. Процедура зміни власника повинна бути задокументована й протестована заздалегідь.

Safe Guards

Guard — контракт, який викликається перед і після кожної транзакції Safe. Дозволяє додати користувацьку логіку: лімити транзакцій за розміром, whitelist цільових адрес, обмеження часу.

interface IGuard {
    function checkTransaction(
        address to,
        uint256 value,
        bytes memory data,
        Enum.Operation operation,
        // ...
    ) external;
    
    function checkAfterExecution(bytes32 txHash, bool success) external;
}

Приклад: guard, який дозволяє безлімітні транзакції тільки якщо всі N власників підписали (не поріг), але транзакції над $100K вимагають додаткової затримки.

Safe Modules

Module — контракт, якому Safe делегує права виконання транзакцій без порога. Для автоматизації: повторювані платежі, потокова зарплата, Zodiac Roles (дозвіл на основі ролей).

Zodiac (Gnosis Guild) — фреймворк модулів DAO. Reality Module (SafeSnap), Roles Module (гранульовані дозволи), Exit Module (rage quit). Встановлюється через UI Safe.

Zodiac Roles Module — призначити адресам ролі з обмеженими дозволами: "ця адреса може викликати тільки функцію X контракту Y з параметрами в діапазоні Z." Корисна для делегування операційних задач без повного доступу до казни.

Безпека та операційні ризики

Компрометація ключів

Основний ризик — компрометація ключів власників. Пом'якшення:

  • Апаратні гаманці (Ledger, Trezor) для кожного власника — обов'язково
  • Різні пристрої, різні фізичні місцеризми
  • Ніколи не зберігайте фрази seed в хмарі чи мессенджерах
  • Звичайні навчання: тестові транзакції від кожного ключа щомісячно

Соціальна інженерія — другий по частоті вектор. Власник отримує "терміновий" запит підписати транзакцію. Процедура: обговорити будь-яку транзакцію в офіційному каналі; без "термінових" підписів без публічного обговорення.

Втрачений ключ

Якщо поріг підписів стає недосяжним (втрачені ключі) — кошти заморожені назавжди. Для захисту: зберігайте фразу відновлення у кількох фізично розділених безпечних місцях (не у однієї людини); протестуйте процедуру відновлення заздалегідь.

Процес і графік

Деплой Safe та базове налаштування — 1-2 дні. Інтеграція з Governor через Timelock — 1 тиждень. SafeSnap + Reality.eth + повне тестування — 2-3 тижні. Користувацькі Guards/Modules + документація процедур — 1-2 додаткові тижні.

Всього для production-ready казни DAO з інтеграцією управління — 4-6 тижнів.