Funding Categories
This is a page outlining 4 categories of grants and deeper thoughts on each of them.
This includes the how we categorize them, rationale for funding them, and current funding processes.
The current grants landscape looks something like this:
Excluding the dependencies, a more detailed look would be like this:
1. Dependencies
This covers protocols that the Grants Program depends on (e.g. Snapshot, Gnosis, etc.).
Funding
Rationale
- We could not run grants without these protocols, so we should pay back to them.
Process
- As outlined in the 2nd grants proposal, we will allocate 10% of our budget and stream funds once V2 Drips is launched.
2. Core Infrastructure
a. Core Product
Projects that add directly to our Core Developer team’s code base, improving the core products (example here).
Funding
Rationale
- These projects take something the Core Dev team would like to work on, but simply don’t have bandwidth to get to. So these projects make sense to fund in that they expand our core capabilities.
Process
- Direct through multi-sig voting
- Direct feedback and support from Grant Committee and Core Dev team
See page below to start an application:
b. 3rd Party Integrations and R&D
Projects that research and/or build 3rd party integrations that extend the core product (Integration example here and R&D example here).
Or grants that research topics to help improve Grants processes or infrastructure (example here).
Funding
Rationale
- These projects take something the Core Dev team would like to work on, but simply don’t have bandwidth to get to. So these projects make sense to fund in that they expand our core capabilities. They also broaden the reach of Radicle by integrating with things like popular IDEs (e.g. JetBrains) and other web3 tooling (e.g. FileCoin, Arweave), which makes it that much easier for potential users to add Radicle to their workflows. This is especially important for user acquisition.
Process
- Direct through multi-sig voting
- Direct feedback and support from Grant Committee and Core Dev team
See page below to start an application:
3. Use Case
These are projects that take some Radicle component and adopt it in a specific use-case.
Examples include using Drips to create a crowd-funding platform (link here) or using Code Collaboration to organize peer review of research (link here).
Funding
Rationale
- Straw-man Argument: to play devil’s advocate, it makes zero sense to fund such projects. We have spent our resources to build out the Radicle ecosystem. So teams using Radicle are essentially our “customers” and should be paying us. From a financial point of view, it does not create a circular loop, but rather creates a hole in our sink, whereby we are pouring money into our sink to developer Radicle, but also spilling water out to people using what we’ve built.
- Steel-man Argument: these projects are important adoption use-cases that should (a) increase usage and visibility of Radicle and (b) prove out the viability of using Radicle for code collaboration or streaming funds. So it makes sense from a product marketing perspective.
Process
- We currently don’t have a process
4. Web3 & FOSS
This is a catch-all for projects that involve some sort of Web3 technology.
Example here for a grant building “web3 email” or this “decentralized YouTube” grant.
The important distinction is that these grants are not directly tied to Radicle. They do not explicitly add to the core product, extend any features, or integrate with one of our tools.
Funding
Rationale
- Straw-man Argument: some of these are vague, untested, and simply are too unrelated to Radicle to make much sense for us to fund. We also don’t have bandwidth or domain expertise to advise on such work.
- Steel-man Argument: some of these could turn out to be revolutionary, even if not directly related to Radicle’s ecosystem. We should be supportive of such work, especially when it adds something amazing to web3 and FOSS.
Process
- We currently don’t have a process