Setting Up a Quadratic Funding Round for Community Projects

Quadratic Funding (QF) is a mathematically optimal mechanism for public goods financing, where a matching pool amplifies community donations. The core principle is that many small contributions signal stronger collective support than a single large one. The matching amount for a project is proportional to the square of the sum of the square roots of individual contributions. This creates a subsidy formula: match = (sum(sqrt(contribution)))^2 - sum(contribution). Implementing this requires a secure system to collect contributions, calculate the match, and distribute funds, typically deployed as a set of smart contracts on a blockchain like Ethereum or its Layer 2s.

Setting up a round begins with defining parameters: the matching pool size (e.g., $50,000 in DAI), the application period for projects, the voting/contribution period, and the final distribution timeline. You'll need a registry for verified projects, a mechanism for users to donate (often via a minimal-viable coordination token like ERC-20), and a secure treasury for the matching pool. Most implementations use a round manager contract that orchestrates these phases, referencing a QF strategy contract to perform the match calculation off-chain for gas efficiency, as the square root operation is computationally expensive on-chain.

A critical technical component is the QF strategy. For example, using the Allo Protocol framework, you deploy a DonationVotingMerkleDistributionDirectTransferStrategy contract. This strategy uses a Merkle root to commit to the final match amounts for each project after off-chain computation. The process involves: 1) collecting all donation data, 2) running the QF algorithm in a trusted environment (like a backend service), 3) generating a Merkle tree of results, and 4) publishing the root to the strategy contract. Contributors can then claim their matched funds by submitting a Merkle proof. This design balances transparency with practicality.

Security and sybil-resistance are paramount. A naive QF implementation is vulnerable to collusion and sybil attacks, where one user splits their capital into many wallets to game the square root formula. Mitigations include integrating sybil defense layers like Gitcoin Passport (which aggregates decentralized identity credentials), requiring a minimum donation threshold, or using a capital-constrained matching pool. Your implementation must also handle token approvals securely, ensure funds are non-custodial, and include emergency withdrawal functions for the round operator in case of critical bugs.

After the round concludes, you must execute the distribution. Using the earlier Merkle root example, you call a function like distribute() on your strategy contract, which allows each project owner to claim their matched funds by providing the proof. It's essential to audit all contracts before launch and use established libraries like OpenZeppelin. For a complete, production-ready example, review the Gitcoin Grants Stack documentation or the Allo Protocol contracts on GitHub. These provide modular, audited primitives for launching your own community-funded rounds with quadratic matching.

Before deploying a quadratic funding round, you must understand its core mechanism and the required technical environment. Quadratic funding (QF) is a democratic matching mechanism where the amount of matching funds a project receives is proportional to the square of the sum of the square roots of its contributions. This design amplifies the impact of a broad base of small donors. The primary tool for implementing this on EVM chains is the Grants Stack, an open-source protocol by Gitcoin. You will need a basic understanding of blockchain concepts, Ethereum wallets (like MetaMask), and familiarity with testnets.

Your first step is to set up the necessary accounts and infrastructure. You will need: an Ethereum wallet with testnet ETH (e.g., on Sepolia or Optimism Sepolia) for deploying contracts and paying gas fees; a Gitcoin Grants Hub account to manage your round; and a basic development environment. For contract interaction, you can use tools like Foundry or Hardhat, but the Grants Stack Manager interface handles most deployment steps. Ensure your wallet is connected to the correct network specified by your round's requirements.

The core of your setup involves configuring the Grants Stack Round Manager. This web interface allows you to deploy the necessary smart contract suite without writing Solidity. You must prepare your round parameters in advance: the matching fund pool size (in USD or crypto), the round start and end dates, a list of verified projects, and the voting strategy (usually the default QF formula). All metadata—like the round name, description, and logo—should be prepared. This data is stored on IPFS via tools like Pinata or web3.storage to ensure decentralization and persistence.

A critical prerequisite is securing matching funds and understanding the deposit process. The matching pool is typically held in a Safe (Gnosis Safe) multisig wallet controlled by the round operator. You must fund this Safe with the matching token (e.g., DAI, ETH, or OP) on the chosen chain before the round starts. The Grants Stack uses a Quadratic Funding Voter contract to calculate distributions and a Round Implementation contract to manage the round lifecycle. Familiarize yourself with the official Grants Stack documentation for the latest contract addresses and deployment guides.

Finally, test your entire setup on a testnet before mainnet deployment. Deploy a round using testnet ETH and simulate contributions from multiple donor addresses to verify the QF matching calculations and the final distribution process. Check that your project registry is correctly linked and that the round operator permissions are properly configured. This dry run helps identify issues with timing, funding, or metadata. Once validated, you can proceed to launch your round on mainnet, initiating a transparent and community-driven funding process.

Quadratic Funding (QF) is a democratic mechanism for allocating a matching pool to community projects based on the number of contributors, not just the total amount contributed. The core formula is: Matching Amount ∝ (Square Root of Sum of Contributions)^2. This amplifies the impact of small, grassroots donations, making it ideal for funding public goods. To run a QF round, you need a smart contract platform, a funding source (the matching pool), and a frontend for contributors. Popular infrastructure includes Gitcoin Grants Stack, clr.fund, and Allo Protocol, which handle the complex QF calculations and distribution.

For this tutorial, we'll use Grants Stack, a suite of tools for managing QF rounds. First, define your round parameters: the total matching pool amount (e.g., 50,000 DAI), the application period (2 weeks), the voting period (2 weeks), and the accepted tokens (e.g., ETH, DAI on Optimism). You must also set the Quadratic Funding formula and any eligibility requirements for projects. These parameters are configured in the Grants Stack Manager interface and deployed as a set of smart contracts on your chosen EVM chain, such as Optimism or Arbitrum.

Project applications are submitted through your round's landing page. Each project creates a profile with a description, funding goal, and recipient address. During the voting period, contributors donate directly to projects. The key QF mechanic is that a $1 donation from 100 people generates more matching funds than a $100 donation from one person. After the round ends, the QF algorithm calculates the final matching amounts. The Grants Stack contracts then distribute the matching pool funds proportionally to the projects, combining them with the direct donations they received.

Gitcoin Grants Stack is a modular, open-source protocol for running Quadratic Funding (QF) rounds. QF is a democratic funding mechanism where a matching pool amplifies community donations, making small contributions more impactful. The Grants Stack provides the smart contracts, frontend, and backend services needed to deploy a round without building from scratch. It's used by major ecosystems like Ethereum, Optimism, and Polygon to distribute millions in matching funds. You can explore the official documentation for the latest specifications.

Before creating a round, you must define your program's parameters. Key decisions include the round's start and end dates, the matching pool size (in ETH, USDC, or other tokens), and the application requirements for projects. You'll also need to configure the Quadratic Funding formula and set any eligibility rules, such as requiring a GitHub repository or verified project profile. These parameters are set in a configuration file (often config.json) that the Grants Manager will deploy. The Allo Protocol V2 smart contracts handle the secure distribution of funds.

The technical setup involves interacting with the Grants Stack's Manager Interface. First, connect a wallet with sufficient funds for the matching pool and gas fees. Navigate to the round creation wizard, where you'll input your configuration. The process will prompt you to deploy two main contracts: a Project Registry (where grantees create profiles) and the Round Contract (which manages the QF logic and distribution). All deployments occur on your chosen EVM-compatible chain. It's critical to conduct a test round on a testnet (like Sepolia or Goerli) before launching on mainnet.

After deployment, you must fund the matching pool. This is done by transferring the designated token amount to the Round Contract's treasury address. The contract uses a direct grants mechanism or a matching pool model. For transparency, the funding transaction should be recorded and shared with your community. The round will not be active for donations until the start date passes and the pool is funded. You can monitor the round's status and incoming applications through the manager dashboard.

Finally, promote your round to attract projects and donors. Share the public round URL, which allows projects to apply and contributors to donate. The Grants Stack provides built-in tools for project verification, sybil resistance (like Passport integration), and real-time results. After the round concludes, the matching funds are automatically calculated and distributed to projects based on the QF algorithm. You can review the Grants Hub for examples of live and past rounds to inform your strategy.

A quadratic funding round is implemented through a smart contract that collects donations, calculates matching funds, and distributes them. The core logic uses the QF formula to allocate a matching pool based on the square root of each project's total contributions. For Ethereum-based implementations, you can deploy a contract like QFContract.sol which inherits from OpenZeppelin's Ownable and ReentrancyGuard for security. The contract must manage key state variables: matchingPool, projects[], contributions, and the round's startTime and endTime. The critical function distributeMatch() iterates through projects after the round closes, calculates each one's match using the QF algorithm, and transfers funds.

Before deployment, you must set up your development environment. Use Hardhat or Foundry for local testing. Install dependencies: npm install @openzeppelin/contracts for secure base contracts and dotenv for environment variables. Configure hardhat.config.js with networks like Sepolia or Goerli for testing. Write comprehensive tests for your QF contract; a key test verifies the matching calculation. For example, if Project A receives 4 donations of 1 ETH each (sum of square roots = 2+2=4, squared = 16) and Project B receives 1 donation of 4 ETH (sum of square roots = 2, squared = 4), with a 100 ETH matching pool, Project A gets 80 ETH and Project B gets 20 ETH. Run tests with npx hardhat test.

The frontend interface connects users to the contract. Use React with wagmi and viem for Ethereum interaction. Key components are a project listing, a contribution form, and a results dashboard. The contribution function calls your contract's contribute(uint256 projectId) method, sending ETH via the value field. To display real-time data, listen for the Contributed event. After the round, call distributeMatch() from an admin panel (protected by the onlyOwner modifier). For a complete reference, study the Gitcoin Grants protocol implementation or the clr.fund open-source codebase. Always audit your contract or use a service like Sherlock or Code4rena before mainnet deployment.

Quadratic funding amplifies the impact of small donations, but its fairness depends on preventing sybil attacks where a single entity creates multiple identities to manipulate results. Voter identity verification is the process of ensuring each vote comes from a unique, legitimate participant. Without it, the matching pool can be easily gamed. Common verification methods include Gitcoin Passport, BrightID, Proof of Humanity, and custom attestation systems built with tools like Ethereum Attestation Service (EAS). The goal is to create a cost or social barrier to identity duplication that exceeds the potential profit from gaming the round.

For many projects, integrating an existing solution like Gitcoin Passport is the fastest path. Passport aggregates trust from multiple Web2 and Web3 identity providers—such as Google, Github, BrightID, and Proof of Humanity—into a single score. You can configure your round to require a minimum Passport score for a vote to count. Implementation involves querying the Passport API or smart contract to verify a user's score when they submit their ballot. This delegates the complex verification logic and sybil analysis to a dedicated, continuously updated system.

For more control or specific requirements, you can build a custom verification layer using Ethereum Attestation Service. With EAS, a trusted issuer (like your project's team or a community council) can create on-chain attestations that a specific Ethereum address belongs to a verified human. Your funding round's smart contract would then check for a valid, unrevoked attestation from your designated issuer before accepting votes. This pattern is useful for closed rounds, such as those for a specific DAO or guild, where the issuer can perform off-chain KYC or validate membership credentials.

The verification logic must be embedded directly into your voting smart contract. A typical vote function will include a check. For example, using a simple registry contract:

solidityCopy
function vote(uint256 projectId, uint256 amount) external {
    require(identityRegistry.isVerified(msg.sender), "Voter not verified");
    // ... rest of voting logic
}

The identityRegistry could be a contract that holds a mapping of verified addresses, updated by your chosen verification method's backend or via EAS schema checks. This ensures verification is enforced on-chain, making the round's rules transparent and tamper-proof.

Consider the trade-offs between different verification methods. Social verification (BrightID, Proof of Humanity) offers strong sybil resistance but may limit participant reach. Credential aggregation (Gitcoin Passport) provides a balance of security and accessibility. Custom attestations offer maximum flexibility but require you to manage the issuance and revocation process. The right choice depends on your round's size, community, and trust assumptions. Always clearly communicate verification requirements to participants before the round begins to ensure smooth onboarding.

After implementing verification, test thoroughly. Run simulations with test identities to ensure the sybil resistance works as intended. Monitor for any issues with the verification provider's uptime. Finally, consider complementing identity checks with donation limits or capital constraints per voter, as a secondary defense. This layered approach, combining unique identity verification with other economic safeguards, creates a robust foundation for a legitimate and impactful quadratic funding round that truly reflects community sentiment.

The quadratic funding (QF) algorithm determines the final distribution of matching funds. It is not a simple 1:1 match. Instead, it calculates a subsidy for each project based on the square root of the sum of contributions it receives. The fundamental formula for a project's match is: Match_i = (sum(sqrt(contribution)))^2 - sum(contribution). This structure creates a quadratic relationship where many small donations are valued more highly than a few large ones, effectively measuring the breadth of community support.

To execute this calculation, you need to process all contributions after the round closes. Using a round manager contract like RoundImplementation from the Allo protocol, you can call the distribute() function. This function triggers the payout strategy, which contains the QF logic. The strategy contract will iterate through all projects, calculate their match amount using the verified contribution data, and prepare the distribution. The funds are then sent from the matching pool to the project's designated payout wallet.

A critical step is verifying the results. Before finalizing, you should run the calculation off-chain to audit the expected distribution. Tools like the QF template from Gitcoin's Passport or libraries such as qfi can be used for this. Compare the calculated match amounts against the on-chain results to ensure no discrepancies. This verification protects against errors in the smart contract logic or contribution data indexing.

For developers, implementing a custom QF strategy involves writing a Solidity contract that inherits from a base class like BaseStrategy in the Allo protocol. Your contract must implement key functions: _allocate to record contributions, _distribute to calculate and send matches, and getPayouts to return the distribution array. The calculation itself is gas-intensive, so consider performing the heavy math off-chain and storing the results in a Merkle root for efficient on-chain verification.

Finally, transparency in distribution is paramount. After the round, publish a complete report including: the total matching pool size, the final list of projects with their total contributions and match amounts, and the calculation breakdown. Providing this data allows the community to verify the fairness of the outcome and builds trust for future rounds. The entire process, from closing contributions to distributing funds, should be automated and verifiable on-chain to minimize manual intervention and central points of failure.

Your round is now live and ready to receive contributions. The core components you've deployed—the RoundFactory, QuadraticFundingVotingStrategy, and DirectPayoutStrategy—work together to calculate matching funds using the quadratic formula (sum of sqrt(contribution))^2. This ensures a $100 donation from 100 people has more impact than a single $10,000 donation. Monitor the round's progress through your application's dashboard or by querying the contract events directly.

To ensure a successful round, proactive community management is essential. Clearly communicate the round's rules, timeline, and the quadratic funding mechanism to participants. Use tools like the grant-explorer from Gitcoin or build a custom interface using the allo-sdk. Track key metrics: the number of unique contributors per project is a more significant indicator of success than the total amount raised due to the quadratic matching algorithm.

Once the round concludes, you must trigger the distribution phase. Call the payout function on your DirectPayoutStrategy contract to execute the calculated payouts. All matching funds from the pool and direct donations will be distributed to the approved projects. Remember to factor in gas costs for this transaction, especially if paying out to many recipients. Always verify the final matching results on-chain before payout.

After distribution, analyze the round's data to improve future iterations. Examine which project categories garnered the most unique support, the effectiveness of your marketing channels, and any Sybil attack vectors that may have emerged. Consider using Sybil defense tools like Gitcoin Passport or integrating with Allo's Registry for enhanced project and recipient identity management.

For next steps, explore advanced configurations. You can implement a minimum contribution threshold to filter noise, use a MACI (Minimal Anti-Collusion Infrastructure) layer for private voting, or set up a merkle-based payout strategy for gas-efficient distributions. The contracts are upgradeable by the owner, allowing you to iterate on the mechanism based on community feedback and evolving needs.

The code and concepts from this guide provide a foundation. Continue your learning by reviewing the official Allo Protocol documentation, experimenting on a testnet, and engaging with the governance communities of ecosystems like Optimism or Arbitrum that frequently use quadratic funding for their grant programs. Building transparent, community-driven funding mechanisms is a key primitive for the next generation of digital public goods.