How to Write a DAO Proposal That Passes

23 September 2026

The short answer: a DAO proposal passes when it solves a real problem for the community, is technically sound, and has been socialized enough that voters understand and trust it. No amount of formatting tricks or rhetorical polish will save a proposal that fails on any of those three points.

Know what your DAO actually requires

Before you write a word, check the specific governance rules for the DAO you are targeting. Every DAO sets its own thresholds for:

• Proposal threshold - the minimum number of tokens you must hold or have delegated to you before you can submit. This varies widely; some DAOs require 1% of total supply, others require a flat 100,000 tokens. The OpenZeppelin Governor contract library lets DAOs set this value, and you should check the current figure on the DAO's governance page or forum.

• Quorum - the minimum total voting power that must participate for the vote to count. Low quorum is a known vulnerability; some DAOs have been captured when a small minority passed proposals against the majority's interests. If the DAO you are targeting has a low quorum, your proposal will be easier to pass but may face more opposition from the community itself.

• Voting period - typically 3 to 7 days on-chain, though some DAOs use Snapshot for off-chain signaling first and then move to an on-chain vote. Know the deadlines.

• Timelock - after a proposal passes, there is usually a delay (often 24 to 48 hours) before the execution. This exists so the community can challenge a malicious proposal. Plan for it.

Step 1: socialize before you formalize

Do not write a formal on-chain proposal as your first communication. Instead:

1. Post a draft on the DAO's forum or Discord. Use a clear title like "Draft: [Problem Statement] - [Proposed Solution]". Ask for feedback explicitly.
2. Run an off-chain Snapshot poll to gauge sentiment. Snapshot is free and gasless, and many DAOs treat a passing Snapshot vote as a green light to proceed.
3. Address concerns publicly. If people point out flaws, fix them. If they suggest alternatives, consider them. A proposal that surprises voters at the last minute rarely passes.

Step 2: Write a Clear Problem Statement

The first section of your proposal must state what problem you are solving. Be specific. Avoid vague statements like "improve the ecosystem." Instead:

• "The treasury holds 500,000 USDC earning 0% yield. Current market rates for stablecoin lending are 4-6% APY."
• "The DAO's frontend library is two versions behind the latest release. This causes a 30-second load time for users on mobile."

If the problem is not obvious to most token holders, your proposal will fail regardless of how well you write the solution.

Step 3: Propose a Concrete Action

Describe exactly what the DAO will do. Use numbered steps if the action involves multiple contract calls or fund movements. For example:

1. Transfer 100,000 USDC from the Gnosis Safe multisig to the Aave lending pool at address 0x...
2. Set the recipient address for interest to the DAO treasury multisig.
3. Authorize the treasury manager (Gnosis Safe signer set) to withdraw at any time.

If your proposal requires code changes, link to the pull request or the audited contract. If it involves a third-party service, explain the terms and risks.

Step 4: Justify the Choice

Explain why this solution is better than alternatives. This is where you demonstrate you have done the work. For a treasury investment proposal, you might compare lending to buying bonds, staking, or doing nothing. For a technical upgrade, you might explain why a specific library was chosen over competitors.

Do not hand-wave the risks. Acknowledging them and showing how they are mitigated builds trust. For example: "Lending through Aave carries smart contract risk. The protocol has been audited by [firm] and has operated without incident for [time period]. The DAO should still diversify across multiple platforms over time."

Step 5: Format for Readability

On-chain proposals are often read on small screens or in governance dashboards. Use:

• Short paragraphs (2-4 sentences max)
• Bullet points for lists
• Bold for key numbers or addresses
• A link to the full discussion thread

Avoid markdown tables; they render poorly on some platforms. Avoid jargon unless you define it.

Step 6: Set the Vote Parameters

When you submit the proposal, you or a delegate will need to set the voting parameters in the Governor contract. These include:

• Voting delay - how long after submission before voting starts. A 1-2 day delay gives people time to read.
• Voting period - 3-7 days is standard. Longer periods help global participation.
• Quorum - use the DAO's default unless you have a strong reason to change it.

If the DAO uses a delegate system, reach out to the top delegates before submission. A few large delegates can swing a vote, and they appreciate advance notice.

What Kills Proposals

Common reasons proposals fail:

• No prior discussion - voters see it cold and vote no out of caution.
• Unclear execution - the proposal says "invest in DeFi" but doesn't specify how or with what safeguards.
• Self-dealing - proposing that the DAO pay you or your company without a clear market-rate justification. Even if it's a good deal, the appearance of conflict will tank the vote.
• Ignoring the threshold - submitting without enough tokens and having the proposal automatically rejected.
• Too long - a 5,000-word proposal that no one finishes reading. Keep it under 1,000 words for the core text. Put technical appendices in a linked forum post.

After the Vote

If the proposal passes, the timelock period begins. Monitor the execution step; some DAOs require a separate transaction to execute the proposal after the timelock expires. If it fails, go back to the forum, ask voters what they disliked, and iterate. Many successful proposals are second or third attempts.

Back to daos