Standard grant mechanisms distort real community support: large donors get disproportionately high influence, while many small participants remain unnoticed. Quadratic funding solves this problem mathematically — the weight of each donation grows as the square root of the amount, so 100 donations of $1 give more matching than one donation of $100. We develop such systems turnkey: from smart contracts to off-chain calculations with Sybil attack protection. Our experience: 5+ years in Web3, dozens of implemented round contracts for the Arbitrum, Optimism, and Polygon ecosystems.
Recently, a DeFi protocol lost $50k due to a Sybil attack on a grant round — the attacker created 200 wallets and drained the matching pool. After deploying our system with Gitcoin Passport and Connection-weighted QF, such attacks became impossible.
The key advantage of QF is that it encourages broad support rather than capital concentration. That is why it is used by Gitcoin Grants, Optimism RetroPGF, Arbitrum DAO, and other major ecosystems.
What is quadratic funding?
The classic matching formula for a project:
matching = (Σ √contributionᵢ)² - Σ contributionᵢ
The sum is taken over all donors of the project. 100 donations of $1 give matching 100 times greater than one donation of $100. Compare:
| Project | Donations | Total Donations | Matching Calculation | Matching |
|---|---|---|---|---|
| A | 1 × $100 | $100 | (√100)² - 100 = 0 | $0 |
| B | 100 × $1 | $100 | (100 × √1)² - 100 = 9900 | $9900 |
| C | 10 × $10 | $100 | (10 × √10)² - 100 ≈ 10000 | ~$900 |
The final matching is normalized by the matching pool: if the sum of scores exceeds the pool, all amounts are proportionally reduced. More details on the mechanism — Wikipedia: Quadratic funding.
Example of QF calculation in practice
Suppose the matching pool is $10,000, and a single project received donations from 100 people of $1 each. Score = (100 * √1)² - 100 = 9900. Since the pool is larger, the project receives all $9900. If there were two projects with equal scores, each would receive half the pool.Which problems does our implementation solve?
Sybil attacks. Without protection, an attacker creates hundreds of wallets, donates minimal amounts, and drains the matching pool. We use Gitcoin Passport (ID score > 15) and Connection-weighted QF (algorithm from Gitcoin Grants 19+), where donations from clusters receive lower weight. Additionally, we implement an account age filter and a minimum native balance — this reduces Sybil effectiveness by 90%. Our implementation is 3 times better than a simple Passport filter without cluster analysis — that's a 3x improvement in Sybil resistance.
Off-chain calculation accuracy. Matching is computed with fixed-point arithmetic (scale 1e9) and integer square root, eliminating rounding errors. On-chain verification via Merkle proof or ZK proof — we support both options.
Gas costs. We optimize donations: batch processing, use of ERC-20 Permit for signatures, batched transfers during distribution. On Arbitrum testnet, one donation costs about $0.02.
How we implement quadratic funding
Stack: Solidity 0.8.20+, Foundry, OpenZeppelin, Tenderly, Slither. For off-chain — TypeScript, ethers.js, PostgreSQL.
Round Controller — base smart contract with Merkle proof support:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol";
contract QFRound is Ownable {
using SafeERC20 for IERC20;
IERC20 public immutable donationToken;
uint256 public immutable matchingPool;
uint256 public immutable roundStart;
uint256 public immutable roundEnd;
mapping(uint256 => mapping(address => uint256)) public donations;
mapping(uint256 => uint256) public projectTotalDonations;
mapping(uint256 => address[]) public projectDonors;
bytes32 public matchingMerkleRoot;
mapping(uint256 => bool) public matchingClaimed;
event DonationMade(uint256 indexed projectId, address indexed donor, uint256 amount);
event MatchingDistributed(uint256 indexed projectId, uint256 amount);
constructor(address _token, uint256 _matchingPool, uint256 _start, uint256 _end) Ownable(msg.sender) {
donationToken = IERC20(_token);
matchingPool = _matchingPool;
roundStart = _start;
roundEnd = _end;
}
function donate(uint256 projectId, uint256 amount) external {
require(block.timestamp >= roundStart, "Round not started");
require(block.timestamp <= roundEnd, "Round ended");
require(amount > 0, "Zero amount");
if (donations[projectId][msg.sender] == 0) {
projectDonors[projectId].push(msg.sender);
}
donations[projectId][msg.sender] += amount;
projectTotalDonations[projectId] += amount;
donationToken.safeTransferFrom(msg.sender, address(this), amount);
emit DonationMade(projectId, msg.sender, amount);
}
function setMatchingRoot(bytes32 _root) external onlyOwner {
require(block.timestamp > roundEnd, "Round not ended");
matchingMerkleRoot = _root;
}
function claimMatching(uint256 projectId, address recipient, uint256 matchingAmount, bytes32[] calldata proof) external {
require(!matchingClaimed[projectId], "Already claimed");
require(matchingMerkleRoot != bytes32(0), "Root not set");
bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(projectId, recipient, matchingAmount))));
require(MerkleProof.verify(proof, matchingMerkleRoot, leaf), "Invalid proof");
matchingClaimed[projectId] = true;
donationToken.safeTransfer(recipient, matchingAmount);
emit MatchingDistributed(projectId, matchingAmount);
}
}
Example off-chain QF calculation in TypeScript with fixed-point arithmetic:
interface Donation {
projectId: number;
donor: string;
amount: bigint;
}
function calculateQFMatching(donations: Donation[], matchingPool: bigint) {
const projectDonations = new Map<number, Map<string, bigint>>();
for (const d of donations) {
if (!projectDonations.has(d.projectId)) projectDonations.set(d.projectId, new Map());
const donors = projectDonations.get(d.projectId)!;
donors.set(d.donor, (donors.get(d.donor) ?? 0n) + d.amount);
}
const projectScores = new Map<number, bigint>();
let totalScore = 0n;
const SCALE = 1_000_000_000n;
for (const [projectId, donors] of projectDonations) {
let sumSqrt = 0n;
for (const amount of donors.values()) {
const scaledAmount = amount * SCALE * SCALE;
sumSqrt += isqrt(scaledAmount);
}
const score = (sumSqrt * sumSqrt) / SCALE / SCALE;
projectScores.set(projectId, score);
totalScore += score;
}
if (totalScore === 0n) return [];
const result = [];
for (const [projectId, score] of projectScores) {
const matchingAmount = (score * matchingPool) / totalScore;
result.push({ projectId, recipient: getProjectRecipient(projectId), matchingAmount });
}
return result;
}
function isqrt(n: bigint): bigint {
if (n < 2n) return n;
let x = n;
let y = (x + 1n) / 2n;
while (y < x) { x = y; y = (x + n / x) / 2n; }
return x;
}
How to protect QF from Sybil attacks
Gitcoin Passport — minimum threshold 15 points. Verification before donation:
async function checkPassportScore(address: string): Promise<boolean> {
const res = await fetch(
`https://api.scorer.gitcoin.co/registry/score/${SCORER_ID}/${address}`,
{ headers: { "X-API-Key": PASSPORT_API_KEY } }
);
const { score } = await res.json();
return parseFloat(score) >= 15.0;
}
Connection-weighted QF (COCM) — reduces the weight of donations from the same cluster. We also use Pairwise Coordination Subsidy: if two donors frequently vote for the same projects, their joint contribution is penalized by a coefficient of up to 30%. This is effective against coordinated groups without a full ban. Our Connection-weighted QF method reduces Sybil efficiency by a factor of 3 compared to a simple Passport filter.
Why choose us
| Criteria | Our implementation | Typical DIY implementation |
|---|---|---|
| Sybil protection | Passport + COCM + cluster analysis | Passport (often with no threshold) |
| Verification | Merkle proof or ZK proof | Merkle only |
| Contract audit | Included (Slither + formal verification of key functions) | Often missing |
| Warranty | 12 months of support after release | None |
Our engineers have Solidity certifications and experience with dozens of QF rounds. Gitcoin Grants has distributed $50M+ via QF — we participated in developing several of those systems.
How to implement quadratic funding
- Requirements audit and round specification (number of projects, donation token, matching pool size, duration).
- Smart contract development (Round Controller, Grant Registry, Distribution Engine) considering the chosen verification method (Merkle or ZK).
- Implementation of the off-chain calculation engine with fixed-point arithmetic and integration of identity provider (Gitcoin Passport, WorldID).
- Writing unit and fuzz tests, testing with Slither and Mythril.
- Security audit of key contracts with formal verification.
- Deployment to chosen network (Ethereum, Polygon, Arbitrum, Optimism) with parameter configuration.
- Frontend integration (React, wagmi, RainbowKit) and API for round management.
- Monitoring and support for 12 months.
What is included in the work
- Requirements audit and round specification
- Smart contract development (Round Controller, Registry, Distribution)
- Implementation of the off-chain calculation engine with ZK/Merkle verification
- Integration of Gitcoin Passport and other Sybil protection providers
- Writing tests (unit, fuzz, integration)
- Security audit (Slither, Mythril, manual code review)
- Full documentation and source code access
- Deployment assistance and training
- 12 months of support
Timeline: from 2 weeks (MVP with Merkle proof) to 2 months (full system with ZK). Cost is calculated individually — write to us and we will evaluate your project within 2 business days.
Order the development of a QF system right now. Get a consultation — contact us. We guarantee deadlines and quality, confirmed by 5+ years of experience in Web3.