DAO на папері виглядає просто: токени = голоси, більшість вирішує. На практиці це одна з найскладніших областей смарт-контрактів — не тому що код особливо важкий, а тому що ціна помилки в governance механіці катастрофічно висока. Proposal пройшов з помилкою в логіці кворуму — і зловмисник злив treasury. Так сталося з Beanstalk, коли flash loan governance атака вивела $182M.Beanstalk incident Розробка контрактів DAO — проектування економічно-безпечної системи прийняття рішень. Ми виконуємо роботу під ключ: від дизайну економічної моделі до аудиту та запуску. Наш досвід — понад 10 років у блокчейн-розробці, понад 50 успішних проєктів, включаючи інтеграцію з OpenZeppelin Governor та SafeSnap. Гарантуємо аудит контрактів провідними фірмами.
Decentralized autonomous organization
Як влаштована архітектура DAO?
Governor + Timelock
Стандарт де-факто — OpenZeppelin Governor з TimelockController. Governor керує lifecycle proposal (створення, голосування, постановка в чергу), Timelock додає затримку між прийняттям proposal та його виконанням.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/governance/Governor.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorSettings.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorCountingSimple.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorVotes.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorVotesQuorumFraction.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorTimelockControl.sol";
contract DAOGovernor is
Governor,
GovernorSettings,
GovernorCountingSimple,
GovernorVotes,
GovernorVotesQuorumFraction,
GovernorTimelockControl
{
constructor(
IVotes _token,
TimelockController _timelock
)
Governor("DAO Governor")
GovernorSettings(
1, // votingDelay: 1 блок (~12 сек на Ethereum)
50400, // votingPeriod: ~7 днів в блоках
100_000e18 // proposalThreshold: мінімум 100K токенів для proposal
)
GovernorVotes(_token)
GovernorVotesQuorumFraction(10) // 10% від total supply = кворум
GovernorTimelockControl(_timelock)
{}
function quorum(uint256 blockNumber)
public view override(Governor, GovernorVotesQuorumFraction)
returns (uint256)
{
return super.quorum(blockNumber);
}
function state(uint256 proposalId)
public view override(Governor, GovernorTimelockControl)
returns (ProposalState)
{
return super.state(proposalId);
}
function _execute(uint256 proposalId, address[] memory targets,
uint256[] memory values, bytes[] memory calldatas, bytes32 descriptionHash)
internal override(Governor, GovernorTimelockControl)
{
super._execute(proposalId, targets, values, calldatas, descriptionHash);
}
function _cancel(address[] memory targets, uint256[] memory values,
bytes[] memory calldatas, bytes32 descriptionHash)
internal override(Governor, GovernorTimelockControl)
returns (uint256)
{
return super._cancel(targets, calldatas, descriptionHash);
}
function _executor()
internal view override(Governor, GovernorTimelockControl)
returns (address)
{
return super._executor();
}
}
TimelockController налаштування
Timelock — критично важливий компонент. Він дає спільноті час зреагувати на прийнятий proposal до його виконання. Мінімальна затримка для treasury операцій — 48 годин, для оновлення контрактів — 72 години.
// Деплой TimelockController
// minDelay: 172800 (48 годин в секундах)
// proposers: [address(governor)]
// executors: [address(0)] — будь-хто може виконати після затримки
// admin: address(0) — немає суперадміна, тільки через Timelock
TimelockController timelock = new TimelockController(
172800,
proposers, // тільки Governor може ставити в чергу
executors, // address(0) = будь-хто може виконати
address(0) // admin revoked
);
executors: [address(0)] означає що виконати операцію після затримки може будь-хто — це правильно. Інакше створюється centralization point, де конкретний адрес має натиснути «execute».
Proposal lifecycle
Pending → Active → Succeeded/Defeated → Queued → Executed
↓
Canceled
Pending: proposal створено, чекає votingDelay блоків. Snapshot голосів береться в останньому блоці перед переходом в Active. Active: відкрито голосування на votingPeriod блоків. Голосування: For, Against, Abstain. Succeeded: кворум досягнуто, For > Against. Queued: в черзі Timelock, чекає minDelay. В цей період Guardian (якщо є) може скасувати. Executed: виконано on-chain.
Як захиститися від flash loan атак?
Beanstalk-сценарій: зловмисник бере flash loan на величезну суму, отримує тимчасовий governance контроль (delegateVote для governance ваги), створює і негайно проводить malicious proposal, повертає loan. Все в одній транзакції.
Ключовий захист — snapshot timing. GovernorVotes використовує getPastVotes(account, proposalSnapshot) — вага голосу визначається на блоці snapshot, а не на блоці голосування. votingDelay = 1 (один блок) вже ламає flash loan атаку: не можна зайняти токени і використати їх в тому ж блоці для snapshot. Додаткові заходи: Timelock затримка (48-72 години), proposal threshold (мінімальний баланс для створення proposal) та кворум, прив'язаний до total supply.
Які voting моделі вибрати?
Три основні моделі: token-weighted, quadratic та optimistic. Token-weighted голосування просте і передбачуване, але великі холдери домінують. Quadratic voting справедливіше — вартість N голосів дорівнює N², але потребує Sybil resistance. Optimistic governance виконує proposal автоматично, якщо не було veto — знижує voter apathy.
Token-weighted голосування на L2 (Arbitrum, Optimism) коштує в 10 разів дешевше, ніж на L1, а квадратичне — тільки в 2 рази дорожче звичайного.
| Параметр | Token-weighted | Quadratic | Optimistic |
|---|---|---|---|
| Швидкість прийняття рішень | Висока | Середня | Миттєва |
| Стійкість до whale-домінування | Низька | Висока | Середня |
| Складність реалізації | Низька | Висока (потрібна Sybil) | Середня |
| Gas cost на L1 | $5-20 | $10-40 | $2-5 (off-chain) |
| Параметр | Рекомендоване значення | Примітка |
|---|---|---|
| votingDelay | 1 блок | Захист від flash loan |
| votingPeriod | 50400 блоків (~7 днів) | Достатньо для глобальної спільноти |
| proposalThreshold | 100 000 токенів | Знижує спам |
| quorum | 10% від total supply | Баланс між безпекою та прохідністю |
Як працює multi-sig як Guardian?
Повністю on-chain governance вразливе на ранніх стадіях: мало токенів в обігу, низька явка, легко маніпулювати. Стандартна практика — Guardian мультисиг (Gnosis Safe 3/5 або 4/7), який може скасувати queued proposals, але не може їх ініціювати або виконувати.
// В TimelockController: CANCELLER_ROLE для Guardian Safe
timelock.grantRole(timelock.CANCELLER_ROLE(), guardianSafe);
Guardian не повинен мати PROPOSER_ROLE або EXECUTOR_ROLE — тільки CANCELLER. Це створює asymmetric protection: Guardian захищає від атак, але не контролює governance. Зі зростанням спільноти Guardian поступово виводиться.
Sub-DAO та спеціалізовані комітети
Монолітний Governor для всіх рішень — антипатерн. Типова багаторівнева структура: Core DAO Governor (великі рішення, 7-14 днів голосування), Treasury Committee (швидкі операції < $100K), Technical Committee (аудит, emergency pause), Grants Committee (бюджет $5-20K, off-chain голосування через Snapshot).
Gasless voting через EIP-712
Основна проблема on-chain голосування — gas cost. На Ethereum mainnet один голос коштує $5-20. Більшість DAO вирішує це через off-chain voting (Snapshot) з on-chain execution. Hybrid підхід: голосування в Snapshot (безкоштовно, підпис EIP-712), результат реалізується через SafeSnap. Для on-chain голосування на L2 (Arbitrum, Optimism, Base) gas вже прийнятний — $0.05-0.50 за транзакцію.
Що входить в роботу
- Дизайн governance моделі: параметри, комітети, Guardian схема.
- Розробка смарт-контрактів: Governor, Timelock, токен, тести атака-сценаріїв.
- Внутрішній security review та формальна верифікація найбільш критичних модулів.
- Зовнішній аудит (опціонально — з нашою рекомендацією топових фірм).
- Інтеграція з Snapshot, Tally.xyz, SafeSnap.
- Документація: технічна специфікація, deploy runbook, опис emergency процедур.
- Навчання команди: як створювати proposal, інтерпретувати результати, реагувати на інциденти.
- Пост-лаунч підтримка: моніторинг, оновлення при зміні стандартів (EIP).
Процес роботи
- Дизайн governance (1-2 тижні). Визначення voting model, параметрів, структури комітетів, Guardian схеми.
- Розробка контрактів (2-3 тижні). Governor + Timelock + Governance token + тести атака-сценаріїв.
- Безпека (1-2 тижні). Внутрішній review всіх сценаріїв, flash loan тести.
- Аудит (2-3 тижні). Зовнішній аудит обов'язковий.
- Frontend та інтеграція (2-3 тижні). Tally.xyz, Snapshot, SafeSnap.
- Поступовий launch. Початок з Guardian мультисигом, зниження централізації по roadmap.
Повний цикл: 3-4 місяці. Вартість розраховується індивідуально залежно від складності governance моделі та наявності існуючого токена. Економія на gas оптимізації може досягати 30%, а зниження вартості аудиту — 20% за рахунок нашої підготовки.
Готові розпочати? Зв'яжіться з нами для детального обговорення вашої DAO.
Докладніше про пост-лаунч підтримку
Ми забезпечуємо моніторинг та оновлення контрактів при зміні стандартів.Отримайте консультацію: зв'яжіться з нами для обговорення вашого проєкту — ми оцінимо його безкоштовно та запропонуємо оптимальне рішення. Замовте розробку контрактів DAO з гарантією аудиту та нашим досвідом 10+ років.