If you’ve participated in public goods funding rounds, then you’re probably familiar with quadratic funding (QF), which uses the square of the sum of the square roots of contributions to determine ideal public goods funding allocations:
payout = (Σ √cᵢ)² where cᵢ is an individual contribution.
It’s a pretty cool mechanism, but it can be TRICKY to implement.
Why? Because matching funds aren’t infinite. That is, the (Σ √cᵢ)² version of the QF formula doesn’t say what to do if your squared sums exceed available funds.
In practice, many QF rounds find themselves in this position.
The original QF paper already solves this
QF’s creators, Buterin, Hitzig, & Weyl, weren’t naive to this reality. Their paper included a QF variant for “capital-constrained” implementations (Section 5.1 - A Flexible Design for Funding Public Goods / https://arxiv.org/pdf/1809.06421). It introduced a scaling factor (α) that can be set to ensure the matching budget isn’t exceeded:
payout = Σcᵢ + α·((Σ√cᵢ)² − Σcᵢ)
α blends each project's allocation between two extremes. At α = 1, you get pure QF (the ideal, infinite-budget answer); at α = 0, the project gets its direct contributions with no matching. The capital-constrained α sits somewhere in between to fit your budget.
Crucially, this is not the same as using each project's (Σ √cᵢ)² as a proportional weight to split the matching pool, which is often the default web3 implementation.
The reason is subtle but important: (Σ √cᵢ)² represents a project's total ideal funding—direct contributions and the matching subsidy. Using it as a matching weight conflates the two, over-rewarding projects whose QF value comes mostly from a few large contributions at the expense of projects with broad, small-donor support.
Example:
- Open Hardware = 4 x $1 contributions
- OS Privacy = 1 x $4 contribution
- Matching Pool = $6
Both projects raised $4 in direct contributions, but QF says Open Hardware's broader support deserves more matching:
- Open Hardware's Ideal Funding = (4 · √1)² = 16
- OS Privacy's Ideal Funding = (√4)² = 4
Open Hardware's value contains $4 in direct contributions plus $12 in matching.
Since OS Privacy only had one contributor, its funding is entirely direct and earns $0 under ideal matching.
The total ideal matching across both projects is $12. The pool only has $6, so we have to scale matching down to fit.
Under proportional scaling, the $6 pool gets split using QF values as weights:
- Open Hardware gets 6 · (16/20) = $4.80 in matching
- OS Privacy gets 6 · (4/20) = $1.20 in matching
- Total payouts: Open Hardware receives $8.80, OS Privacy receives $5.20
Under proper capital-constrained QF, we can consume the whole budget (4 + 4 + 6 = $14) by setting α = 0.5. We get the following allocation:
- Open Hardware = 4 + 0.5·(16 - 4) = $10.00
- OS Privacy = 4 + 0.5·(4 - 4) = $4.00
Compared to capital-constrained QF, proportional scaling underpays Open Hardware (and its broad community support) by $1.20 and overpays OS Privacy by $1.20.
Why this matters
At least in part, QF took off in web3 because, on paper, it promised an ideal democratic allocation of funds.
While it’s understandable why proportional scaling is often used as an approximation, it can undermine that core democratic design goal. And once you know that, you can’t unknow it.
That’s why we’re excited for Epoch 12 to use a new onchain allocation mechanism in Octant v2 that we’re calling Proper QF (pQF). It’s our trustless implementation of capital-constrained QF, faithful to Buterin, Hitzig, & Weyl’s original proposal and proofs.
The implementation differences might not always jump off the screen. You’ll still see an estimated quadratic match at checkout. These estimates can change as more round contributions come in (as is the norm in every QF round).
But early in the round, you won’t see exceedingly large matching multipliers.
If you’re funding the matching pool, pQF doesn’t presume your full budget is consumed from day one. The round reaches 100% pool usage only if the community signal grows to justify it. More users = bigger community signal.
If participation exceeds the matching pool capacity, the α factor will scale payouts fairly: projects at least receive the direct contributions you make to them and your impact to matching isn’t improperly skewed one way by whales or the other by only small allocators.
It’s QF in the proper way it was designed to be.
