DAO Bounty System Development

Integration with Moloch DAO framework

Moloch DAO is a minimalist framework for managing shared capital. It emerged in 2019 as a reaction to the complexity of early DAO systems and focused on one task: managing shared treasury with a rage-quit mechanism. Code simplicity is intentional. Moloch v1 contains about 400 lines of Solidity, and this is a matter of principle: less code means less attack surface.

Today Moloch v2 and its derivatives (DAOhaus, Metacartel, Raid Guild) are used by hundreds of DAOs. Moloch v3 (Baal) added modularity. Understanding the architecture helps integrate the protocol or create a custom DAO on this foundation.

Key mechanism: shares, loot, rage-quit

Shares vs Loot

Shares — a member's voting stakes. Give the right to vote on proposals and claim a proportional treasury share upon rage-quit.

Loot (Moloch v2) — non-voting economic stakes. Give the right to treasury share upon rage-quit, but not a vote. Useful for investors without management rights or for vesting schemes.

Difference: a member with 100 shares and 0 loot votes differently than a member with 50 shares and 50 loot, with equal economic stake.

Rage-quit — exit mechanism

This is the main architectural difference from Governor-based systems. If a proposal passes but a member disagrees — they can rage-quit before execution. Rage-quit burns the member's shares/loot and returns them a proportional share of whitelisted tokens from the guild bank.

Alice: 100 shares out of 1000 total = 10% treasury
Treasury: 10 ETH + 50,000 USDC
Alice rage-quits: gets 1 ETH + 5,000 USDC, her shares are destroyed

This creates fundamental safety for minority holders: even if the majority voted for something harmful, the minority can exit before execution with their proportional share.

Moloch v2 Architecture

Proposal lifecycle

submitProposal() → sponsorProposal() → voting (Yes/No) →
[grace period for rage-quit] → processProposal()

Grace period is the key link. After voting ends and before execution, there's a window (typically 3–7 days) during which dissenters can rage-quit.

// Simplified Moloch v2 proposal structure
struct Proposal {
    address applicant;     // who receives shares/loot
    uint256 sharesRequested;
    uint256 lootRequested;
    uint256 tributeOffered; // what applicant offers to guild bank
    address tributeToken;
    uint256 paymentRequested; // what they request from guild bank
    address paymentToken;
    uint256 startingPeriod;
    uint256 yesVotes;
    uint256 noVotes;
    bool[6] flags;         // sponsored, processed, didPass, cancelled, whitelist, kick
    bytes32 details;       // IPFS hash with description
}

Guild bank and token whitelist

Guild bank is just an address => uint256 mapping of tokens inside the contract. Not all tokens are accepted: only whitelisted. Upon rage-quit, a member gets a proportional share of each whitelisted token.

This is important for integration: you can't just transfer any token to the Moloch contract and expect it to enter rage-quit calculations. You need a submitWhitelistProposal — a proposal to add a token.

Integrating a custom project

Option 1: DAOhaus as a wrapper

DAOhaus is a product on top of Moloch v2, which adds UI, subgraphs, and the ability to create Moloch DAOs without writing code. If you need a treasury management DAO without custom rules — DAOhaus is ready to use.

DAOhaus limitations: standard proposal types (membership, funding, trade, whitelist). If you need custom logic — move to the next option.

Option 2: Moloch v3 (Baal) with modules

Baal is Moloch v3, built as a modular Safe (Gnosis Safe) with Moloch governance on top. Architecture:

Safe manages the treasury. Baal manages shares/loot and voting. Shamans are external contracts with rights to mint/burn shares/loot or manage DAO parameters.

// Shaman — external contract with rights
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;
}

// Example: automatic shaman for share streaming
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);
    }
}

The Shaman approach allows building complex mechanics on top of Moloch without modifying the core contract.

Option 3: Custom Moloch fork

If you need full customization (different voting types, different quorum rules, integration with external protocols) — a Moloch v2 fork with changes. This requires careful audit of the changes.

Typical integration use cases

Grant DAO. Uses grants treasury to fund projects. Applicant submits fundingProposal, DAO members vote. On passage — treasury transfer. Rage-quit protects members if grants go in the wrong direction. Real examples: MolochDAO grants, MetaCartel Ventures.

Investment club. Participants deposit ETH in exchange for shares. All investment decisions go through funding proposals. Rage-quit is the exit mechanism from the club with preserved share. Advantage over corporate structure: on-chain transparency + automatic execution.

Service DAO (Raid Guild model). Shares are earned for completed work (not for money). Loot — for financial contributions. Separation of governance rights (shares) from economic rights (loot) allows building merit-based organizations.

Technical nuances when integrating

Voting period in periods, not seconds. Moloch v2 counts time in abstract "periods" (periodDuration in seconds). This makes time calculations less intuitive on integration. In Baal this is fixed — timestamps are used directly.

Tribute token decimals. When creating a membership proposal, it's important to properly account for tribute token decimals. Decimal error is a common cause of miscalculated shares during join.

Guild bank vs Safe treasury. In Moloch v2, guild bank is built into the contract. In Baal it's a separate Safe, which provides more functionality (multisig, modules) but adds dependency on Gnosis Safe security.

Subgraphs. DAOhaus maintains ready-made subgraphs for Moloch v2 contracts. For Baal — official subgraph in HausDAO repository. Using ready subgraphs cuts frontend development time by 2–3x.

Stack and timelines

Moloch contracts: Solidity 0.8.x + Foundry. For Baal — using official HausDAO/Baal repository. Frontend: React + wagmi + The Graph client. For DAOhaus-based projects you can use DAOhaus SDK.

We recommend starting with Baal: good documentation, active HausDAO team, proven production track record.

Cost is calculated after clarifying DAO type, membership mechanics, and required custom shamans.