Funding Proposal

Defines the specific work to be performed, including technical specifications, features, and milestones. This section establishes clear, measurable deliverables (e.g., a smart contract audit report, a completed dApp frontend, a research paper) that are used to gauge progress and completion. Ambiguity here is a primary cause of grant disputes.

Specifies the total grant amount requested, denominated in the treasury's native token or a stablecoin, and details the allocation breakdown. This includes:

• Development costs
• Operational expenses (hosting, tools)
• Team compensation
• Contingency buffers Transparency here is critical for assessing budget feasibility and preventing fund misuse.

Outlines a payment schedule tied to the verification of pre-defined milestones. This is a core accountability mechanism, releasing funds incrementally upon community or committee approval of completed work. It protects the treasury by ensuring capital is disbursed only for verified progress, reducing the risk of funding unfinished projects.

Provides verifiable information about the project team, including:

• Public identities or pseudonyms
• Relevant experience and past contributions
• GitHub repositories or prior work
• Wallet addresses for payment This establishes credibility and allows the community to assess the team's capability to execute the proposal. Anonymous teams may require additional proof-of-work.

Defines the Key Performance Indicators (KPIs) that will measure the project's impact post-funding. These are quantifiable metrics beyond delivery, such as:

• User adoption rates
• Total Value Locked (TVL) increase
• Transaction volume generated
• Code commits or community engagement KPIs align the project's goals with the treasury's strategic objectives.

Details the reporting process and governance interaction. This includes:

• Frequency of progress reports
• Communication channels (e.g., forum posts, community calls)
• The process for milestone verification and dispute resolution
• On-chain voting mechanisms for fund release This framework ensures ongoing transparency and community oversight throughout the grant's lifecycle.

This section provides a high-level overview and defines the core issue the proposal aims to solve. It must clearly articulate the problem statement, the proposed solution, and the value proposition for the protocol or community. This is the elevator pitch that determines if stakeholders read further.

This is the technical and operational blueprint. It breaks down the project into specific, measurable deliverables (e.g., smart contract audit report, frontend UI, marketing campaign). It should include:

• Timeline with clear milestones.
• Technical specifications and architecture.
• Success criteria and key performance indicators (KPIs).

A transparent and itemized financial plan is critical. This section details the total funding request (often in the native governance token or stablecoins) and allocates it across categories like development, marketing, and operational costs. It should justify each line item and may include vesting schedules or milestone-based payouts.

Proposals must establish credibility by detailing the project team's relevant experience, past contributions to the ecosystem, and specific roles. For anonymous teams, this may include links to past work, GitHub repositories, or pseudonymous reputations. This section addresses the team's capability to execute the proposed work.

This defines the mechanics of the proposal itself within the DAO's governance framework. It specifies:

• The voting system (e.g., token-weighted, quadratic).
• Voting duration and quorum requirements.
• The on-chain execution process for transferring funds upon approval.
• Any multisig or vesting contract addresses for fund custody.

A robust proposal anticipates challenges. This section outlines potential risks (technical, market, regulatory) and mitigation strategies. It also defines clear, verifiable metrics for success (e.g., user growth, TVL increase, fee generation) that will be used to evaluate the project's impact post-funding.

Proposals to fund growth activities, including:

• Hackathons and bug bounty programs.
• Content creation, translation, and education.
• Community moderator compensation.
• Partnerships and business development efforts. These often require clear KPIs (Key Performance Indicators) like user growth or engagement metrics for accountability.

Standardized templates to improve clarity and success rates. Widely used frameworks include:

• Project Proposal Template: Problem, solution, team, budget, timeline.
• Grant Proposal Template: Abstract, deliverables, impact, sustainability plan.
• RFC (Request for Comments): For gathering community feedback before a formal vote. Adopting a framework ensures all necessary information is presented for informed voting.

A core vulnerability where an attacker creates many fake identities (Sybils) to gain disproportionate voting power. Defenses include:

• Proof-of-Personhood systems (e.g., Worldcoin, BrightID)
• Token-weighted voting, where cost to attack scales with capital
• Quadratic voting to reduce large-holder dominance
• Bonding curves that increase cost per additional vote

Proposals can be designed to siphon funds to an attacker. Mitigations involve:

• Multi-sig timelocks delaying execution after approval
• Delegate call guards preventing arbitrary contract execution
• Spending limits per proposal or time period
• Rage-quit mechanisms allowing dissenting token holders to exit before fund disbursement

Low voter turnout centralizes power with a small, potentially malicious group. Solutions aim to increase engagement:

• Delegated voting (e.g., Compound, Uniswap) for passive participation
• Incentive mechanisms like voting rewards or bribing platforms (e.g., Votium)
• Quorum requirements ensuring a minimum vote threshold for validity
• Snapshot for gas-free off-chain signaling

The token's market dynamics directly impact governance security.

• Vote buying: Tokens can be borrowed (e.g., via flash loans) to pass proposals, decoupling voting power from long-term interest.
• Whale dominance: Concentrated holdings can override community will.
• Protocols like MakerDAO use Governance Security Modules (GSM) with delays to allow MKR holders to react to malicious governance actions.

The technical execution of a passed proposal carries risks.

• Smart contract bugs in new code can be exploited.
• Governance contract itself must be upgradeable, creating a meta-governance attack vector.
• Best practice is a phased rollout: testnet deployment, time-locked execution, and multisig emergency pauses.

Ensuring proposers are identifiable and accountable for their requests.

• Required KYC for large grants (e.g., Aave Grants DAO).
• Milestone-based payouts tied to verifiable deliverables.
• On-chain reputation systems tracking past proposal success.
• Forum discussion mandates (e.g., Discourse threads) before on-chain voting.

A pool of assets (often native tokens and stablecoins) owned and managed by a DAO or protocol. It is the source of funds for approved proposals.

• Management: Controlled via multi-signature wallets or smart contracts.
• Purpose: Funds development, grants, liquidity incentives, and other operational expenses to ensure long-term sustainability.

A structured initiative, often managed by a sub-DAO or committee, to distribute funds for ecosystem growth, such as developer bounties, research, or community projects.

• Relation to Proposals: Can be established via a high-level funding proposal, which then delegates ongoing distribution authority.
• Example: The Uniswap Grants Program (UGP) funds builders in the Uniswap ecosystem.

The two primary methods for executing governance decisions on funding proposals.

• On-chain Voting: Votes are written directly to the blockchain (e.g., Compound, MakerDAO). Binding and secure, but incurs gas fees.
• Off-chain Voting: Voting occurs on platforms like Snapshot. Used for signaling and is gas-free, but requires a separate step for on-chain execution.