[Discussion 🌱] Radicle Grants Program - Continuation

[Discussion :seedling:] 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 :mechanical_arm:

@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:

  • Indefinite via Optimistic Funding

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

:dog2::bone: 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:

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 Upstream, 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: 1-2 interviews, voting pre/post, assessment of work
  • Tree Grants
    • Target: small teams/start-ups
    • Budget: > $50,000
    • Time commitment from Committee members: 1-2 interviews, voting pre/post, assessment of work

Application Process

Whether technical or non-technical, grantees may apply via the following channels, following the application template:

Milestones

Milestones will either be explicitly written in the RFP and if not, should be addressed by the Grant Applicant in the application.

The purpose of milestones is to break down projects into functional components. In short, the main goal is to 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. Second, the simple exercise of creating milestone components organizes the work for the grantee into manageable chunks. Lastly, milestones also help us measure the completion status of the project in a simple way.

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, and non-technical approval.

Initial Approval

All projects will go through the initial approval. This will be managed entirely by the RGP Committee. An approval in this case is any multi-sig vote on a project that reaches quorum for the initial payment (see Payment section below).

Technical Approval

Technical approval will include an assessment by relevant Core Dev Team member(s).

For example, if a grant project touches Radicle Upstream, the work will need to be posted as a patch to Radicle 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

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.

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

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 DAO (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

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.

Dripping to Dependencies

  • 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.

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.

Applicants

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.

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.
  • Pay committee members using Drips.

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

Open Questions

The proposal above remains largely the same as the proposal that was originally approved for Wave 1. The 2 main open questions/amendments are as follows:

1. Optimistic Funding

The new wave will continue in perpetuity or until funds run out and new funds are not approved.

In the event that funds run out, a new on-chain proposal for budget must be made by any member of the multi-sig.

If that proposal is accepted by the RadicleDAO, the Grants Program shall continue.

If that proposal is not accepted, the Grants Program shall be considered no longer valid and a new multi-sig and program shall be started by someone else.

In the case that the multi-sig funds do not run out, but the community finds an issue with the current RGP committee, a new proposal can be made to setup an entirely new multi-sig and RGP committee. This can be considered equivalent to relieving the current RGP committee of their duties.

In other words, the Grants Program will be optimistically funded.

The pro for this model is a streamlined process, whereby the Grants Program can continue for perpetuity (or until funds run out), with little/no overhead such as freezing funds or sending them back to the Treasury when a grant wave is over.

The con for this model is that is is optimistic, so there is always the risk that the grants program doesn’t efficiently allocate the funds. This can be through poor grant approvals or simply not recruiting enough grant applicants to fill the funding. This downside is mitigated by the fact that funds will eventually run out and the community can choose to not approve subsequent grants.

2. Scheduling

Grants Wave 2 will start upon completion of a vote by the community to fund it.

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 leaving this open for this formal discussion to see what the community would prefer.

Based on previous experience, Workflow 1 may help reduce about a month of overhead.

3 Likes

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.

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 ?

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).

1 Like

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…

1 Like

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.
1 Like

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.

1 Like

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 :mechanical_arm: 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.

  • 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.

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

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.