Editing Quadratic Funding (section)

=== 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.
[[File:Quadratic funding per-project allocation diagram.png|thumb|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.