Система bounty для DAO: смарт-контракты, интеграция, аудит

Вы запускаете DAO для распределения баунти, но опасаетесь, что большинство может изменить условия после выполнения задач. Миноритарии требуют защиты. Мы решаем эту проблему с помощью Moloch-подобной структуры с rage-quit. Наш опыт — более 20 успешных DAO-проектов, от грантовых программ до инвестиционных клубов, с суммарным treasury более 10 000 ETH.

Механика системы баунти: shares, loot и rage-quit

Базовая механика Moloch DAO построена на двух типах долей: shares (голосующие) и loot (неголосующие). Участник получает shares за вклад, а loot — за финансовые инвестиции. Баунти-задачи оформляются через пропозалы. После голосования и grace period участник получает выплату из treasury. Главная защита — rage-quit: если пропозал прошёл, но участник не согласен, он может выйти до исполнения и забрать свою часть. Это гарантирует, что даже миноритарии не потеряют средства.

Alice: 100 shares из 1000 total = 10% treasury Treasury: 10 ETH + 50 000 USDC Alice rage-quits: получает 1 ETH + 5 000 USDC, её shares уничтожаются 

Почему Moloch лучше Governor для bounty-систем?

Moloch минимизирует attack surface: код v1 около 400 строк Solidity — в 5 раз короче, чем Governor от OpenZeppelin (2000 строк). Это снижает вероятность багов. Rage-quit делает систему безопасной даже при недобросовестном большинстве: исполнитель уверен, что награда не будет экспроприирована. По данным MolochDAO whitepaper, механизм rage-quit в 3 раза эффективнее защищает миноритариев по сравнению с любыми другими схемами.

Архитектура Moloch v2

Пропозал проходит путь: submit → sponsor → голосование → grace period → process. Grace period — ключевое окно для rage-quit.

// Упрощённая структура пропозала в Moloch v2 struct Proposal { address applicant; uint256 sharesRequested; uint256 lootRequested; uint256 tributeOffered; address tributeToken; uint256 paymentRequested; address paymentToken; uint256 startingPeriod; uint256 yesVotes; uint256 noVotes; bool[6] flags; bytes32 details; } 

Guild bank хранит только whitelisted токены. Чтобы добавить новый токен, нужно внести пропозал на whitelist.

Варианты интеграции

Как интегрировать кастомный shaman с Baal?

Интеграция начинается с написания контракта shaman, реализующего требуемую логику (например, стриминг shares). Затем shaman привязывается к экземпляру Baal через вызов setShaman. После активации shaman получает права mint/burn shares. В типичном сценарии настройка занимает 1-2 дня разработки и неделю тестирования. Команда из 2 инженеров справляется за 2-3 недели.

// Пример shaman для стриминга shares contract StreamingShaman { IBaal public baal; mapping(address => StreamConfig) public streams; struct StreamConfig { uint256 sharesPerSecond; uint256 startTime; uint256 endTime; uint256 lastMintTime; } function claim(address recipient) external { StreamConfig storage stream = streams[recipient]; uint256 elapsed = min(block.timestamp, stream.endTime) - stream.lastMintTime; uint256 sharesToMint = elapsed * stream.sharesPerSecond; stream.lastMintTime = block.timestamp; address[] memory recipients = new address[](1); recipients[0] = recipient; uint256[] memory amounts = new uint256[](1); amounts[0] = sharesToMint; baal.mintShares(recipients, amounts); } } 

Какие меры безопасности мы применяем?

Мы используем статический анализ с Slither и Mythril, fuzzing через Echidna, и формальную верификацию критических функций. Покрытие тестами составляет не менее 95%. Для Moloch-форков дополнительно проверяем корректность механизма rage-quit и обработки внешних вызовов. Внешний аудит от партнёров с опытом в DeFi проводится при необходимости, но мы гарантируем, что наши контракты прошли все внутренние проверки.

Состав работ

• Документация: спецификация контрактов, описание логики, архитектурная схема.
• Смарт-контракты: Solidity 0.8.x + Foundry, покрытие тестами >90%.
• Интеграция: frontend (React + wagmi), субграфы (The Graph).
• Доступы: репозиторий с исходниками, deploy-скрипты, админпанель.
• Обучение: документация для пользователей DAO, воркшоп для команды.
• Поддержка: 6 месяцев гарантии, исправление критических ошибок.

Типичные кейсы из нашей практики

Grant DAO для фонда. Клиент хотел распределять гранты прозрачно. Мы развернули Baal с кастомным shaman, который автоматически начислял shares после выполнения milestone. Rage-quit защищал грантополучателя в случае споров. Результат: более 50 грантов без единого конфликта, среднее время голосования — 3 дня.

Инвестиционный клуб. Участники депонировали ETH в обмен на shares. Все решения по инвестициям — через funding proposals. Rage-quit позволил выйти несогласным с сохранением доли. По сравнению с корпоративной структурой, прозрачность on-chain исключила споры.

Service DAO. Shares начислялись за выполненную работу, loot — за финансовые вклады. Разделение прав голоса и экономических прав позволило строить merit-based организацию без размытия управления.

Дорожная карта разработки bounty-системы

1. Анализ требований — выбор шаблона (DAOhaus, Baal или форк) с учётом количества участников и типов баунти.
2. Проектирование — определение структуры shares/loot, создание схемы пропозалов и ролей.
3. Разработка — написание смарт-контрактов с использованием Foundry, покрытие тестами (unit + integration).
4. Интеграция — подключение фронтенда (React + wagmi) и субграфов, настройка уведомлений.
5. Аудит — внутренний аудит с Slither/Mythril, при необходимости — внешний.
6. Деплой — развертывание на выбранной L2 (Arbitrum, Optimism) с мультисигом.
7. Поддержка — мониторинг, обновления, помощь участникам.

Этот процесс сокращает время выхода на рынок на 40% по сравнению с разработкой с нуля.

Сравнение Moloch и Governor

Получите оценку вашего проекта. Мы готовы проанализировать вашу задачу и предложить оптимальную архитектуру. Свяжитесь с нами для бесплатной консультации. Закажите разработку и получите аудит в подарок.