Розробка DAO (децентралізованої автономної організації)

Розробка DAO

DAO — це смарт-контракти + соціальний шар. Контракти забезпечують виконання рішень без довіри до конкретних людей; соціальний шар формує консенсус перед тим, як що-небудь йде on-chain. Технічно ви можете побудувати DAO за тиждень, використовуючи Governor Bravo або OpenZeppelin Governor. Але більшість DAO з якісним кодом помирають саме через погану архітектуру управління, а не через код.

Тут ми розглянемо обидва шари: що саме реалізується on-chain, які паттерни працюють у production, і де дизайн управління важливіший за код.

On-chain архітектура Governor

OpenZeppelin Governor як основа

OpenZeppelin Governor (OZ 4.x+) — це модульний фреймворк: базова логіка плюс взаємозамінні модулі для голосування, підрахунку, кворуму та timelock. Більшість production DAO зараз використовують його або Governor Bravo (Compound).

Мінімальна конфігурація:

contract MyDAO is
    Governor,
    GovernorSettings,        // votingDelay, votingPeriod, proposalThreshold
    GovernorCountingSimple,  // FOR / AGAINST / ABSTAIN
    GovernorVotes,           // ERC20Votes або ERC721Votes
    GovernorVotesQuorumFraction, // кворум як % загального пропозиції
    GovernorTimelockControl  // інтеграція з TimelockController
{
    constructor(IVotes _token, TimelockController _timelock)
        Governor("MyDAO")
        GovernorSettings(7200, 50400, 1000e18) // 1 день затримки, 1 тиждень голосування, 1000 токенів поріг
        GovernorVotes(_token)
        GovernorVotesQuorumFraction(4) // 4% кворум
        GovernorTimelockControl(_timelock)
    {}
}

ERC20Votes: Снапшоти голосування

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

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

// Голосувальна сила в момент снапшоту
uint256 power = token.getPastVotes(account, proposalSnapshot);

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

TimelockController: Затримка виконання

Timelock обов'язковий для production DAO. Затвердене пропозиція не виконується негайно; воно ставиться в чергу й виконується після затримки (зазвичай 2-7 днів). Це вікно дозволяє спільноті помітити потенційно небезпечні пропозиції й вийти з протоколу перед виконанням.

Ролі TimelockController:

• PROPOSER — хто може ставити пропозиції в чергу (звичайно лише контракт Governor)
• EXECUTOR — хто може виконувати (часто address(0) — будь-хто)
• CANCELLER — хто може скасовувати (мультисиг команди як клапан безпеки)

Мінімальна затримка — параметр безпеки. 48 годин — абсолютний мінімум для протоколів з реальними коштами. Compound та Aave використовують 2-7 днів.

Життєвий цикл пропозиції

Створення пропозиції → votingDelay (щоб зафіксувати снапшот) → 
votingPeriod (FOR/AGAINST/ABSTAIN) → 
(якщо пройшла) черга в timelock → 
timelockDelay → 
виконання

Пропозиція містить масиви викликів: targets[], values[], calldatas[]. Одна пропозиція може виконати довільну кількість on-chain дій атомарно — змінити параметри протоколу, перевести казну, оновити контракти.

// Пропозиція: змінити комісію протоколу з 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%");

Управління казною

DAO зазвичай управляє казною — резервами протоколу. Стандартний паттерн: казна — це сам TimelockController (тримає ETH та токени) або окремий контракт як Gnosis Safe з Governor як єдиним власником.

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

Для малих DAO або на ранній стадії: Gnosis Safe з мультисигом плюс модуль Zodiac SafeSnap, який виконує голосування Snapshot.org on-chain. Це дешевше (безгазові off-chain голосування) й достатньо, доки не накопичиться достатньо активних емітентів токенів для on-chain управління.

Перехід від мультисигу до повного on-chain управління — це окремий мільйон. Типовий шлях: мультисиг (запуск) → мультисиг + Snapshot (зростання спільноти) → повний on-chain Governor (зрілий протокол).

Диверсифікація та стабільність

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

Делегування та Off-chain координація

Система делегатів

Більшість емітентів токенів не голосують прямо. Compound запровадив концепцію делегата: емітенти токенів делегують голосувальну силу відомим учасникам (дослідники, основні контрибьютори, спеціалісти DAO), які активно беруть участь у управлінні.

Профіль делегата — це пост Discourse/Mirror з позиціями щодо ключових питань. Реалізується через ERC20Votes.delegate(). Делегування не передає токени — лише голосувальну силу.

Off-chain управління (Snapshot)

Snapshot.org дозволяє безгазове голосування через підписи повідомлень. Використовується для сигнальних голосувань (перевірка температури) не пов'язаних з on-chain діями. Стратегії: erc20-balance-of, erc20-votes-with-overrides, delegation та десятки користувацьких стратегій.

Типовий двоступеневий процес:

1. Перевірка температури на Snapshot — оцінка настроїв, безгазове
2. On-chain пропозиція — якщо перевірка температури пройде з 60%+ підтримкою

Безпека управління

Атака Flash Loan на управління

Атака: flash loan → отримати тимчасовий контроль великої кількості токенів → делегувати собі → створити або просунути пропозицію → повернути кредит. Для створення пропозиції: proposalThreshold повинен бути достатньо високим. Для голосування: proposalSnapshot фіксується в минулому; flash loan не допомагає (немає історії делегування в поточному блоці).

ERC20Votes захищений від атак flash loan голосування саме через механізм чекпоїнтів. Уразливість існує тільки в proposalThreshold, якщо встановлено занадто низько.

Спам пропозицій і DOS

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

Захоплення управління

Якщо зловмисник накопичує >50% голосувальної сили (або >кворум при низькій явці), він може пройти будь-яку пропозицію. Захисти:

• Високий кворум (4-10% пропозиції)
• Timelock з достатньою затримкою (7 днів)
• Мультисиг Гранди з роллю CANCELLER у TimelockController
• GovernorPreventLateQuorum — розширює період голосування, якщо кворум набраний в останні моменти (запобігає останній-хвилинним качаннями китів)

Оновлення через DAO

Смарт-контракти оновлюються через пропозицію DAO плюс timelock. Паттерни оновлення:

UUPS/Transparent Proxy + власник DAO. Governor — власник проксі. Пропозиція викликає upgradeTo(newImplementation). Timelock дає спільноті час перевірити новий код перед активацією.

Модульна архітектура без проксі. Кожен модуль замінюється через управління: пропозиція змінює адресу модуля в реєстровому контракті. Менш ризиковано, ніж повне оновлення.

Стек і типовий графік

Базовий on-chain DAO: OpenZeppelin Governor + TimelockController + ERC20Votes. 2-3 тижні розробки, 2-3 тижні аудиту.

DAO з управління казною, UI делегування, інтеграцією Snapshot, мультисигом Гранди: 6-10 тижнів розробки.

Повна платформа DAO з користувацькими модулями, veToken управління, системою калібрування, ринком мотузок: 3-6 місяців.

Технічний стек: Solidity 0.8.x + Foundry + OpenZeppelin 5.x. Frontend: wagmi + viem + React. Індексація: The Graph subgraph для пропозицій і голосів (frontend не може показати історію без subgraph без ітерації подій).

Вартість розраховується після визначення моделі управління та обсягу.