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

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1306 услуг
Разработка системы bounty для DAO
Средний
~3-5 дней
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1306
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1218
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    920
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1147
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    610
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    885

Интеграция с 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 — механизм выхода

Это главное архитектурное отличие Moloch от 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 уничтожаются

Это создаёт принципиальную safety для 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 форк

Если нужна полная кастомизация (другие типы голосований, разные kворум правила, интеграция с внешними протоколами) — форк 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 это исправлено — используются timestamp-ы напрямую.

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 раза.

Стек и сроки

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

Вариант Срок Кастомизация
DAOhaus (no-code) 1–2 дня Минимальная
Baal + кастомный shaman 2–4 недели Высокая
Moloch v2 форк 4–6 недель + аудит Полная

Рекомендуем начинать с Baal: хорошая документация, активная команда HausDAO, доказанный продакшн track record.

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