Разработка 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. Одобренное предложение не исполняется немедленно: оно помещается в очередь и исполняется после задержки (обычно 2-7 дней). Это окно для сообщества заметить потенциально опасное предложение и выйти из протокола до его исполнения.

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 месяцев. Стоимость рассчитывается индивидуально после анализа требований. Свяжитесь с нами для предварительной оценки.