Budget Proposal

The core of a budget proposal is the explicit request for a specific amount of treasury assets, broken down into a detailed allocation. This includes:

• Total ask amount in the DAO's native token or stablecoins.
• Line-item breakdown for salaries, software, marketing, grants, and operational costs.
• Vesting schedules or milestone-based releases to ensure funds are disbursed as work is completed.

A successful proposal clearly defines the problem statement it aims to solve and its key objectives (KPIs). This establishes the 'why' and provides measurable goals for accountability. Examples include:

• Increasing protocol revenue by X% through a new product feature.
• Growing the developer community by funding X grants or hackathons.
• Improving security via a dedicated audit program.

This section outlines the actionable plan and concrete deliverables. It answers 'how' the work will be done and 'what' will be delivered. Key components are:

• Project timeline with phases and milestones.
• Team composition and relevant experience.
• Technical specifications or product roadmap.
• Deliverables such as a smart contract audit report, a live dApp, or a completed research paper.

The proposal is embedded within the DAO's on-chain governance framework. This defines the rules for passage, including:

• Voting period (e.g., 5 days).
• Quorum requirement (minimum participation threshold).
• Approval threshold (e.g., simple majority or supermajority).
• Delegated voting through platforms like Snapshot or Tally, where token holders signal their support.

Post-approval, proposers are typically required to provide transparent reporting on fund usage and progress. This fosters accountability and may include:

• Regular updates (bi-weekly or monthly) in community forums.
• On-chain transparency for large transactions.
• Final report comparing achieved results against the stated KPIs from the objectives section.

A robust proposal acknowledges potential risks and outlines mitigation strategies or contingency plans. This demonstrates thorough planning and can include:

• Technical risks (e.g., smart contract vulnerabilities).
• Market risks (e.g., token price volatility affecting budget).
• Execution risks (e.g., key personnel leaving).
• A plan for returning unspent funds to the treasury.

The core of the proposal, specifying the exact amount of capital requested from the treasury. This figure should be broken down into a line-item budget and justified with market-rate quotes or detailed cost estimates. It often specifies the payment token (e.g., USDC, ETH, DAO's native token) and may include a multisig wallet address for disbursement.

A detailed allocation of the total request, typically presented as a table or list. Each line item (e.g., development, marketing, legal, operational overhead) must include:

• Cost Estimate: A realistic figure.
• Vendor/Recipient: Who will be paid.
• Justification: Why this cost is necessary for the project's success.
• Timeline: When the funds are needed (milestone-based).

Defines the Key Performance Indicators (KPIs) that will be used to measure the project's success and the return on the treasury's investment. These are objective, quantifiable metrics that the proposal team commits to reporting on. Examples include:

• User growth targets (e.g., 10,000 new wallets).
• Protocol revenue generated.
• Code commits or features delivered.
• Reduction in gas costs or improvement in throughput.

Identifies the individuals or entities responsible for executing the proposal and stewarding the funds. This section builds trust and includes:

• Team members with relevant experience and public profiles (GitHub, LinkedIn).
• Past contributions to the ecosystem or similar projects.
• Roles and responsibilities for each member.
• Legal entity (if applicable), such as a registered company or DAO.

Outlines how funds will be released, tying disbursement to the achievement of verifiable milestones. This mitigates risk for the treasury. Common structures include:

• Upfront Payment: A small portion to begin work.
• Milestone-based Payments: Bulk of funds released upon delivery of predefined outputs.
• Retroactive Funding: Full payment after all work is completed and verified.
• Vesting Schedules: For longer-term engagements or team compensation.

A responsible assessment of potential risks and a plan for handling them. This demonstrates thorough planning and includes:

• Identified Risks: Technical hurdles, market conditions, team availability.
• Mitigation Strategies: Plans to address each risk.
• Contingency Budget: A reserved portion of funds (e.g., 10-15%) for unforeseen costs.
• Failure Conditions: What constitutes project failure and what happens to unspent funds.

A budget proposal follows a structured governance process:

• Drafting & Discussion: A community member or team drafts a proposal, often in a forum, detailing scope, budget, and timeline.
• Temperature Check: An informal poll gauges initial community sentiment.
• Formal Submission: The proposal is submitted on-chain via a governance contract (e.g., Snapshot, Tally).
• Voting Period: Token holders vote to approve or reject the proposal.
• Execution: If approved, funds are disbursed from the treasury, often via a multisig wallet or automated smart contract.

Budget proposals fund diverse initiatives:

• Grants & Ecosystem Funding: Financial support for developers, researchers, or community projects building on the protocol.
• Core Development: Salaries and resources for ongoing protocol development, audits, and maintenance.
• Marketing & Growth: Campaigns, content creation, and partnerships to drive adoption.
• Operational Costs: Covering infrastructure (servers, APIs), legal counsel, and other administrative expenses.
• Liquidity Incentives: Programs to bootstrap liquidity in decentralized exchanges (DEXs).

Effective proposals are comprehensive and transparent, typically including:

• Abstract: A clear, concise summary of the proposal's goal.
• Motivation: The problem statement and why funding is needed.
• Specification: Detailed technical and operational scope of work.
• Budget Breakdown: A line-item budget justifying all costs (e.g., developer hours, software licenses, marketing spend).
• Team & Credentials: Background of the proposers and relevant experience.
• Success Metrics & KPIs: How progress and success will be measured and reported back to the community.

The Uniswap Grants Program (UGP) is a prime example of budget proposals in action. The UGP itself is funded by a large, community-approved treasury allocation. Individual grant seekers then submit proposals to the UGP committee, requesting funds for specific projects that benefit the Uniswap ecosystem. This creates a two-tiered system where a master budget proposal funds a grants program, which then evaluates and executes on smaller, more granular proposals.

Budget proposal systems face several challenges:

• Voter Apathy: Low participation can lead to governance capture by a small, active group.
• Information Asymmetry: Voters may lack the technical or financial expertise to evaluate complex proposals.
• Execution Risk: Ensuring funds are used as promised requires robust reporting and, sometimes, vesting schedules.
• Treasury Sustainability: Proposals must balance short-term growth with the long-term health of the protocol treasury.

The process is facilitated by specialized tooling:

• Discussion Forums: Discourse and Commonwealth for drafting and feedback.
• Snapshot: Used for off-chain, gas-free signal voting on proposal sentiment.
• Tally & Boardroom: Interfaces for on-chain voting and delegate management.
• Sybil: Tools for verifying delegate identities and preventing sybil attacks.
• Safe (Gnosis Safe): A popular multisig wallet for secure treasury management and fund disbursement.

A structured process ensures deliberate review. A typical lifecycle includes:

• Drafting & Discussion: Initial forum post for community feedback.
• On-chain Submission: Formal proposal with executable code or parameters.
• Voting Period: Token-holders cast votes, often requiring a quorum.
• Timelock Execution: Approved proposals enter a mandatory waiting period before funds are released, providing a final safety net for review or cancellation. This multi-stage process prevents rushed or malicious spending.

Governance parameters protect against low-participation attacks and ensure legitimacy.

• Quorum: The minimum percentage of voting power that must participate for a vote to be valid. Prevents a small, coordinated group from passing proposals in a low-turnout scenario.
• Approval Threshold: The percentage of participating votes required for a 'Yes' outcome (e.g., >50% simple majority, >66% supermajority). Setting these thresholds is a key governance decision balancing security with efficiency.

Proposals must consider the treasury's asset composition and market risk.

• Asset Volatility: Proposals funded by native tokens expose the treasury to price swings, affecting future spending power.
• Diversification Proposals: Some proposals aim to swap treasury assets into stablecoins or other reserves to mitigate volatility risk.
• Smart Contract Risk: Proposals involving DeFi protocols to generate yield introduce additional technical and insolvency risks that must be audited.

In delegated proof-of-stake (DPoS) systems, voters rely on delegates or validators to vote on their behalf. This creates principal-agent risks:

• Voter Apathy: Low direct participation can centralize decision-making power with a few large delegates.
• Delegate Accountability: Mechanisms like vote delegation tracking and slashing for malicious voting are proposed to align delegate actions with voter intent. Transparent voting records are essential.

Systems must prevent the artificial inflation of voting power.

• Token-Weighted Voting: The standard model where one token equals one vote. This is susceptible to whale dominance but is inherently Sybil-resistant (splitting tokens doesn't increase power).
• 1p1v & Proof-of-Personhood: Alternative models aim to reduce whale power but require robust Sybil-resistance mechanisms (like biometrics or social graphs) to prevent fake identities from flooding votes.
• Bribe Markets: Platforms can emerge to openly trade voting influence, challenging governance integrity.

The final step of transferring funds requires technical security.

• Multisig Wallets: Treasury funds are often held in a multisignature wallet requiring M-of-N approvals from elected community stewards, adding a human review layer even after a vote.
• Parameterized Proposals: Best practice is to propose specific, immutable transaction parameters (amount, recipient, contract), not open-ended spending authority.
• Emergency Powers: Some systems have a security council or pause guardian with limited powers to halt malicious executed proposals in extreme scenarios.