This is a future proposal for consideration once the clrfund foundation has been established.
tl;dr
Child clrfund instances nested within parent instances will create the conditions for an emergent hierarchy of recipient categories and allow the ecosystem to flexibly allocate funds towards both problems and solutions to problems.
Motivation
1. Information asymmetry
Quadratic Funding’s core strength is the ability to convert community preferences into funding allocation decisions. QF is better at this than a centralized decision-maker can be because, by eliciting input from (up to) all members of the community, it can take their preferences directly into account. However, for QF to work as designed, the members of the community need to be able to map their preferences to the available recipients of the funding round.
The better the information available to a given community member, the better they will be able to map their preferences to the appropriate options. In other words, in QF, a person who knows a lot about the eligible public goods projects and how those projects benefit them is more likely to contribute to the projects that provide them the most value.
Information is never perfect; that’s ok. What is not ok is when there are asymmetries and other structural differences in the availability of information. These issues create problems even in traditional markets, and QF only exacerbates them. For example, when a certain project that has wide-spread benefits are known only by a few, QF matching for that project will be sub-optimal compared to when those benefits are known by many, even when the total pre-match funding amount is the same.
Similarly, projects like blogs, twitter accounts, and other media – where the mechanism for providing value provided to members of the community is the same as the mechanism for communicating with those members – have a structural advantage over other projects. Since a blog can embed a call for QF contributions within their content its entire readership will be aware of the campaign, while an application that works for its users without regular use will have to fight hard to inform its users of their funding campaign. So even if the blog and the application create the same amount of value for the same amount of value, contributions to the blog will be amplified more by the QF mechanism.
2. The problem with solutions
Another aspect of the recipient-to-preference mapping problem is that evaluating solutions for their effectiveness at solving your problems is hard, and dreaming up real solutions in the first place is even harder. This is true for experts and even more so for non-experts, and it happens to be the case that most people are non-experts in most things.
It turns out that it’s a lot easier to figure out what your problem is than it is to know what or how to solve it. While detailed and actionable problem-definition is a skill of its own and requires subject matter expertise, a more broad labeling of a general problem does not. For example, it is quite difficult for a typical Ethereum user to evaluate the potential benefits of EIP-1559, but it’s quite easy for them to be able to say that they’d prefer cheaper and more predictable transaction costs.
3. Categorizer legitimacy
One way to address structural differences between different types of projects – as in the blog vs. app example above – is to create separate matching pools so that those different projects aren’t competing for the same matching funds.
This is exactly the approach that Gitcoin has taken with Tech vs. Community, and it is 100% the right call.
But who decides which categories get their own matching pools, and, more importantly, who decides on the size of each matching pool? Any categories and separate matching pools established by a centralized decision-maker like Gitcoin will struggle for legitimacy. More importantly, the allocation of funds across matching pools – just like traditional grants funding by single decision-makers – will be non-optimal for the community.
A Tree of Matching Pools
Imagine the first clrfund round. Now imagine that anybody can register a category as a recipient just like they would a regular public goods project. That category could be anything – ETH2, Developer Tooling, User Research, Transaction Costs, DeFi, Journalism, etc. Contributors can contribute to one of these category recipients just as they would a typical project recipient, and those contributions are quadratically matched just like project recipient contributions.
Category (or “domain”) recipients are exactly like project recipients, except for one thing: while all funds allocated to a project recipient go directly to that project, funds allocated to a category recipient go into a matching pool of a child instance of clrfund dedicated to that category. Public goods projects related to that category can then register and receive contributions within the child instance. Sub-categories can also be registered!
Example
Let’s take ETH2 as an example category. Say the root clrfund instance has $100k in total funds (matching pool + contributions) and the ETH2 category pulls in 25%. That $25k now goes into the matching pool for the ETH2 clrfund instance. Now, within the ETH2 category, we expect all the ETH2 clients to register as recipients. But what about phases of ETH2 that don’t currently have project teams dedicated to them? To fund those R&D efforts, subcategories for each phase – Phase 0, Phase 1, Phase 2 – could be created. And any time a new research problem is discovered and needs funding, a sub-sub-category could be created underneath one of those sub-categories.
Benefits
1. Reduce the impact of information asymmetry by enabling the community to make explicit decisions about the relative importance of different categories or domains of public goods.
2. Dampen the outsized amplification of projects with a structural fundraising campaign advantage (e.g. media projects with built-in connections to their users) by separating the matching pools for those projects.
3. Allow the community to amplify funding categories of projects that create value for a much larger number of people than those who are aware of them (e.g. developer tooling and libraries) by funding the category as a whole.
4. Enable the community to allocate funds towards problems even if specific proposals for solutions do not yet exist. Clrfund can act as a form of prize-driven innovation, facilitating a decentralized form of RFPs. This will help surface more problems in need of solutions as well as make it easier for individuals to contribute even if they don’t know what specific projects best meet their needs or preferences.
5. Emergent categorization, resolving the issue of category legitimacy.
Miscellaneous thoughts
- Proper categorization can be enforced by allowing individuals to make negative contributions to projects they deem to be registered under the wrong category
- Child instances of clrfund can be free to manage different aspects of their implementation (e.g. coordinator power, recipient curation, etc.) however they’d like. These instances can compete with each other to find the approaches that work best for the community.