Система баунті для 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

Отримайте оцінку вашого проєкту. Ми готові проаналізувати ваше завдання та запропонувати оптимальну архітектуру. Зв'яжіться з нами для безкоштовної консультації. Замовте розробку та отримайте аудит у подарунок.