Quadratic Funding

Quadratic funding is a system used for situations where you have a large pool of money and want to allocate that to various public goods projects in the most "optimal" way (optimized wrt some "it's an economics paper, fine, assume homo economicus, utility is measured in $, complete information" assumptions, and calculus - see sources and "Baseline" for details)

It's a matching funds tool, so individuals donate to different projects, and matching funds are drawn a matching pool, and allocated according to the equation. The matching pool can come from wherever is suitable for whatever organization is using it, so, donations from wealthy individuals, or government expenditure, or something else.

Funding quadratic with respect to the number of individuals donating, and (sort of) linear with respect to the total donations from individuals (in the sense that if all individuals doubled their donations, all else being equal, the total funding would also double). Individual donations increase a project's funding by a function with the shape of (a+sqrt(x))^2, and individuals look at how much their donations would increase funding to determine how much to donate.

It relies upon being able to distinguish between individuals. This means the implementations on blockchains have not been scaled past a few $M a year due to difficulty scaling sockpuppet resistance.

This is a decent overview of it: https://vitalik.eth.limo/general/2019/12/07/quadratic.html, but it does not explain exactly why the equation is the way it is. It has been hard to find good explanations, because in the original paper it very much reads as the result of some calculus.

If you'd like to read the original paper it's here https://www.radicalxchange.org/media/papers/liberal-radicalism.pdf. The derivation is written somewhat unintuitively. There are multiple variants, with different constraints and assumptions.

This article will contain a lot of opinion from Archipelago as to which implementations make better heuristics than others.

Variants and Implementations

All existing Quadratic Funding implementations differ some amount from the variants in the original paper. It is the opinion of the main author of this page (archipelago) that these differences are small enough that existing implementations are still useful, but may require some caution to use effectively.

Baseline

The first variant in the paper assumes all individuals ignore impact on total spending aside from their own contributions. This is, of course, a flawed assumption. All further variants are analyzed in terms of their deviation from this result, because it achieves the "most optimal way of funding" - what is meant by this is that, under these assumptions, if each individual selfishly optimizes their own utility, that actually results in the total utility of all individuals being optimized as well. No individual would receive more than one cent of value from donating one more cent, and allocating one more cent of funding to any project would not increase the total utility to everyone by more than one cent. (In math terms: the derivative of utility wrt cost is 1 in both perspectives, or, the derivative of utility - cost wrt cost is 0). Total utility could not be improved by taking funds from one project and giving it to another, but this is evident already because utility could not be improved by increasing funding to any project.

So, it serves as a decent baseline to measure more realistic implementations against, to see in what ways that "most optimal" solution is changed.

The baseline calculation is - for each project, square root each individual's donation, sum those together, and square the result, and that is how much that project receives in funding. As you can see, it has no budget, and can grow endlessly.

Budgeted

Baseline, but the portion that comes from the matching pool is scaled down by some factor α. As analyzed in the paper, it does not have a fixed budget, but α is fixed. The major difference here is that projects are "underfunded", in the sense that if there were more funds to allocate to them, it would increase total value by more than the value of those funds (remember, we're assuming utility/value can be universally measured in $).

The key detail of this variant is that it is still the case that utility could not be improved by moving funds from one project to another, i.e. it's still the "best" use of the funds given the constraints.

Unfortunately, even though the paper says "α may be adjusted to ensure the budget is not exceeded", the math is done with a fixed α, which is impractical in practice, because it's still a variable (unlimited) budget.

The author of this article (Archipelago) has in the past checked what the difference would be if the budget was fixed and α was variable, (This is the main real-world implementation, see "Budgeted in practice") and was satisfied that the difference between the two was insignficiant, but this will have to be re-checked.

See figure 1 for a visual representation of how this works, or the first overview linked in the header.

"Incorporating the deficit"

This variant modifies the baseline (note: not the budgeted variant) with an assumption that each individual values reducing the matching funds spent by some fixed linear amount.

Example: Individual A, if the matching funds amount is $10M, would value a decrease in that amount by $1000 at $61. If the matching funds amount was $100, they'd value decreasing that to 0 at $6.1 - in other words, $x in total collective spending from the matching pool is seen as -$λ*x utility to each individual, with a different λ for each individual.

This is kind of a weird assumption, it seems totally unrealistic that it would be perfectly linear like this, but it leads to a uniform underfunding result with basically the same properties as Budgeted.

Others, and Archipelago's reflection on these.

There's also a variant in the paper where you can donate to have money taken away from a project.

Because humans are actually irrational, and also any implementation in practice will have some amount of error from what's truly optimal, I'd rather constrain human irrationality to only irrational generosity, rather than irrational antagonism. It's fine to me if people donate more than is actually reasonable, but humans have plenty of desire to harm others even at cost to themselves, so I think anyone using QF should be very cautious and hesitant to include this.

Generally speaking, practical implementations will at least have the uniform underfunding feature, and would have to be slightly off from these variants even if all individuals had complete information because budgets have to be capped.

How are they actually done in practice?

Individuals don't actually have complete information, how is this dealt with? Also, what are individuals using to determine their utility?

Both in theory and in practice, the total funding to any project needs to be available to all individuals, because individuals have to look at some project's funding and go "ok, how much is it worth to me for this project to have its funding increased by a certain amount?". In addition to this, it's sometimes displayed on the interface how much a given donation will be matched by. (Example: you could see $1 be matched by $20, $5 matched by $87, $10 matched by $150, or in another situation, $1 matched by $110, $5 matched by $300, ...) So, you add dollars until the rate the matching amount increases by drops to the point where it's no longer worth it to you to donate more.

The theory version of this requires that all individuals instantaneously optimize against each others' behaviors! In practice, it's an iterative process, you look at where things are, decide if you want to change your donation amounts based on the past actions of others, and others come back and look at where things have changed since they last checked in, tweak their inputs, then you could come back and tweak based on that, etc. repeat. This is kind of like stochastic gradient descent, in the sense that a subset of a whole is polled to change some parameters, this is iterated a bunch, and then the result converges towards an optimal value. It seems quite reasonable to me that this should in practice approximate the optimal solution quite well. Due to conditions of needs, wants, values, available funds from individuals and also the collective budget, new projects, the economy as a whole, etc. changing over time, the optimal outcome would always be changing, but the approximation this makes would always continue to chase it.

Following this, there's a few more variations in implementation. The paper makes no statements on time at all - time is not even a variable in the derivations and theory at all, so there's some difference in how that's handled, and there's also two main variants on how to deal with fixed budgets.

In general, I see practical implementations as heuristic approximations for the theoretical Budgeted variant, which do seem overall good enough, though some are better.

Budgeted in practice

Only scale down matching if budget reached

Some implementations act as the Baseline case if the amount total of matching funds calculated is less than the funding pool allocates, funding as calculated, reserving the excess, and only start scaling down the matched amounts as in Budgeted once the budget is reached. Individual contributions are not touched, only the matching amounts. I consider this the best heuristic, especially in opposition to the other major alternative:

Matching funds scaled to fit budget exactly

This one works by doing:

Calculate the total payouts to all projects as if you were using Baseline, then, get the ratio of that to (funding pool + all individual contributions). Scale Baseline-calculated payouts by that ratio, then give those payouts to all projects, in addition to the individual contributions.

This is a bad way of doing budgeting, it's not a heuristic for the Budgeted variant, and misses some key points:

It can overfund, since it always uses the entire budget, allocating more than even Baseline would.

In practice, it's unlikely that an equilibrium would be less than the budget, but this is not desirable generally. Early conditions would be especially sensitive to this, especially in the continuous time implementation. If you wanted to allocate, say, $1M a week, whoever posted their project first and got just one donation would be allocated all of that until other projects and donors came in - pool funders may not like this possibility and would be pressured into scaling the pool size manually, starting off small.

When there's an alternative that just doesn't overfund, this is a bad heuristic. This is why starting with baseline allocation until you've hit the budget is ideal. Pool funders could just start things off at whatever rate they wanted to use.

Figure 1: Visual representation of QF baseline's calculation of allocation to one project, with only the yellow area scaled down in the case of Budgeted

It also is in error in adding the scaled baseline payouts to the individual contributions, because individual contributions are already included in the final allocation. See Figure 1: This is a representation of how funding for one project is calculated - it already calculates the final result, it doesn't need to have the contributions added back on.

In the proper implementation, if the matching amount is 0, the yellow area is scaled to 0, and this calculation still works. Individual contributions are basically duplicated, which strays significantly from the theory.

Discrete rounds vs continuous

Some implementations have discrete rounds, where donations are only for that specific round, and happen infrequently - Gitcoin did theirs 4 times a year, for example, with donations only being open for a few weeks, to give people time to iterate and adjust their inputs based on the inputs of others, and with significant downtime inbetween funding rounds. Once the deadline is reached, funds are sent all at once.

Some do continuous funding - i.e. you donate, say, $10/month to a project, and your individual contribution stays fixed until you change it. Funds are continuously sent to each project, and subject to change at any time.

Streaming funds seems much more likely to reach a proper equilibrium, as it is always active, and contributions are recurring. In the discrete rounds case, due to the small time windows and large gaps between them, it could very well be the case that someone wants to donate but doesn't catch the window when it's open, or does once and then doesn't catch the next one.

Discrete rounds also led to the phenomenon of people stopping the work they were doing so they could fundraise, marketing themselves and requesting people go to Gitcoin and donate to their project.

While I do strongly prefer continuous implementations, I can see the appeal of having discrete rounds. Continuous means your project's income can change at any time. Discrete rounds have uncertainty too, just at known times.

Actual implementations we can use

SQF by flowstate.network is as far as I can tell the only remaining implementation that lets groups spin up their own QF systems. It uses continuous streaming of funds, and does the "Matching funds scaled to fit budget exactly" budget variant. As a result, it is imperfect, and we will need to either get them to fix it or do our own implementation eventually. I expect it to still be okay at small scales, but it is unfit for use at medium or large scales.

An article about how to actually use the interface needs to be written, as it seemed unintuitive to some.