Розробка системи bounty для DAO

Інтеграція з Moloch DAO фреймворком

Moloch DAO — мінімалістичний фреймворк для управління спільним капіталом. Він з'явився в 2019 році як реакція на складність ранніх DAO систем і сфокусувався на одній задачі: управління treasury з механізмом rage-quit. Простота кода — навмисна. Moloch v1 налічує близько 400 рядків Solidity, і це принципіальна позиція: менше коду — менше attack surface.

Сьогодні Moloch v2 та його похідні (DAOhaus, Metacartel, Raid Guild) використовуються сотнями DAO. Moloch v3 (Baal) додав модульність. Розуміння архітектури допомагає інтегрувати протокол або створити кастомну DAO на цій основі.

Ключова механіка: shares, loot, rage-quit

Shares vs Loot

Shares — голосуючі доли учасника. Дають право голосувати за пропозалами та право на пропорціональну долю treasury при rage-quit.

Loot (Moloch v2) — неголосуючі економічні доли. Дають право на treasury долю при rage-quit, але не голос. Корисно для інвесторів без управління або для vesting схем.

Різниця: учасник з 100 shares та 0 loot голосує інакше, ніж учасник з 50 shares та 50 loot, при однаковій економічній долі.

Rage-quit — механізм виходу

Це головне архітектурне відмінність від Governor-based систем. Якщо пропозал пройшов, але учасник з ним не згоден — він може rage-quit до виконання. Rage-quit спалює shares/loot учасника та повертає йому пропорціональну долю whitelisted токенів з guild bank.

Alice: 100 shares з 1000 total = 10% treasury
Treasury: 10 ETH + 50,000 USDC
Alice rage-quits: отримує 1 ETH + 5,000 USDC, її shares знищуються

Це створює принципіальну безпеку для minority holders: навіть якщо більшість проголосувала за щось шкідливе, меньшість може вийти до виконання з сохранением пропорціональної долі.

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

Proposal lifecycle

submitProposal() → sponsorProposal() → голосування (Yes/No) →
[grace period для rage-quit] → processProposal()

Grace period — ключове звено. Після закінчення голосування та перед виконанням є вікно (зазвичай 3–7 днів), в течение якого несогласні можуть rage-quit.

// Спрощена структура пропозала в Moloch v2
struct Proposal {
    address applicant;     // хто отримує shares/loot
    uint256 sharesRequested;
    uint256 lootRequested;
    uint256 tributeOffered; // що пропонує applicant у guild bank
    address tributeToken;
    uint256 paymentRequested; // що просить з guild bank
    address paymentToken;
    uint256 startingPeriod;
    uint256 yesVotes;
    uint256 noVotes;
    bool[6] flags;         // sponsored, processed, didPass, cancelled, whitelist, kick
    bytes32 details;       // IPFS hash з описанням
}

Guild bank та whitelist токенів

Guild bank — це просто address => uint256 маппинг токенів всередині контракту. Не всі токени приймаються: тільки whitelisted. При rage-quit учасник отримує пропорціональну долю кожного whitelisted токену.

Це важливо для інтеграції: не можна просто transfer будь-який токен в Moloch контракт та очікувати що він вийде в розрахунок rage-quit. Потрібен submitWhitelistProposal — пропозал на додавання токену.

Інтеграція кастомного проекту

Варіант 1: DAOhaus як оболонка

DAOhaus — це продукт поверх Moloch v2, який додає UI, субграфи та можливість створювати Moloch DAO без написання коду. Якщо потрібна treasury management DAO без кастомних правил — DAOhaus готовий до використання.

Обмеження DAOhaus: стандартні типи пропозалів (membership, funding, trade, whitelist). Якщо потрібна кастомна логіка — переходимо до наступного варіанту.

Варіант 2: Moloch v3 (Baal) з модулями

Baal — це Moloch v3, побудований як modular Safe (Gnosis Safe) з Moloch governance поверх. Архітектура:

Safe управляє treasury. Baal управляє shares/loot та голосуванням. Shamans — це зовнішні контракти з правами mint/burn shares/loot або управління параметрами DAO.

// Shaman — зовнішній контракт з правами
interface IBaal {
    function mintShares(address[] calldata to, uint256[] calldata amount) external;
    function burnShares(address[] calldata from, uint256[] calldata amount) external;
    function mintLoot(address[] calldata to, uint256[] calldata amount) external;
}

// Приклад: автоматичний 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);
    }
}

Shaman підхід дозволяє будувати складні механіки поверх Moloch без зміни core контракту.

Варіант 3: Custom Moloch форк

Якщо потрібна повна кастомізація (інші типи голосування, різні quorum правила, інтеграція з зовнішніми протоколами) — форк Moloch v2 з змінами. Це вимагає ретельного аудиту змін.

Типові кейси інтеграції

Grant DAO. Використовується grants treasury для фінансування проектів. Applicant подає fundingProposal, члени DAO голосують. При passage — treasury transfer. Rage-quit захищає членів якщо grants йдуть у неправильну сторону. Реальні приклади: MolochDAO grants, MetaCartel Ventures.

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

Service DAO (Raid Guild модель). Shares отримуються за виконану роботу (не за гроші). Loot — за фінансові вклади. Розділення governance rights (shares) від економічних прав (loot) дозволяє будувати merit-based організації.

Технічні нюанси при інтеграції

Період голосування в periods, не в секундах. Moloch v2 рахує час в абстрактних «періодах» (periodDuration в секундах). Це робить часові розрахунки менш інтуїтивними при інтеграції. У Baal це виправлено — використовуються timestamps безпосередньо.

Tribute token decimals. При створенні membership proposal важливо правильно облікувати decimals tribute токену. Помилка в decimals — часта причина неправильного розрахунку shares при join.

Guild bank vs Safe treasury. У Moloch v2 guild bank вбудований в контракт. У Baal — окремий Safe, який надає більше можливостей (multisig, modules) але додає залежність від Gnosis Safe безпеки.

Субграфи. DAOhaus підтримує готові subgraphs для Moloch v2 контрактів. Для Baal — офіційний subgraph у репозиторії HausDAO. Використання готових субграфів скорочує час розробки frontend в 2–3 рази.

Стек і сроки

Moloch контракти: Solidity 0.8.x + Foundry. Для Baal — використання офіційного репозиторія HausDAO/Baal. Frontend: React + wagmi + The Graph клієнт. Для DAOhaus-based проектів можна використовувати DAOhaus SDK.

Рекомендуємо почати з Baal: добра документація, активна команда HausDAO, доказана production track record.

Вартість розраховується після уточнення типу DAO, механік членства та необхідних кастомних shamans.