Daodao proposals use different ballot rules to authorize DAO actions

A treasury decision starts with its attached actions

A proposal that would spend treasury funds must carry the transfer instructions that execution will apply. Its description explains the purpose; its actions specify the blockchain operation. Read the recipient and token details in those actions alongside the written request. Single-choice voting asks whether to approve the attached action set. Multiple-choice voting lets each proposed option carry its own actions. When the DAO chooses between competing transfers, each option should identify the instructions that support its description.

Proposal actions also support membership changes, governance-token minting, and configuration updates.

The proposal module connects the ballot to the core

The proposal module manages the ballot and its outcome, while the DAO core holds the treasury and executes authorized messages. A separate voting power module supplies the weights that the ballot counts. Standard interfaces connect these components, so changing a proposal format does not inherently change the participation model. The same membership-based or staked-token voting power can support different proposal modules.

View image file

Submission fixes the proposal's voting-power snapshot

Creating a proposal establishes its ballot and records the voting power that its approval and quorum rules will evaluate. That record includes the total voting power that quorum uses as its denominator. Later membership changes do not rebuild the electorate for an existing proposal. Someone who joins afterward cannot acquire a vote on that earlier ballot simply by becoming a member. This keeps participation tied to proposal creation, even when current membership totals differ from the weights that determine an older proposal's result.

Submission permission governs who may put a proposal to a vote. The configured policy can allow members only or anyone. An enabled deposit requirement adds a separate submission condition; it does not establish voting eligibility.

Single-choice approval separates quorum from the passing threshold

A single-choice ballot offers Yes, No, and Abstain, with a configured threshold determining whether the proposed action set passes. Quorum adds a participation requirement when enabled. Read these settings separately because reaching the participation requirement does not establish approval.

Quorum measures participating voting power against the proposal's total voting power. The calculation uses weights, so counting participating wallet addresses can give the wrong denominator. Low participation can prevent passage even when Yes leads the recorded votes. When quorum is enabled, the final percentage approval test uses the Yes and No voting power. Abstain contributes to participation but does not enter that approval denominator.

Disabling quorum changes the percentage approval basis. The single-choice contract then uses the proposal's total voting power, excluding recorded Abstain power. Uncast voting power remains in that basis. A percentage among votes cast therefore does not describe this absolute-percentage test.

Majority requires more than half of the relevant voting power; a configured percentage instead passes when support reaches that percentage. Selecting a 50% threshold and selecting majority express different rules.

Before expiration, the module also accounts for votes that could still arrive when determining whether the outcome is irreversible. A current majority among recorded votes does not necessarily establish early passage. At expiration, the quorum-enabled percentage test evaluates the completed Yes and No tally.

Multiple-choice voting compares the actions behind each option

Each proposed multiple-choice option can contain its own action set, and the ballot tallies weighted support for those alternatives, while passage requires quorum. Multiple-choice ballots have no separate Yes passing threshold. A successful option wins through plurality, meaning that it receives more voting power than the competing options. It does not need the single-choice ballot's configured Yes percentage. Compare the instructions attached to each option, since execution applies the selected set rather than combining the alternatives.

The ballot also includes None of the above, which lets voters reject the proposed alternatives. At expiration, the version 2.6.0 multiple-choice contract rejects a proposal if None of the above wins or the highest-weight options tie. Quorum remains required for this ballot format, so a leading action option alone cannot establish a successful proposal.

Voting duration controls when the outcome can settle

The maximum voting duration sets the deadline for additional votes, while revoting determines whether a voter may replace an earlier choice. With revoting enabled, the voting rules defer passage or rejection until the voting period ends. A temporary lead cannot settle an outcome that voters can still reverse. When revoting is disabled, early passage or rejection may become possible once eligible remaining votes cannot change the result.

Single-choice contracts and the version 2.6.0 multiple-choice contract both allow a minimum voting period before passage. Even a decisive tally must wait until that period expires. This requirement and the maximum deadline govern different boundaries of the voting window.

Veto configuration can interrupt the move to execution

An optional veto configuration can place an approved proposal in a timelock before ordinary execution becomes available. The designated vetoer may veto eligible proposals during that period. The configured duration can use blocks or seconds and extends from the proposal's expiration. If early execution is enabled for the vetoer, that address can execute during the timelock. A separate setting can permit vetoing before passage. These controls qualify the execution path for modules that include them.

Execution applies the instructions that the ballot approved

A passed proposal authorizes its approved actions; execution sends those messages through the DAO core once the proposal's configuration permits that transition. Approval and execution are distinct states. A treasury proposal can pass while its transfer remains unapplied. Single-choice execution uses the proposal's attached action set. Multiple-choice execution uses the successful option's actions. To interpret completion, distinguish the decided vote from the execution result and the resulting treasury or configuration change.

The member-only execution setting determines who may execute passed proposals. For ordinary single-choice execution, enabling it requires the executor to have voting power at the proposal's creation height; disabling it allows anyone. That permission changes the eligible executor, not the actions that the vote approved.

Configuration changes preserve the distinction between ballot formats

Changing voting rules requires a governance proposal containing the relevant configuration action. When multiple-choice proposals are enabled, Update Single Choice Voting Config and Update Multiple Choice Voting Config target the formats separately. They can therefore use different voting durations or revoting settings. Single-choice approval also retains its threshold settings, while multiple-choice voting retains its quorum-based selection rule. Choose the action for the intended proposal type before publishing the configuration change. Submission settings have their own configuration actions and address a different permission.

Single-choice voting fits approval of one proposed action set; multiple-choice voting fits selection among competing sets. Ranked-choice voting appears in a separate Condorcet module. Its documented first version lacks human-readable proposal and option names and descriptions. It also lacks revoting, pre-propose integration, and proposal or vote hooks. A multiple-choice ballot in the standard interface consequently describes a different workflow from that ranked-choice contract.