[Discussion 🌱] Radicle Grants Program - Continuation

[bordumb]

[Discussion ] 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.

Note: See Open Questions section at bottom for more details on scheduling and optimistic funding.

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:

1. Initial grant approval
2. Technical approval
3. 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

[Temperature Check] Radicle Grants Program

Thanks for the awesome feedback everyone. We plan to discuss the Radicle Grants Program in more detail on the Radicle Governance Working Group call tomorrow. If the feedback is positive, we’ll close the temperature check and move on to the next step of the process, a structured discussion. Before we start the structured discussion, however, we’ll likely need to find a lead for the grants program. We’ll be posting more on that role in the forums soon!

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 TBD:00 CET - TBDday, September TBD

[yorgos]

DISCLAIMER IN BIG FAT BOLD LETTERS: Grantee speaking (me), so there’s an obvious conflict of interest here, probably applicable to anything I say on this thread.

@bordumb

There are 2 possible workflows here:

1. We keep remaining funds (~1,000,000 USDC) in the Grant’s multi-sig. We then create an off-chain Snapshot vote to approve this Grants Proposal. If approved, Wave 2 starts.
2. We send remaining funds (~1,000,000 USDC) from the Grant’s multi-sig back to the Treasury. We then create an on-chain vote to send 1,000,000 USDC back to the Grant’s multi-sig. If approved, Wave 2 starts.

Workflow 1 will have much less overhead, however will be off-chain.
Workflow 2 will have more overhead in that involved sending funds back and forth between the multi-sig and Treasury. However, the process is more rigorous and on-chain.

I am wondering:
is there any on-chain record that funds must be returned ? Is that embedded in some smart contract or some on-chain vote ? If it is a vote, does the vote carry the full text of the proposal, or just a link to some off-chain document?

• It sounds like if there is, then this should all be settled on-chain (whether with a vote reverting the text, or fund transfers).
• If, on the other hand, the understanding that unused funds will be returned only existed off-chain (e.g. in a discourse post, etc.) it sounds like “optimistic funding” could already apply to wave 1 ?

[bordumb]

Thanks for reading this in detail @yorgos

There is no on-chain record or mechanism for automatically returning the funds.

The idea of returning the funds was written in the original charter for Wave 1, and meant to be done manually.

So I wanted to call this out (manual return of funds) while also mentioning that there may be a more efficient way to move into Wave 2 (off-chain vote to keep funds in multi-sig).

[yorgos]

In that case, it also sounds to me like workflow 1 offers the least friction / bureaucracy.

From the grantee point of view, we are obviously looking for as little disruption to service as possible: putting a team together to work on a project in less-than-full-time capacity has been considerably more challenging than expected (finding devs is hard enough these days - finding devs who care about decentralization is even more so)…

It feels like a month or two of “delay” could pose a serious risk to our team that’s been working on the IDE plugins, especially at a point in time when we just finished our first iteration and were starting to pick up momentum…

[shelb_ee]

I support keeping the optimistic voting model in this case for the following reasons:

• @bordumb has proven to be a responsible and reliable Grants lead and I have full faith in him continuing this work going forward. The RGP committee has also been able to successfully work together during the first wave.
• Sending funding back to the treasury and have to restart this process risks causing delays in functionality of the Grants program for current and upcoming grant applications. Such an interruption feels unnecessary considering how well the Grants program has been running in wave 1.
• This ensure future efficiency and reliability for grantees. I think it would be good to keep doing wave-to-wave check-ins to make sure everything is still running smoothly, but to keep the funding availability in the multi-sig seems to be the most practical option for all parties going forward.

[maddybergen]

The cohort team (Me, Ruth, and Jesper) also support continuing the grants programme as it aligns very closely with the mission of the cohort programme. We aim to work closely together to ensure we support projects that bring the most value to the Radicle ecosystem and hope that some cohort projects are awarded grants.

[abbey]

Sorry for the significant delay in review! Hopefully we can get this moving through governance now. @bordumb, very excited to see the Grants program continue into this next season. Sharing some thoughts/feedback here:

• All for optimistic funding Only caveat I would add is that I think you should maintain the concept of cycles, seasons, or rounds. Reasoning here is that it will give the RGP time to reflect and iterate, while creating space for community feedback. How do you envision these cycles working?

• How can we better involve Core Development team members in the grant application process? I feel like we had 1-2 grants that got make or break feedback from Core Team members pretty late in the application process (one was at the final Safe vote iirc). I’d like to ensure that we’re involving Core Team members as early as appropriate to ensure that grantees are able to process & manage feedback accordingly — how do you suggest we do that in Season 2?

• Do we want to set any KPIs or goals with regards to amount of funding distributed or grant applications received? I’d say that having 8 quality applications funded was a great success for Season 1, but how or do we want to scale the program up and if so, by how much?

• When do we realistically think that Workstreams will be in a place to use for funding Grants?

• I love the Retroactive Funding objective from Wave 1 Learnings + Future Plans! How can we expand on this further? Can we create space for retroactively rewarding contributions to Radicle?

• I think we should ensure the application timeline is more clearly communicated to grantees. Seems like some grantees were confused about when to receive a response. On that note, do you think you have enough capacity to manage all grant in-flow while keeping to the application timelines? We should think about what additional personnel (or process) should be added to the team to ensure that applications are being processed and the committee is being engaged in a timely fashion.

@bordumb

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.

• My instinct is that communication during the application process is beneficial to keep grantees in the loop. Also, I’m not sure if we can expect grantees to be watching the multisig at all times. Perhaps we can develop a better communication process here? I’d be interested to know what @shelb_ee thinks.

@bordumb

1. Grant Applications

No communications by us.

2. Grant Approvals and Rejections

The single source of truth for grant approvals and rejections will be the Grant’s Multi-Sig.

We will endeavor to communicate approvals and rejections in a timely manner on Discourse or Workstreams, but candidates should rely on the multi-sig for the most timely communication.

All in all, great work. Super excited to move forward into the next chapter of Radicle Grants!

[shelb_ee]

You could use EPNS or Apex Wallet notifications that would automatically send notifications to given wallet addresses after a multisig decision is executed, but you have have to set this up for each group of applicants. Unless you were planning on using that notification stream for other things, it might just be easier to post on the application itself after a decision is made, tag the applicants and let them know to wait for that notification. This is also a bit more transparent.

[bordumb]

@abbey

I’ve addressed all of your feedback by amending the original post. Please let me know what you think.

Below is your feedback paraphrased + easy links/comments pointing where I addressed it.

Managing “seasons”:

• Proposing 4 month, simply because I think 6 months was too long, and 4 months seems like a good cadence. Open to changing this to align with other teams.
• Link: [Discussion 🌱] Radicle Grants Program - Continuation

Core Development Teamwork:

• Added some guidelines / rules for when and how soon we get them involved
• Link: [Discussion 🌱] Radicle Grants Program - Continuation

KPIs:

• Added KPIs to all elements of the Purpose component
• Link: [Discussion 🌱] Radicle Grants Program - Continuation

Using Workstreams:

• I’ve added a KPI to the same section above to spur on our use of Workstreams. We have one verbal agreement from Yorgos to try it out, so I’ve made the KPI “2” applications as a stretch goal. I’d like to get us using it for something rather than nothing, if for nothing else than to create a feedback loop with the Workstreams team, even if it is somewhat lacking in features.
• Link: [Discussion 🌱] Radicle Grants Program - Continuation

Retroactive Funding:

• I’ve added a new section in KPIs explicitly for retroactive funding.
• Link: [Discussion 🌱] Radicle Grants Program - Continuation

Communications with Grantees:

• I’ve made much more comprehensive notes on how we will communicate for rejections and approvals
• Link: [Discussion 🌱] Radicle Grants Program - Continuation

[abbey]

Amazing! Some notes below:

@bordumb

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.

Process-wise, we should just make a note to ensure that applicants are given notice that their vote will be delayed until Core Team input is received. Probably through a reply to the Discourse post.

@bordumb

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

KPIs look great Would love to use these as a framework to reflect upon at the end of each season.

@bordumb

Communications

Communications will be key and made fairly uniform and consistent. The major steps where communications will be made are:

Great edits! Just a note to think about if there’s any potential hires that could help you run the program and how you would go about getting them involved.

All in all, I’m very happy with the edits! Let’s get this moved to formal review!