Grants 1.0 flywheel
I think that Gitcoin Grants is a triple sided marketplace.
- We enable Community/Ecosystem builders to get their JTBD (Build their ecosystem/community) done.
- The way we do that is we enable Grant Owners to get their JTBD (raise $$$) done.
- The way we do that is we enable Contributors to get their JTBD (find great projects, support them) done.
This is a virtous flywheel here where each side of the market contributes to the network effect of the entire market.
Said another way:
- More contributions creates more grants creates more ecosystems => (repeat)
- More ecosystems creates more grants creates more contributions => (repeat)
Because each marginal new user creates more value for each grant owner, and visa versa, the network is subject to power law growth in it’s utility. This law of network value is called Metcalfe’s law:
It gets better. We can build this triple sided market by choosing the leverage point on any of the 3 sides of the marketplace.
- Focus on getting more ecosystems (via sales)
- Focus on getting more grants (via marketing)
- Focus on getting more contributions (via marketing).
This triple sided marketplace (and Metcalfe’s law) is how Gitcoin has grown to help 78,070 funders reach an audience of 318,218 earners. Gitcoin has facilitated 2,069,421 complete transactions to 10,457 unique earners.
Grants 2.0 flywheel
I think that Grants 2.0 builds on the momentum of Grants 1.0 in a really important way.
In the second half of this post I aim to articualte how.
Grants 1.0 was a monolithic app, but Grants 2.0 will be made up of a suite of modular money legos that are all interoperable with each other (and replacable)
- At the base of the system is a deeply liquid grants registry (which in the spirit of Practical Pluralism, is interoperable with other grants programs).
- Built on that is an ecosystem of mechanisms that all help create more contributions on the platform.
- In Grants 1.0, we leveraged Pairwise QF and were stuck with it because of the monolithic architecture. But in Grants 2.0, we could build many pluralistic mechanisms (MACI QF, DeSoc QF, Retroactive Public Goods Funding, Dominance Assurance Contracts, etc) on top, or integrate other mechanisms (like Optimism’s RetroPGF or CLRFunds Maci QF).
- This allows for more modular choice among ecosystems about how they want to coordinate their ecosystem.
- It also allows mechanism designers to quickly traverse the design space of possible mechanisms to get real emperical feedback & data.
- We can supercharge this ecosystem by adding Governance to any part of the system that needs it.
- For example, the DAO could build useful components that (1) offer Mutual Grants to Grant owners, (2) enhance the sybil resistence of the system, (3) help curate Grants, (4) set the round rules.
I really cant emphasize enough how much this modular & composable architecture matters to building on the EVM.
What is really exciting to me is how this modular architecture enhances the existing Grants 1.0 flywheel.
In Grants 2.0, we can enhance the Grants 1.0 flywheel by giving our ecosystem participants more leverage points to create network effects. The levers that become available to them in Grants 2.0:
- Building more better mechanisms into the platform.
- Building more registry integrations into the platform.
- Building more governance utility into the platform.
It is important to note that this modular open source architecture presupposes that each module will have good documentation + there will be a solid developer relations campaign to build out this ecosystem . Having these things will create a thriving developer ecosystem + marketplace of mechanisms to fund these grants. (We could jumpstart this with Gitcoin Hackathons + Moonshot Collective)
By creating this thriving ecosystem of modules, we can speed run the search space of possible coordination mechanisms, which speeds our ability to reach our shared mission.
If you think of Gitcoin as being on search for better coordination mechanisms that help us meet our purpose (help communities build & fund their shared needs), then you can visualize the search as follows:
We are in a hill climbing problem where the heuristic (how high or low each point in the hill climbing problem is), is defined by the heuristic of “how much does it help communities meet their shared needs”.
Within this hill climbing problem, we are looking for the global maxima. The mechanism that helps us find the global maximum utility this heuristic (again, the heuristic is “how much does it help communities meet their shared needs?”)
We can speedrun the traversal of that mechanism design space by creating a thriving ecosystem of developers who are building different flavors of QF in parallel with each other.
By creating & designing new modular plugins that do a better job of coordinating ecosystems + deploying them to our ecosystem partners, we find the ultimate coordination mechanisms for helping communities build & fund their shared needs.
Here is the same diagram, but laid out with multiple mechanisms (many of which are on our roadmap) on it.
Feedback welcome.
