Daohaus proposals for basic requests and advanced actions

Which proposal form matches the intended action?

A basic form suits a request that fits its defined action, while advanced options cover custom interactions and configuration changes. The New Proposal menu separates these choices into Basics and Advanced.

The distinction between requesting DAO tokens and requesting treasury assets changes the proposed action. Shares and loot represent membership rights; a treasury payment spends an asset that the DAO holds. The swap form concerns an exchange for DAO tokens under the proposal's terms. A Signal Request records sentiment without specifying a treasury payment.

Readiness before a treasury request

A treasury proposal needs the correct DAO, network, asset, and recipient before submission. These inputs determine which balance the proposed transaction can spend and which account should receive it.

DAO, network, and Safe

The connected wallet must use the network that hosts the selected DAO. Settings lists its governance, treasury, voting token, and non-voting token contracts. The Safes view identifies the asset-holding account and its balances. An existing Safe attached to governance remains a distinct contract from Baal, the Moloch v3 governance layer. The selected transfer must concern assets held by the intended Safe on that network.

Timing before wallet confirmation

The DAO's voting period, grace period, sponsor threshold, and proposal offering affect submission readiness. A time-sensitive payment needs room for those periods and any wait for sponsorship or processing. Before confirming submission, an unresolved recipient, asset, or contract call is a reason to stop and correct the proposal. For a first ERC-20 payment from the main treasury, choose ERC-20 Token Transfer in New Proposal. Enter the title, description, recipient, token, and amount, then review the form. Opening a form or reviewing its details does not submit an on-chain request.

The proposal record confirms submission

A confirmed submission creates a numbered proposal record, establishing that the contract recorded the request. The Admin App displays its submission date, title, description, submitter, and current status. Unsponsored means voting has not started; an automatically sponsored submission can enter In Voting immediately. It does not establish approval or completion of a treasury payment.

Sponsorship starts the voting window

Sponsorship admits a submitted proposal into voting under the DAO's configured threshold. Moloch v3 expresses the sponsor threshold as an amount of voting power in shares. The threshold does not describe the percentage of members who must approve a request.

A submitter whose voting power meets that threshold can automatically sponsor the proposal during submission. In that case, the submission also starts the voting clock. Sponsorship does not always require a separate transaction after the initial request.

A submitter below the threshold must supply the exact configured proposal offering in the network's native coin. That offering is non-refundable and separate from the network transaction fee. The proposal then needs sponsorship from an account that satisfies the threshold before voting can begin.

An unsponsored request can therefore wait even when its submission transaction has confirmed. A payment deadline must allow for this dependency. The voting period begins at sponsorship, so submission time alone cannot establish the voting end time.

Voting thresholds use token weight

Approval combines the recorded yes and no voting weight with any additional governance requirements. A count of participating wallets cannot establish whether a proposal meets those requirements.

Shares and voting power

Shares carry voting rights, while loot carries financial rights without votes. Delegation determines which account exercises delegated voting power. The Members view shows voting power and delegation, which helps explain why token holders can have different influence over the same proposal.

Quorum and retention

Quorum sets a minimum yes-vote percentage of voting shares. In the Zodiac-based Baal implementation, this calculation uses share supply recorded at sponsorship. A successful vote also needs more yes weight than no weight. Minimum retention compares current combined shares and loot supply with the proposal's recorded combined-supply baseline. Falling below the configured retention requirement prevents execution despite a favorable vote. These requirements measure token units, so wallet counts cannot substitute for either calculation.

Grace time and expiration constrain execution

The grace period separates voting from readiness for execution, giving members time to use ragequit before proposed actions take effect. Ragequit exchanges burned membership tokens for a proportional claim on eligible main-treasury assets. This exit mechanism explains why the available treasury balance can change while a proposed action waits.

An optional proposal expiration adds a deadline. When an expiration is set, Baal requires enough remaining time for voting and grace at submission and again at sponsorship. Waiting for a sponsor can consume that margin. An unset expiration does not remove voting, grace, ordering, or execution requirements. A time-sensitive request therefore needs a feasible governance schedule as well as the correct payment action.

Processing order connects concurrent proposals

Baal links a sponsored proposal to its previously sponsored predecessor, creating an ordering constraint even when several proposals occupy different stages. Processing requires an existing sponsored predecessor to be processed, cancelled, or defeated. The first sponsored proposal has no earlier proposal to clear.

Submission order and sponsorship order can differ because a request may remain unsponsored. The relevant dependency follows sponsorship. A Ready to Execute label describes the proposal's own stage; an unresolved predecessor can still prevent its processing. Changing the payment form does not remove this ordering rule.

Contract calls need review beyond the description

Advanced calls suit actions that basic forms do not express. Use WalletConnect supports external contract interactions, and the Multicall Proposal Builder supports a custom set of contract actions within a proposal.

The builder accepts a contract address and its application binary interface, or ABI. The ABI describes available functions and their inputs. Selecting a function creates an action that voters can authorize. The contract address, function arguments, and any payment value must match the intended operation on the DAO's network. A familiar function name does not establish the recipient or amount.

The description explains the request in ordinary language; Transaction Call Data describes the interactions that execution will attempt. Review needs both. A proposal requesting a payment should express the same asset, recipient, and amount in its explanation and encoded action. Any additional contract call also belongs within the scope that voters understand.

A multicall bundles actions into a shared decision, so voters approve or reject the proposed bundle together. Keeping unrelated decisions in separate proposals allows separate votes. Within a batch, calls that depend on earlier actions need the appropriate execution order. A successful governance vote cannot make invalid contract arguments work.

Passed and Action Failed describe different outcomes

Baal records approval separately from the success of the proposed contract action. A proposal can pass its governance checks and still produce an action failure. The Admin App includes Action Failed among its proposal statuses, alongside Passed, Defeated, and Expired.

A confirmed processing transaction therefore needs interpretation beyond its transaction status. For a treasury payment, the relevant outcome includes the intended asset movement from the selected Safe to the named recipient. A defeated vote, unmet retention requirement, and failed external call describe different causes. Resolving a scheduling dependency cannot correct a wrong recipient or an invalid function argument in the submitted action.

Treasury selection changes the rights at stake

The Safes view supports proposals against the main treasury and attached sidecars, including native coin transfers, ERC-20 transfers, and multicall transactions. Their exit rights differ. Sidecar Safes do not give members ragequit rights over their assets. Members' exit claims concern the designated ragequittable main treasury.

Moving an asset between these accounts can therefore change its availability through ragequit. The payment's description should identify the affected Safe clearly when that distinction matters. A combined view of DAO assets does not mean every displayed balance belongs to the same account or carries the same exit rights.

Advanced forms can change the DAO itself

Advanced proposals also change governance settings, token transferability, membership, and delegated contract permissions. These choices can affect future decisions well beyond the immediate treasury request.

Governance and token settings

Update Governance Settings covers proposal timing and governance parameters, including quorum, sponsorship, offering, and retention. Update Token Settings changes whether voting or non-voting tokens can transfer. These actions address different controls: transferability governs token movement, while a DAO Token Request concerns allocating tokens. An authorized admin Shaman can also control token transferability within its granted permissions. Proposal voting and Shaman authority therefore provide distinct paths for configuration changes.

Membership and Shaman permissions

Remove Member converts a member's voting tokens into non-voting tokens. Add Shaman grants permissions to an external contract, which can then act within those permissions outside the ordinary proposal process. Manager permissions include minting and burning membership tokens; governor permissions include changing governance configuration. A proposal granting these powers authorizes ongoing capabilities, so its scope extends beyond a single payment.

Open full-size image