[Formal Review 
] Radicle Grants Program - Continuation
Note: this proposal is largely based on the original Grants proposal that passed, which you can find here. The main amendments can be found at the bottom in the Open Questions section and focus on optimistic funding and scheduling/workflow.
Proposal Champions 
@bordumb | bordumb#6773
Functional Description
This is a proposal to continue the existing Grants Program with some amendments.
This is the first time we are extending or amending an existing proposal.
The Grants Program has already passed a temperature check, so an additional temperature check is not required.
The next step in governance - as outline here - is a formal discussion.
The intention of this post is to start that formal discussion.
Note: In terms of general philosophy and mission statement for Grants, please refer to the existing main README in our repository here.
Budget & Timeline
Amount
- 743,575.46 USDC for grants
- 199,994.52144606 DAI for grants
- 29,232.19987693 RAD for committee compensation
Length
Optimistic Funding / Schedule
So long as there is budget left, the RGP shall be considered “alive.” So assuming that funds exist, the RGP should be considered indefinitely active.
There are 2 ways for the RGP to turnover or “stop”:
- Funds run out and a subsequent proposal is not approved by token holders.
- There is a vote of no confidence from token holders.
Seasons
- There will be “seasons,” which will last 4 months each.
- At the end of every season, the RGP committee shall provide a retrospective write-up and a community call to take feedback from grantees, community members, and anyone else who joins.
- In the event that funds run out in the middle of a season, the RGP committee shall create a new proposal for funding. Ideally, this shall be forecasted and planned for ahead of funds running out.
Implementation
Grants will, as much as possible, be run through Radicle products, including Workstreams for grant applications and Drips for payments.
If/when Radicle products fall short, we will fall back on Discourse for managing grants and the Multi-Sig for payments.
Team & Responsibilities
RGP Committee
The group outlined below will act as the RGP committee and will be the signers of the RGP Org’s multi-sig. These committee members will be responsible for approving grants and distributing funding to grant projects.
The Radicle Grants Committee is made up of core Radicle team members, Radicle community members, and outside individuals who have related domain expertise within the Web3 ecosystem.
Committed members include:
- Grants Lead: Bordumb (Radicle Community)
- Abbey Titcomb (Core Team)
- Kei Kreutler (Ecosystem)
- Nader Dabit (Ecosystem)
- Nassar Hayat (Core Team)
- Reverie (comprised of Derek Hsue and Larry Sukernik from the Radicle Community)
Compensation
Compensation for Committee Members will continue the exact same model we had in the previous proposal outlined here.
Core Development Team
This section is independent of whether a Core Team member is on the Committee.
Any technical work (i.e. code) will be posted to the respective Project/repo. For example, if a grant project touches Radicle CLI, the work will need to be posted to either the Radicle or GitHub repo. It will be up to any maintainer(s) of the respective repo to review, give feedback, and ultimately approve the work.
Once the work is completed and approved, the grantee can share the Project ID + anchored commit hash as proof of work to the Grant Committee for final payment.
The Core Development Team may at any time join the process to give feedback or guidance on any application.
Program Structure & Process
Grant Ideas
Grant ideas can come directly from the community or as RFPs from core members or Radicle users.
Grant Scope
Applications will be reviewed on a rolling basis.
- Seed Grants
- Target: individuals or small teams/start-ups
- Budget: < $50,000
- Requirements: 20% of multi-sig approval; remaining members can rubber stamp
- Time commitment from Committee members: assessment of work, voting pre/post
- Tree Grants
- Target: small teams/start-ups
- Budget: > $50,000
- Time commitment from Committee members: assessment of work, 1-2 interviews, voting pre/post
Application Process
Whether technical or non-technical, grantees may apply via the following channels, following the application template:
- Discourse
- Radicle Workstreams: we will work with select applicants to help beta testing of Workstreams for Grants.
Milestones
Clear, concise, and manageable milestones must be included in every application.
The purpose of milestones is to:
- Break projects down into functional components.
- Mitigate the risk of projects not being 100% complete. If 1 usable component is done and 2 are not, we can restart from square 2, rather than square 1.
- Organize the work into chunks that are more manageable for grantees and anyone reviewing the work.
Note: Whether a grant is part of an RFP from the commununity or directly from an applicant, milestones should follow the application template
Grant Approval
The Grant Lead is to communicate Multi-Sig voting due dates and any required secondary assessments, such as interviews.
As noted above, this will occur on every 2nd Friday for Tier 1 grants. For Tier 2/3 grants, this may be on either the 3rd or 4th Friday, subject to Committee Member availability.
In leu of synchronous interviews, Committee Members may assess applicants asynchronously by providing written questions for the applicant(s) to respond to. This must be done in a timely manner (i.e. several days prior to when the final assessment takes place).
Project Support
The Grant Lead will directly or indirectly (through other Committee Members) provide grantees with the following:
- Feedback before/during the application process
- Funding
- Feedback on delivered milestones
Outside of these 3 Fs, the RGP will not be a hands-on assistance or mentorship program. We are expecting individuals and teams who are planning to own the work from start to finish.
In cases where there is close integration with the product, Grantees should expect interaction and can get details clarified and pointers via our community channels (Discord, Matrix, etc.).
Posting Work
Technical Work
If a grant project is technical in nature, the delivery should include a link to the open-sourced code, whether it’s on Radicle or GitHub.
If a grant touches a Core Dev team’s repo, the merged commit will act as the approval of the work.
Non-Technical Work
Any non-technical (i.e. non-code) work can be shared in any manner that makes sense.
For example, if the work is to write a blog post, simply sharing a link to the content and a text file will suffice. If it is a video tutorial, a link to the video and a file of the video will work.
The details for posting non-technical work will be on a case-by-case basis.
Note:
All work must adhere to the following criteria:
- All code produced during your grant must be open-sourced with proper licensing (Apache 2.0, GPLv3, MIT or Unlicense).
- All code must not rely on closed-sourced software or infrastructure to be fully functioning.
Work Approval
There are 3 possible approvals:
- Initial grant approval
- Technical approval
- Non-technical approval
Initial Approval
The initial approval is the 20% funding that marks a grant as “approved” and gets it off the ground with initial funding.
2 groups may weigh in:
- RGP Committee
- Core Dev Team
In the case that an application’s technical details are beyond any RGP committee members, the committee shall reach out to relevant Core Dev members and ask for input within a week of application. If an application is marked for Core Dev input, no vote shall be started until input has been received. There will be either a $500 (USDC) bonus given to any Core Dev members who provide detailed input, regardless of grant approval.
Technical Approval
2 groups may weigh in:
- RGP Committee
- Core Dev Team
Any technical work that includes code should include unit tests and must have integration tests (i.e. it’s gotta actually work!).
Technical approval may include an assessment by relevant Core Dev Team member(s).
For example, if a grant project touches Radicle CLI, the work will need to be posted as a patch to the Radicle repo or as a pull request in the GitHub repo.
The maintainer(s) of the respective repo (likely Core Dev Team) will review, give feedback, and ultimately approve the work to be merged.
The RGP Committee will use this approval as the “proof of work” to disburse final funds from the multi-sig (see Payment below).
Non-Technical Approval
Technical approval will include an assessment by relevant Core Dev Team member(s).
Payment
Schedule: when a grantees application is approved 20% of the grant will be disbursed upfront to provide immediate funding to grantees. Once
the work is complete (i.e. gone through Approvals as noted above), the remaining 80% will be disbursed.
Process for Final Payment:
- Technical work: grantees must provide the Project ID + anchored commit showing the work has been approved by a Core Dev Team maintainer. RGP Committee will then disburse funds via the multi-sig.
- Non-technical work: grantees must share the finalized work, which will then be assessed by the RGP Committee, and funds will be disbursed via the multi-sig.
Communications
Communications will be key and made fairly uniform and consistent. The major steps where communications will be made are:
1. Grant Applications
No communications by us.
2. Grant Approvals and Rejections
Scheduling
- Seed Grants: rejection or approval within 1 week of application
- Tree Grants: rejection or approval within 2 weeks of application, pending any back-and-forth (additional documents, calls, etc.)
Upon rejection:
We will provide a concise note that the grant was rejected and why.
If there are a chance to continue forward, constructive feedback will be given.
If there is no alignment or chance to move forward, this will be made clear.
Upon approval:
We will provide a concise note that includes the following:
- Note of approval
- Link to Multi-sig transaction
- The Nonce # related to the funding transaction
- Standard note on compliance:
All compliance - including taxes - are the responsibility of the recipient
Note: The single source of truth for grant approvals and rejections will be the Grant’s Multi-Sig.
3. Grant Completion
- Completion of individual grant projects (per grant)
- Twitter + other social (celebrate!)
- Will be inherently public due to on-chain Multi-Sig votes
Purpose / KPIs
We are continuing with the high-level goals set out in the original proposal here, including:
- Progressive decentralization
- Product Growth
- Model for other sub-DAOs
In addition to this, over the next 6 months, we want to push forward a few very specific goals, including:
1. DAO Partnerships
3rd Party Tooling/Integrations
- We want to cultivate an expertise around 3rd party integrations in the developer tooling space.
- We already have several promising projects in the pipeline (e.g. JetBrains IDE plug-in, VisualCode IDE plug-in, Arweave and/or Filecoin integration for hosting binaries), so we’d like to continue funding the development of these and other similar projects.
Recruiting Funnels
- We’d like to partner with upcoming sub-DAOs like the Cohort Programme (naming TBD) lead by Ruth D.
- The plan here is to support a rigorous funnel of mentorship within the Radicle ecosystem and team with them on onboarding cohorts of contributors to Radicle Grants.
- KPI(s):
- Top of funnel: 2x the number of applications. We had ~30 applications in 6 months (5 per month). With 4 month seasons, this means getting 10 per month, or 40 in total.
- Bottom of funnel: 1.5x the number of grants funded. We had 8 grants approved in 6 months (~1.3 per month). With 4 month seasons, this means getting 2 per month, or 8 in total.
Note: We landed on 2x vs 1.5x between the top and bottom of the funnel as increasing the top-end tends to bring in lower quality participants. So we’d like to manage expectations that approvals are unlikely to grow at the same rate.
Badges + Distribution of Influence
- We funded OtterSpace’s grant to create soul-bound (i.e. non-transferrable NFTs)
- In Wave 2, we will assign badges to Committee Members and Grantees and experiment with badges for various governance decisions.
- KPI(s):
- Mint Raft token for RGP multi-sig.
- Create 1 badge for RGP committee members.
- Create 1 badge for grantees, which will be sent upon grant approval.
Dripping to Dependencies & Retroactive Funding
- We have prepared a list of key Grants dependencies here.
- We will work with these dependencies to get them set up with Drips (especially Splits) and create a network of giving through the Grants Program.
- KPI(s):
- See the list of key Grants dependencies here. We want to set 100% of them up for Drips. Drip $10,000 ($40,000 in total, or ~4% of budget) to each dependency.
- Write blog post about retroactive funding of FOSS, teaming up with Marketing team on this.
Retroactive Funding
- Create an explicit charter for retroactive funding.
- KPI(s):
- Allocate $50,000 (~5% of budget) as an easy-access fund for retroactive funding. By easy-access, this means that there is no application process and the amounts can be used to fund simple “thank you” notes, such as <$1,000 for blog posts, tutorials, documentation, or other small or large work. Use 100% of this fund.
2. Dogfooding
Another goal in the background is to make sure that we push Radicle products to their limit to manage our work and the work of Grantees.
Applications
- Manage applications through Workstreams.
- KPI(s):
- Get 10% of applications (~4) to accept payment via Workstreams, creating a feedback cycle with the Drips team. Create a bonus program for those that participate (5% bonus, applied at final approval/funding of completed work).
Grantees
- Get them using CLI, Patches, etc. for code management and collaboration
- Get grantees - especially larger groups - using Drips to drip to their members and/or dependencies.
- KPI(s):
- Get 10% of applications (~4) to user Drips to drip to dependencies, creating a feedback cycle with the Drips team. Create a bonus program for those that participate (5% bonus, applied at final approval/funding of completed work).
Note: Grantees will not be required to use Radicle products, but we will provide incentives (e.g. % bonuses on top of grants) to get their work on the network. These bonuses will be appended to the final payment.
Grant Committee
- Manage grant applications and payments using Workstreams.
- KPI(s):
- Manage 10% of applications (~4) through Workstreams, creating a feedback cycle with the Drips team. Create a bonus program for those that participate (5% bonus, applied at final approval/funding of completed work).
Background
The Radicle Grants Program was the first sub-DAO to spin off from the foundation.
We would like to continue this process of progressive decentralization by continuing to onboard and fund more contributors to our ecosystem.
Link to Temperature Check
Reasoning & analysis
Pros
- The pros largely follow the Purpose section above
- Progressive decentralization: almost by definition, a grants program decentralizes governance and contribution of the ecosystem
- Team growth: the RGP can become a powerful channel for attracting community contributors as well as new core members
- Product growth: the RGP will bring in more contributions to development of Radicle’s core product as well as 3rd party integrations
- Feature ideation: the RGP can be a hub for users and contributors to meet where people can share best practices, product requests, and anything else that helps the ecosystem
- Model for DAOs: the RGP will be a model — both from a process and technological point of view — for other DAOs to adopt
Cons
- There is a risk of projects not working out as expected
Technical implementation
Treasury Funding
- Amount: 1,000,000 USDC
- Period: Indefinite or until funds run out (i.e. Optimistic Funding)
- Reasoning: In Wave 1 of Grants, we had over 1,000,000 USDC worth of applications (see table here). Given the pipeline of grants and possibility of similar volume of applicants, we want to be prepared to fund around 1,000,000 USDC worth of work.
Impact
(Note: largely covered above in the Purpose section, so summarized below)
- Progressive decentralization: self-sustaining (community funded/community built) growth from community contributors
- Team Growth: will become a pipeline for recruiting new core members
- DAO model: will provide a model for others DAOs to be self-sustaining, both from a process standpoint as well as technological
Please formally review the proposal and vote in the Snapshot poll by
11:00pm CET - October 16
Snapshot Poll Result 
See final results