Grants Round 12 continues Gitcoin’s trend of innovating on the Quadratic Funding Mechanism originally proposed by Glen Weyl, Vitalik Buterin, and Zoe Hitzeg. This round we are running an experiment: we’re testing out mechanisms in ways we’ve never tried before to better understand how to best implement Quadratic Funding at higher scales + higher levels of legitimacy.
Capping a grant’s maximum matching amount is part of this experiment.
6 days into GR12, we realized that the matching cap outlined in the governance proposal was not operating as intended. We have since made a change to fix that.
This post is intended to provide detail on the matching cap implemented in Grants Round 12 – why it exists, how it works, and what grantees should be aware of as it pertains to the change we have made.
The audience of this post is
Within GR12, we have three types of rounds: our main round (which historically is broken out into categories), six ecosystem rounds, and three thematic/cause rounds. Details on the different rounds can be found in the GR12 announcement post. The main round & the cause rounds are affected by this change, while ecosystem rounds are not. For simplicity, the discussion below is framed around the main round, which is where the majority of grants lie.
Prior to GR12, Gitcoin would typically run the main round with category pools to allocate specific percentages of funds across different categories (e.g., Infrastructure, Community). The proposal for GR12 deviated from this norm.
Within the governance proposal for GR12, the idea was proposed to test Vitalik’s theory that Quadratic Funding across one single main round pool should be as effective at allocating funds via category pools. The idea to run this experiment was approved by the community and brought into existence via a Snapshot vote; more details on the experiment can be found in the governance proposal itself.
This cap was implemented as part of GR12, but the implementation did not match the intent outlined in the proposal. This next sections will break down:
(1) The intent of the cap
(2) How implementation deviated from intent
(3) The impact of the fix
(4) What this means for grant owners
As mentioned above, the governance proposal stated that no individual grant’s matching amount would exceed 2.5% of the overall matching round fund (i.e., $25K for the $1M round).
This cap was proposed with the intent of preventing any one grant from running away with a disproportionate amount of the matching funds in this uncharted territory.
As can be discerned from the wording, the idea was that throughout the round, any grant could earn matching funds up to a maximum of $25,000, and would then be capped off from receiving more matching funds – so, the maximum funds any one project could be paid out at the end of the round would be $25,000.
There are two components to the matching cap calculation: normalization, and application of the cap itself.
The issue was that the initial implementation logic did them in this order:
Whereas the intended logic was to do them in this order:
What is “application of the cap”?
The application of the cap is, simply, cutting off a grant’s matching amount at a specific level. For example, if a grant was eligible for $40,000 of matching funds and we had a $25,000 cap, the application of the cap is skimming that $40,000 number to $25,000 across the board for any grants whose eligible calculation had them at >$25,000.
What is “normalization”?
The GR12 main round matching pool is $1M. As a result, we need to force-fit the total matching amounts so that the sum of the matching funds for all the grants in the main round does not exceed $1M – otherwise, we would be paying out more funds than we have. We call this ‘normalization’. Normalization only kicks in once a round is ‘saturated’ (when estimated matching dollars exceed the actual matching dollars available).
Why does the order matter?
Doing these in one order vs. the other has significant implications, as we have now learned.
When we were applying the cap before normalizing, we were effectively reducing the $25,000 cap, because we’d cap the grants off at $25,000 – and then scale down the entire summation of the calculated matching funds to fit into the $1M round.
To get specific, based on GR12 results as of Dec 5, we had:
The effective cap was a result of the $3.3M getting ‘squeezed’ down to $1M via normalization – so $25K grants got ‘squeezed’ down to $7K (note that $7K / $25K is roughly equal to $1M / $3.3M).
In the graphic below, you can see the effective cap and its trajectory over time since GR12 start:
What the above shows is that, by December 6th, we had a number of grants getting artificially capped at about $7K when they should really have been eligible for the full $25,000 match.
To fix this and honour the intent of the original governance proposal that was voted on by the community, we are switching the order and will now, estimates of matching funds on the Gitcoin.co site will be normalizing and thenapplying the cap.
We are glad to make this fix so that the grants who are eligible for their full $25,000 match in the main round are indeed able to receive that match amount. As of Dec 7, there are 22 grantees in GR12 who fall into that category – i.e., they will hit the $25K match – and 41 grantees in total who are positively impacted by this change (i.e., their matching amounts go up).
Unfortunately, this fix is a zero-sum game – the round is still the same size – so, it does come with corresponding decreases in matching amounts for other grants.
That said, the impact is mitigated by the fact that for all grants that earn more than the cap after the normalization is complete, the excess funds are re-distributed proportionally across grants that haven’t been capped yet.
In terms of overall impact, there are 525 grantees whose matching amounts will decrease as a result of this change:
As can be discerned from the numbers above, the implementation meant that the formula was being overly democratic. We had 130 grants hitting the $7K cap, and now, with the $25K cap, we will only have 22 grants hitting the cap.
While Quadratic Funding is intended to be a mechanism that puts the power in the hands of the people, this implementation meant that popular grants who were generating substantial funding from their communities were not getting the matching amounts they were entitled to.
In the chart below, this phenomenon can be seen based on the grants on the left-hand side whose match amounts are increasing substantially with the fix.
Grant owners may notice that their matching amount has changed, either positively or negatively.
Notably, any grant owners who previously thought they had hit the cap – but now haven’t as a result of this change – may want to communicate to their communities that their grant continues to be eligible for matching funds, up to the cap of $25,000. Even grants that have hit the $25,000 cap may not want to discourage additional donations, as they could drop back below the cap due to normalization as donations to other grants continue.
It is worth noting that, for grant owners who are negatively impacted, their resulting matching amount will still be higher than it would be if we didn’t have a cap in the first place. To that end, we still feel good about the intent of having a cap within GR12.
Finally, grant owners should remember that the matching amounts displayed throughout the round on each grant page are estimates, and matching amounts are not final until the round is ratified.
We are glad to have caught this and to be learning with our experimentation, but we recognize this learning is coming at the cost of many users’ funding experience, which we did not anticipate.
We hear you.
In the meantime, you can always reach out to the Gitcoin Core team with any questions, provide feedback to governance at https://gov.gitcoin.co/ or feedback on the Gitcoin Discord.