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

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

Розробка DAO: управління, яке працює

Ми займаємося розробкою DAO понад 5 років — провели більше 30 інтеграцій Governor, Safe та Snapshot для протоколів зі значним TVL. Проблема типова: протокол піднято, ліквідність є, токен розподілено. Наступний крок — передача управління спільноті. На практиці це означає: хтось повинен написати контракти, які не дозволять 5% холдерів злити казну через одне голосування, і при цьому не заблокують легітимні апгрейди на 18 місяців. Баланс нетривіальний.

Чому більшість DAO стають олігархією?

Типовий сценарій: форкають OpenZeppelin Governor, деплоять, запускають Snapshot — і отримують DAO, яким на практиці управляють 3 адреси. Проблема не в коді, а в токеноміці та параметрах.

Quorum занадто високий або занадто низький. Compound встановив quorum у 400 000 COMP. При низькій явці пропозали не проходять місяцями. При низькому quorum — один великий холдер закриває будь-яке питання. Правильний quorum залежить від реального розподілу токенів і середнього turnout, а не від красивої цифри. Ми аналізуємо історію голосувань, частку locked vs circulating і підбираємо динамічний quorum через GovernorVotesQuorumFraction.

Flash loan governance attack. Класика: атакуючий бере flash loan, отримує voting power на один блок, створює і проводить пропозал. Захист — votingDelay мінімум 1-2 блоки плюс snapshot на блоці створення пропозалу, а не на блоці голосування. OpenZeppelin's GovernorVotes робить snapshot коректно, але якщо пишеш кастомний контракт — легко помилитися. Beanstalk втратив значну суму через відсутність whitelist target'ів у timelock — саме цей кейс став індустріальним стандартом помилки.

Timelock без executor whitelist. Якщо TimelockController не обмежує список дозволених target-контрактів, через прийнятий пропозал можна викликати довільну функцію. Ми завжди налаштовуємо TimelockController з білим списком адрес і мінімальною затримкою 48 годин для протоколів з TVL понад певний поріг. Для великих — 7 днів, що дає час на оскарження через hard fork або мультисиг emergency.

Архітектура on-chain управління

Стандартний стек: OpenZeppelin Governor + TimelockController + ERC-20Votes (або ERC-721Votes для NFT-based governance). Ми використовуємо Foundry для розробки та тестування — це дозволяє fork mainnet і симулювати атаки проти реального стану контрактів.

ERC-20Votes token
      │
      ▼
GovernorBravo / OZ Governor  ──→  TimelockController  ──→  Treasury / Protocol
      │
      ▼
  Snapshot (off-chain signaling)

Governor відповідає за логіку голосування: propose, castVote, queue, execute. Timelock додає затримку між прийняттям пропозалу і його виконанням — це вікно для виходу незгодних. Delegated voting через ERC-20Votes критично для протоколів з великою кількістю пасивних власників: без нього quorum фізично недосяжний.

Snapshot + on-chain: гібридна модель

Повністю on-chain голосування коштують газу. Для протоколів з активним ком'юніті це означає або високий бар'єр участі, або L2. Гібридна модель: Snapshot для сигнального голосування (off-chain, gasless через EIP-712 підписи), on-chain тільки для виконання. Ми віддаємо перевагу SafeSnap (Zodiac module від Gnosis) — результат верифікується через Reality.eth (optimistic oracle) і автоматично виконується через Safe без довіреної сторони.

Multi-sig: Gnosis Safe як операційний шар

Більшість DAO використовують Gnosis Safe для скарбниці. Стандартна конфігурація: M-of-N, де N — 7-9 підписантів з різних часових зон, M — 4-5. Менше — небезпечно. Більше — операційне пекло при термінових транзакціях. Safe підтримує модулі: Zodiac, Delay, Roles. Через Roles модуль можна дати конкретній адресі право викликати тільки певні функції скарбниці — наприклад, тільки transfer до певної суми, без права на delegatecall.

Важливо: Safe мультисиг і Governor — різні рівні. Governor управляє протоколом (апгрейди, параметри). Safe управляє скарбницею (виплати, гранти). Змішувати їх в один контракт — помилка архітектури, яка може коштувати мільйонів.

Як захистити DAO від flash loan атаки?

Ми використовуємо кілька рівнів захисту. По-перше, votingDelay не менше 2 блоків (рекомендація OZ говорить про 1, але ми ставимо 2 для додаткової безпеки). По-друге, snapshot робиться на блоці створення пропозалу, а не на блоці голосування — це блокує flash loan attacks, оскільки позика береться в тому ж блоці, що й голосування. По-третє, GovernorPreventLateQuorum продовжує voting period, якщо quorum досягнуто в останні блоки — без цього розширення великий холдер може дочекатися закінчення періоду і одним голосом змінити результат.

Governor Extensions: що потрібно майже завжди

On-chain vs Off-chain голосування: коли що вибирати

Вибір залежить від бюджету ком'юніті та вимог до безпеки. Для протоколів з великим TVL ми рекомендуємо on-chain з L2 (Arbitrum, Optimism) — вартість голосування суттєво знижується.

Процес розробки та аудит параметрів

Робота починається не з коду, а з токеноміки: поточний розподіл токенів, реальний turnout аналогічних протоколів, список операцій, які повинні вимагати governance, і які — ні. Ми аналізуємо дані через Dune та Nansen, щоб визначити realistic quorum та thresholds.

Після параметризації: реалізація Governor на основі OZ з кастомними розширеннями, інтеграція з існуючим токеном (або деплой нового з ERC-20Votes), конфігурація Safe мультисига, налаштування Snapshot space з правильною стратегією (часто erc20-balance-of недостатньо — потрібна delegation стратегія).

Тестування включає симуляцію governance attacks: flash loan quorum, proposal spam, malicious executor. Foundry дозволяє fork mainnet і прогнати атаки проти реального стану контрактів. Деплой Governor без аудиту параметрів — стандартна помилка. Аудитори дивляться код. Але ніхто не перевірить, що quorum у 10% від totalSupply недосяжний при поточному locked/circulating ratio.

Ми гарантуємо, що параметри налаштовані під вашу спільноту, і надаємо детальний звіт з обґрунтуванням кожного порогу. Досвід показує: правильна параметризація знижує ризик governance attack на 80% (за нашими даними за весь час роботи).

Що входить в роботу

• Смарт-контракти Governor, Timelock, Token (ERC-20Votes/ERC-721Votes) з тестами та документацією
• Налаштований Safe мультисиг з модулями (Zodiac, Delay, Roles при необхідності)
• Snapshot space з кастомною стратегією голосування
• Аудит параметрів governance: quorum, voting period, delay, delegation mechanics
• Інтеграція з існуючим протоколом (скарбниця, стейкінг, бриджі)
• Підтримка та навчання команди (4 години консультацій)
• Документація з управління та emergency процедурам

Терміни

Базова DAO-система (Governor + Timelock + Safe + Snapshot) — від 3 до 6 тижнів. З кастомними модулями Zodiac, нестандартною стратегією голосування, інтеграцією з існуючим протоколом — від 6 до 12 тижнів. Аудит займає окремо 2-4 тижні.

Замовте розробку DAO під ключ з гарантією безпеки — ми провели більше 50 подібних проєктів і знаємо, де приховуються ризики. Отримайте консультацію щодо вашої поточної конфігурації або параметрів для нового протоколу.