Розробка DAO під ключ: токени, governance, казначейство

DAO, де голосування відбувається тільки через Snapshot, а виконання — через мультисиг, ризикує централізацією. Як перейти до повноцінної on-chain демократії без втрати безпеки? Ми розробили десятки таких рішень за понад 5 років: від простих мультисигів до платформ з веТокенами та модульним governance. Наш досвід показує: більшість проблем DAO лежить у соціальному шарі, але без правильної архітектури смарт-контрактів соціальний шар не працює. Розберемо on-chain архітектуру, типові граблі в governance design та конкретні конфігурації, які ми використовуємо в production.

Архітектура Governor на Solidity

OpenZeppelin Governor (OZ 5.x) — модульний фреймворк: core логіка + interchangeable модулі для voting, counting, quorum, timelock. Більшість production DAO сьогодні використовують його або Governor Bravo (Compound).

Мінімальна конфігурація включає чотири модулі: GovernorSettings задає votingDelay (7200 блоків ≈ 1 день), votingPeriod (50400 блоків ≈ 1 тиждень) та proposalThreshold (наприклад, 1000 токенів). GovernorCountingSimple обробляє голоси FOR/AGAINST/ABSTAIN. GovernorVotes підключає токен з відстеженням делегування (ERC20Votes). GovernorTimelockControl інтегрує TimelockController для затримки виконання. Quorum задається через GovernorVotesQuorumFraction — зазвичай 4% від total supply.

ERC20Votes: знімки голосування

ERC20Votes розширює стандартний ERC-20, додаючи механізм _delegate та checkpoint історію. Кожен трансфер або делегування створює checkpoint. При голосуванні використовується voting power на блоці proposalSnapshot, а не поточний баланс — це захист від покупки токенів спеціально для голосування.

// Користувач повинен делегувати собі (або іншому) для активації voting power
token.delegate(msg.sender);

// Voting power на момент знімку
uint256 power = token.getPastVotes(account, proposalSnapshot);

Важливо: токени без делегування не беруть участі в голосуванні. Це часто дивує нових користувачів. UX повинен нагадувати про делегування при першому використанні гаманця.

Життєвий цикл proposal

1. Підготовка — створення calldata через abi.encodeWithSignature.
2. Створення — виклик governor.propose(targets, values, calldatas, description).
3. Затримка перед голосуванням — votingDelay (зазвичай 7200 блоків) фіксує знімок.
4. Голосування — votingPeriod (50400 блоків). Учасники голосують FOR, AGAINST або ABSTAIN.
5. Queue — якщо proposal пройшов, його ставлять у Timelock через governor.queue.
6. Виконання — після timelockDelay викликається governor.execute.

// Example: змінити комісію протоколу з 0.3% до 0.5%
address[] memory targets = new address[](1);
targets[0] = address(protocolFeeManager);
uint256[] memory values = new uint256[](1);
values[0] = 0;
bytes[] memory calldatas = new bytes[](1);
calldatas[0] = abi.encodeWithSignature("setFee(uint256)", 50); // 0.5% = 50 bps
governor.propose(targets, values, calldatas, "Increase protocol fee to 0.5%");

Чому важливий Timelock?

TimelockController — обов'язковий елемент production DAO. Схвалений proposal не виконується негайно: він поміщається в чергу і виконується після затримки (зазвичай 2-7 днів). Це вікно для спільноти помітити потенційно небезпечний proposal та вийти з протоколу до його виконання.

Ролі TimelockController: PROPOSER (зазвичай тільки Governor контракт), EXECUTOR (часто address(0) — anyones) та CANCELLER (мультисиг команди як safety valve). Мінімальна затримка — параметр безпеки. 48 годин — абсолютний мінімум для протоколу з реальними коштами, Compound і Aave використовують 2-7 днів.

timelock = new TimelockController(
    minDelay,          // 172800 - 2 дні
    proposers,         // масив: address(governor)
    executors,         // масив: address(0) - anyone
    admin              // мультисиг команди (CANCELLER)
);

Treasury management

DAO зазвичай керує treasury — протокольними резервами. Стандартний патерн: treasury — це сам TimelockController (він тримає ETH та токени), або окремий контракт типу Gnosis Safe з Governor як єдиним owner. Для маленьких DAO або на ранньому етапі: Gnosis Safe з мультисигом + zodiac SafeSnap модуль, який виконує Snapshot.org голосування on-chain. Це дешевше (gasless off-chain voting) і достатньо до накопичення достатньої кількості активних тримачів для on-chain governance. Перехід від мультисига до повного on-chain governance — окремий milestone. Типовий шлях: мультисиг (launch) → мультисиг + Snapshot (зростання спільноти) → повний on-chain Governor (зрілий протокол).

Treasury, що складається на 100% з native токена — високоризиковий. Ведмежий ринок обвалює runway. Production DAO диверсифікують: 20-30% USDC/DAI для операційних потреб, решта — нативний токен. Диверсифікація проводиться через governance-approved proposal на DEX swap або OTC угоду.

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

Flash loan attack

Атака: flash loan → отримати тимчасовий контроль над великою кількістю токенів → делегувати собі → створити або просунути proposal → повернути loan. Для створення proposal: proposalThreshold повинен бути достатньо високим. Для голосування: proposalSnapshot фіксується в минулому, flash loan не допомагає (в поточному блоці немає історії делегування). ERC20Votes захищений від flash loan атак на голосування саме завдяки checkpoint механізму. Захист від flash loan атак запобігає потенційним збиткам на суму від $50 000 до $5 000 000. Вразливість — тільки на proposalThreshold при його низькому значенні.

Proposal Spam та DOS

Без порогу створення пропозицій — протокол засипається сміттєвими proposals. proposalThreshold (мінімум токенів для створення proposal) — обов'язковий параметр. Типові значення: 0.1% - 1% від total supply.

Governance takeover

Якщо зловмисник накопичив > 50% voting power (або > quorum при низькій явці) — він може провести будь-який proposal. Захисти: високий quorum (4-10% від supply), Timelock з достатньою затримкою (7 днів), Guardian multisig з правом CANCELLER в TimelockController, GovernorPreventLateQuorum — продовжує voting period якщо quorum набраний в останній момент (запобігає last-minute whale swing).

Upgrades через DAO

Смарт-контракти оновлюються через DAO proposal + timelock. Патерни оновлюваності: UUPS/Transparent Proxy з Governor як owner проксі — proposal викликає upgradeTo(newImplementation). Timelock дає спільноті час перевірити новий код до його активації. Альтернатива — modular architecture без proxy: кожен модуль замінюється через governance. Менш ризиковано, ніж повний upgrade.

Delegation та off-chain coordination

Більшість тримачів не голосують напряму. Compound ввів концепцію delegate: токен-холдери делегують voting power відомим учасникам (researchers, core contributors, DAO-спеціалісти). Delegate profile — це Discourse/Mirror пост з позицією по ключових питаннях. Реалізується через ERC20Votes.delegate(). Делегування не трансферує токени — тільки voting power. Snapshot.org — gasless голосування через підпис повідомлення. Використовується для сигнальних голосувань (temperature check), не пов'язаних з on-chain діями. Типовий двоступеневий процес: temperature check на Snapshot (gasless) → on-chain proposal при підтримці 60%+.

Порівняння рішень: OZ Governor vs Governor Bravo vs Custom

Орієнтовні строки розробки DAO

Вартість розробки залежить від складності: аудит безпеки може коштувати від $10 000 до $100 000 залежно від обсягу коду та необхідного покриття тестами.

Процес роботи

1. Аналітика та проектування — визначаємо governance модель, типи голосування, склад treasury.
2. Розробка смарт-контрактів — Governor, voting token, timelock, кастомні модулі (staking, gauge, bribes). Для розробки використовуємо Solidity 0.8.x та Foundry для тестування.
3. Інтеграції — підключення Snapshot, Tally, Boardroom, The Graph для індексації.
4. Аудит — внутрішній review + зовнішній аудит (контракти перевіряються на reentrancy, oracle manipulation, flash loan).
5. Розгортання — mainnet deploy з верифікацією через Etherscan, налаштування мультисига Guardian.
6. Документація та навчання — керівництва для користувачів, опис довірених делегатів, runbook для команди.
7. Підтримка — 30 днів після запуску: моніторинг, фікс багів, інтеграційні консультації.

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

• Вихідний код смарт-контрактів з повним покриттям тестами Foundry.
• Документація з архітектури, розгортання та використання.
• Розгорнуті контракти в mainnet (або testnet за запитом).
• Інтеграція з Tally/Snapshot для off-chain голосування.
• Результати внутрішнього та зовнішнього аудиту.
• 30 днів технічної підтримки після запуску.

Наша команда — senior-розробники з багаторічним досвідом у Solidity та Rust. За плечима 20+ завершених проєктів та десятки аудитів. Ми гарантуємо прозорість кожного етапу: всі контракти в open source, аудит від незалежної фірми, постапдейт review. Зв'яжіться з нами для попередньої оцінки вашого проєкту. Отримайте консультацію з архітектури вашої DAO — оцінимо complexity та прикинемо строки.

Згідно OpenZeppelin Governor Documentation, Governor є еталонною реалізацією on-chain управління.

Строки розробки: базова DAO з OZ Governor та Timelock — від 2 до 3 тижнів розробки плюс аудит. Повноцінна платформа з кастомними модулями — від 3 до 6 місяців. Вартість розраховується індивідуально після аналізу вимог. Зв'яжіться з нами для попередньої оцінки.

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