[Formal Review 🌿] - Radicle Grants Program [v2]

This is the official draft and Snapshot poll for the Radicle Grants Program proposal. Please formally review the proposal and vote in the Snapshot poll by :rotating_light:17:00 CET - Thursday, November 25 :rotating_light:

:bulb:This is the second attempt at passing this proposal. Please refer to the discussion in the first Formal Review before addressing concerns with this proposal. The Snapshot poll failed to meet participation requirements. You can view the results here.

Proposal Champions :mechanical_arm:

@bordumb | bordumb#6773

Functional Description

The proposal is to start the Radicle Grants Program (RGP). The purpose of which will be to collect, assess, approve, and fund solutions to problems within the Radicle ecosystem.

In other words, the aim is to directly support open source initiatives that help grow the Radicle product, community, and the greater Free and Open Source Software (FOSS) and Web3 community at large.

Budget & Timeline

Amount: $1,000,000 (USDC) for grants + 44,108 RAD for committee compensation
Length: 6 months

Grant funding and compensation for committee members will be controlled by the RGP’s multi-sig. As Radicle decentralizes, the budget may fall under a different group entirely and/or utilize Radicle Funding/Drips. Any new arrangements will be assessed at the end of the 6 months. See the Compensation section below for more details.

:dog2::bone: Implementation

A fundamental goal for the RGP is to dogfood Radicle in order to build a web3-wide model for sustainable software development. This comes down to 3 main uses of Radicle:

The RGP Committee will be its own Org. Committee members will be added as members of the Org.

Grantees post work to relevant Projects within Radicle’s core codebase for assessment by Core Dev maintainers. This workflow would be handled with forks + patches with the final anchored commits acting as the “proof of work” for grantees.

Finally, once Radicle Funding is ready, RGP’s Org could pay out to grantee Orgs for their work via Drips.

Below is a high-level diagram of the proposed framework.

Note:

In the short term, I see all of these pieces being substitute-able by any combination of off-chain tools (GitHub, AirTable, etc.) in order to lower friction for grantees. However, in the long term, the goal is to get as much of this activity on-chain. This is not just for the sake of having things on-chain. It is so that the entire process is natively transparent, highly automated, and so that any learnings and pain points from the on-chain process are fed back to the Radicle product itself. We want a virtuous cycle!

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

All committee members, including the Grant Lead, will all be paid at a rate of $150/hour of work.

What is total amount of compensation needed?
We use the following assumptions on hours worked to find the total USD-denominated amount of RAD needed to cover committee compensation over 6 months.

committee_members = 6
monthly_hours = 50
grants_program_lengths_in_months = 6
total_hours_worked = committee_members * monthly_hours * grants_program_lengths_in_months

hourly_compensation_usd = 150
total_rad_compensation_usd = total_hours_worked * 150
total_rad_compensation_usd = $270,000

So we need roughly $270,000 worth of RAD to compensate committee members over the 6 month period.

How will we handle volatility in RAD:USD?
We start with the following information about historical prices over the past 6 months:

average_price = $10.80
standard_deviation = $4.68

So we propose the below formula to protect against large fluctuations downward in price:

RAD to Transfer = $270,000 / (AVG Price over 6 months - STD of price)
RAD to Transfer = $270,000 / ($10.80 - $4.68)
RAD to Transfer = $270,000 / $6.12
RAD to Transfer = 44,108

How will the conversion be made at the end of each month?

This will be paid out in RAD, with the conversion being made based on the average spot price in the last 7 days of each month. The payment will be made at the end of each month.

For example, if the average spot price were $15:1RAD at the end of the month and a committee member reported 10 hours of work for the month, they would receive 100RAD for the month (10 hours x 10 RAD, at $15:1RAD).

Committee members must self-report their hours worked by uploading a log to RGP’s repository, either on GitHub or Radicle Upstream. Committee members shall not be paid until they have logged their hours.

The rationale behind an hourly rate is that it creates the greatest opportunity for learning:

  • We will learn how much each committee member actually works
  • We will learn whether we need less or more committee members

In either case above, an hourly rate is likely the best mechanism to not overpay, but also not underpay committee members.

The rationale behind the rate itself is that we want to make sure we can recruit Committee members who can contribute well behind simple operational tasks. For example, the types of people who can bring a high degree of domain expertise around governance, documentation/education, and recruiting for & management of software development.

Please refer to the discussion held in the first Formal Review of this proposal for more context on what led to this decision.

The committee members themselves will use the multi-sig vote around the end of each month to approve compensation.

As noted above, the goal is not to keep compensation decisions contained within the RGP committee. We will move compensation decisions to some sort of external committee (e.g. Compensation Committee) as soon as possible.

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

Grants Lead

As mentioned in the forums, the Radicle Governance Working Group decided it would be best to hire a Grants Lead to create and manage the RGP.

After applying, I was chosen to lead the program by the RGWP. I’ve already introduced myself a bit in the application here.

I will be responsible for the following:

  • Organizing and disseminating project ideas: this will include RFPs from core Radicle members or open applications from the community (e.g. product requests from partners or straight from individual users)
  • Building channels for recruiting applicants: this might include things like putting forth RFPs to hackathons or posting bounties on GitCoin
  • Initial screening of applications: the Grant Lead will be the first line of defence for bad applications. Committee Members and Core Dev Team members should trust that they will only have to assess candidates who have met a high bar.
  • Scheduling assessments/interviews: this will include scheduling between grant candidates and any relevant Committee Members and/or Core Dev Team
  • Planning milestones/check-ins: milestones expected to be written by the grant candidates in their application. The Grant Lead will be responsible to have regular check-ins, depending on the tier of the project (see tiers below)
  • Multi-Sig voting: the Grant Lead will communicate to relevant Committee Members when a vote for finalized work is in order.

The core goal of the Grants Lead is to build the Radicle ecosystem.

Program Structure & Process

The entire structure and process is meant to evolve over time, with the long-term goal to push as much of the work onto Radicle.

Project Ideas

RFPs will be the main source of project ideas. RFPs can come from core Radicle members or can be written by users and other community members (e.g. a feature request that another platform’s team is keen to have). RFPs from community members must follow the same format as the format established by Radicle. They cannot be free-form. This is to ensure some level of equality when assessing multiple applicants. And the more technical details, the better. This is to ensure we have enough detail to assess an application with as little back-and-forth as possible.

We expect that in Wave 1 of the Radicle Grants Program, most RFPs will come from the core Radicle team. Over time, the line between core member based RFPs and community RFPs should blur. This will be a key part of Radicle’s progressive decentralization. Canonical RFPs will be organized within RGP’s Org in its own Project. Copies will be made available elsewhere, such as mirroring on GitHub, blog posts, etc. Budget Estimates will be made at this point.

Scope

The first grants wave will last 6 months.

Applications will be reviewed on a rolling basis. Every 2 weeks applications will be assessed by Committee Members.

Multiple teams may apply for the same grant/RFP. This has several implications. It means applicants are in competition. But Committee Members may also (a) recommend to combine teams or (b) split the RFP into sub-tasks to be divided amongst each grantee.

There will be 3 tiers to help organize and prioritize projects:

  • Tier 1
    • Target: individuals/small teams
    • Budget: < $25,000
    • Requirements: 20% of multi-sig approval
    • Time commitment from Committee members: voting pre/post, assessment of work
  • Tier 2
    • Target: small teams/start-ups
    • Budget: $25,000 - $50,000
    • Time commitment from Committee members: 1-2 interviews, voting pre/post, assessment of work
  • Tier 3
    • Target: small teams/start-ups
    • Budget: > $50,000
    • Time commitment from Committee members: 1-2 interviews, voting pre/post, assessment of work

Note: Details above are subject to change based on our experience providing grants.

Application Process

Grantees may choose from any of the application processes below. Both application processes follow the same form.

Non-Technical Applications

Location: there will be an AirTable based application.

Process: it will ask the Applicant for things like their name/pseudonym, GitHub or other previous work material, ask for a URL/name of the RFP they are applying to, or in the case of their own RFP/feature request, will ask them to fill in more details. It will also ask for details on how they plan to address the RFP’s work.

Technical Applications

This application process is recommended for anyone who wants to immediately start organizing their work with a Git client.

Location: the RGP Org will run applications through a Project called “applications.” In the example below, there is an rfps folder where all RFPs live. A standard template [template.md](http://template.md) , an RFP for Japanese localization posted by the Core Dev Team, and an RFP/application posted by a community member.

RGP-ORG
  | - applications (project)
  |  | - rfps (folder)
  |  | - | - application-template.md
  |  | - | - japanese-localization (folder)
  |  | - | - | - rfp.md
  |  | - | - | - your-application.md
  |  | - | - my-custom-application (folder)
  |  | - | - | - your-application.md

Process: to apply, Grant Applicants can fork + patch into an existing RFP’s folder or they can create their own RFP folder. In either case, the only thing an applicant should be adding is a new application file (your-application.md)

Note

In the short-term (this grant wave), Applicants may substitute this workflow with GitHub using PRs. We will mirror RFPs there. But canonical RFPs will be on Radicle.

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

Any technical work (i.e. code) must be posted as a fork + patch if done using Radicle or as a pull request (PR) if on GitHub

For example, if a grant project touches Radicle Upstream, the work will need to be posted as a patch to Radicle project or as a PR in the GitHub repo.

The maintainer(s) of the respective repo (likely Core Dev Team) will review, give feedback, and ultimately approve the work.

Grantees will use the Project ID and anchored commit as “proof of work” for final payment (see Work Approval and Payment below).

Note:

In the short-term (i.e. this first grant wave) Grantees can expect some flexibility to this process. For example, we will allow you to post your final draft to GitHub for assessment. But we will still end up forking it ourselves to bring it into the Radicle Grant Program’s own Org.

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 40% 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 60% 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. Grants Dissemination

As Radicle-based RFPs become available, they should be posted with their budget through the following channels:

  • Twitter + other social
  • RFP + budgets posted on GitHub, Radicle Grants Program’s repo, Blog, and the #garden channel on Discord

For community-based RFPs, they will be posted if they pass the initial screening.

2. Grant Applications

No communications by us.

But these will be naturally public due to the fork + patch workflow mentioned above (or as PRs in the mirrored repo on GitHub).

3. Grant Approvals

As grants are approved on a rolling basis,

  • Approvals of grants (per grant)
    • Added to GitHub, Radicle, Blog on rolling basis as they come in

4. Grant Completion

  • Completion of individual grant projects (per grant)
    • Twitter + other social (celebrate!)
    • Will be naturally public due to the patch workflow mentioned above

Purpose

The purpose of this entire exercise comes down to three main goals.

First and foremost is progressive decentralization. Radicle is meant to enable the decentralization of governance and contributions to free and open-source software. As a result, Radicle itself should be self-governed, self-funded, and self-built for and by the Radicle community. This also aligns with the third high-level objective of the Radicle Foundation,

Second is that the team growth of contributors will mean product growth. There is a natural limit to what the Core Dev Team can develop, so new contributors will mean more attention to more features, an improved experience for users, and more innovation. The Radicle Grants Program won’t just be a space for peripheral tasks. It will also be a part of Radicle’s own recruiting pipeline to bring on new core members.

Lastly, if we’re successful, the RGP will become a model for all DAOs. It will be a model for building self-sustaining, open source projects, DAO-funded project development, as well as DAO-to-DAO (D2D) “business”. The RGP will become a hub for sharing best practices around organizing and funding projects, as well as how best to use Radicle to drive governance and development for FOSS. It will do this in a more codified, automated, and in an on-chain way that only Radicle can do.

The RGP is also an initiative that contributes to two of the Radicle Foundation’s high level objectives for the project (see full post below):

  1. Increase the number of devs building and contributing to Radicle #grants ##progressive-decentralization

  2. Strengthen the core teams #people

Background

Radicle is currently run by a couple dozen core members.

The Radicle Grants Program will be a major towards progressive decentralization.

The reasoning behind starting a grants program is to add structure, process, and automation to the onboarding of new contributors, all of which is powered by Radicle’s software itself. This will help us put our best foot forward in decentralizing Radicle.

Link to Temperature Check

Reasoning & analysis

Pros

  • The pros largely follow the Purpose section above
    • Progressive decentralization: almost by definition, a grants program decentralizes
    • 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, which should mean more innovation
    • 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
  • Period: 6 months
  • At the end of the period, the unused money should be sent back to the Treasury
  • Would need someone from Core Dev Team + Treasury to implement this

At the end of the 6 months, a new grants wave must be announced, go through the normal governance process.

Execution of Grant Work

(Note: summarized from Implementation & Setup above)

The Radicle Grants Program will have its own Org, with a structure like below:

RGP-ORG
  | - applications (project)
  | - project-one (project)
  | - project-two (project)

The Org will be managed by the Grant Lead.

Grant Applicants will use the fork + patch workflow to apply for grants (i.e applications project). If applicants use an airflow application, the Grant Lead will post their application publicly to the RGP Org.

Grantees will post work to the respective Radicle Project using fork + patch or as a PR in the respective GitHub repo. Core Dev maintainers will have final say on technical work. Non-technical work will be shared in a way that makes sense for the given work.

Once work is finally approved, the RGP Committee will use voting via multi-sig to disburse funds.

Note

In cases where grantees do their work on GitHub or elsewhere, that is fine. But the final draft will be uploaded to
Radicle in the relevant Project as noted above. This is what RGP Committee members will use to determine their
multi-sig vote for funding.

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:17:00 CET - Thursday, November 25 :rotating_light:

3 Likes

Great stuff!! :+1:

Just a couple of questions / comments:

Love this! :clap::clap:
(well, and many other points in the proposal… :slightly_smiling_face: )

Is there a requirement for % of multi-sig approval for all Tiers, or just Tier 1?

2 questions here:

  • is the “but” a typo?
  • is this a definitive list of allowed licenses, or are these just examples?

Should that read: “any unused money should be sent back to the Treasury” ?

Top ideas for building the best community

Is there a requirement for % of multi-sig approval for all Tiers, or just Tier 1?

When we set up the multi-sig, the required votes will be set to 3. This will amount to 50% of the current committee.

The motivation for this is to keep friction low (especially for tier 1 projects), while requiring a level of consensus that keeps the bar for quality of applications reasonably high.

With Gnosis, only a single requirement can be set, so the hard-rule (i.e. what is codified) will be 3. But we will have a soft rule that 4 votes are required for tier 3 projects. This would amount to 2/3 (~66%) consensus.

2 questions here:

  • is the “but” a typo?

Yes, the “but” is a typo. Will remove that.

  • is this a definitive list of allowed licenses, or are these just examples?

These are just common examples. If an applicant wishes to use another license, we will evaluate that on a case-by-case basis and this may become a contributing factor in whether an applicant passes the votes needed to get a grant.

Should that read: “any unused money should be sent back to the Treasury” ?

Yes. That’s a good interpretation and a better way to specify this portion. I’ll reword that. Thanks!

2 Likes

ok, thanks a lot for the clarifications! :ok_hand:

really great systematic thinking here. i think transparency around committee compensation on an ongoing basis will be paramount.

the fact even that we are putting aside $511K worth of RAD for the management of $1M of grant capital for 6 months does not pass a common sense smell test. it means on an annualized basis we are putting aside >100% of the total capital as a reserve to compensate committee members.

i believe the rate of $150 per hour is too high and has not been appropriately explained. based on the requirements articulated there is no clear reason why an undergraduate comp sci major would be unwilling to effectively serve on the committee for a fraction of that rate. as previously mentioned assumptions around 50 hours month for grant committee work sounds absurd. low to mid single digit feels far more reasonable. 300 hours of work to distribute $166K monthly is incredibly inefficient. most of the work should be done by grant applicants. the committee’s job is to review and make decisions, that is not time intensive. if it is the system is not working.

i understand we have left a lot of variables open and appreciate the extra effort in trying to structure this, but the anchoring bias of these sets of assumptions i view as dangerous and not indicative of a community driven by common purpose.

i believe the rate of $150 per hour is too high and has not been appropriately explained.

Even though I wasn’t involved in how this figure came about, that is actually something I find ok. In my experience, it is typical for “consulting” type of work (intermittent, limited length, few hours per month) as it offers no kind of “job security”, etc. I wouldn’t compare this hourly rate to what people make on their day job, is what I mean. To add to that, I would want that committee members make enough considering the capital they are managing, so they are not “tempted” to act dishonestly. I don’t have any numbers or figures to back that with though.

based on the requirements articulated there is no clear reason why an undergraduate comp sci major would be unwilling to effectively serve on the committee for a fraction of that rate.

This is where I take a completely different point of view. I am failing to see how an undergrad has enough experience to evaluate different project ideas and tell the good from the bad apart. This is something that comes with years of experience in the space/industry and so I would not expect “an undergrad comp sci major” to be able to fulfill this role adequately.

Side note: Perhaps this different point of view also helps explain the different point of view we have on the hourly fee as well?

as previously mentioned assumptions around 50 hours month for grant committee work sounds absurd. low to mid single digit feels far more reasonable. 300 hours of work to distribute $166K monthly is incredibly inefficient.

Hmm I think there are some assumptions missing here… For example, what if the Radicle Grants program goes viral and there are 500 RFPs that need to be reviewed? What if that goes up to 1000? Would that not require more hours from the Grants committee ?

the committee’s job is to review and make decisions, that is not time intensive. if it is the system is not working.

I actually find reviewing to be very time intensive for me and I would even go so far as to say that if the reviewing is thorough, then the system is working.

Thanks for the sharp feedback!

@yorgos wrote a great reply, but figured I’d give my 2 cents on some of your points as well

They’re organizied in descending order of agreement (i.e. I agree more at top, less so at the bottom).

Agree

i understand we have left a lot of variables open and appreciate the extra effort in trying to structure this, but the anchoring bias of these sets of assumptions i view as dangerous

I think the most dangerous point is that we the committee will also be the ones voting on our own compensation. There is a clear conflict of interest.

In the short-term, 2 things I think will help control for this:

  1. Everyone is getting paid in RAD (not USDC), so the hope is that we will keep each other honest for the benefit of the equity we are being paid (i.e. we have skin in the game)
  2. Committee members will need to open a PR that logs their time worked. This entire process will be 100% public.

In the long-term, I’ve posted a few times that ideally we move compensation to an entirely separate governing body; something like a “Compensation Committee” that thinks deeply about how best to manage compensation.

In leu of that Compensation Committee, the overall structure outlined above is the best possible option, in my opinion. If you have better (and specific) ideas, I’m all ears :slight_smile:

Disagree

I’ll start with the equation above:

committee_members = 6
monthly_hours = 50
grants_program_lengths_in_months = 6

hourly_compensation_usd = 150
  • We have 6 voting seats. No debate there.
  • 50 monthly hours. There is debate here.
  • We have a 6 month program. No debate here.
  • $150 per hour. There is debate here.

50 hours

as previously mentioned assumptions around 50 hours month for grant committee work sounds absurd.

Main theme here is:

Preparing for the maximum

This number is the absolute maximum that I am expecting some people to work. This number was not pulled out of thin air. It came from talking with people who have worked in grants programs and said that they have sometimes worked between 10-15 hours per week reviewing work.

I am not trying to fund this program with the “lowest common denominator” in mind. I am trying to fund it in a way that allow people to work more and trust that they can be paid for doing more work. This is sort of the point @yorgos made about the grants program possibly going viral.

At my current job, I am on a team of about 6 people. When we are hiring, we rely on an HR department to do all the initial screening of candidates. This is probably 30-45 minutes of work per candidate (reading through their application, GitHub account, past projects, etc.). Once a candidate makes it past there, we might collectively spend 10 hours per candidate to put them through interviews, review candidate work, and collect feedback notes. Again, to @yorgos’ point: reviewing work should not be a rubber stamp. It’s intellectual work that takes time.

At the end of the day, any unused funds will be returned to the Treasury. We will come away with learnings (e.g. perhaps we really only work 3-5 hours a week as you mentioned), but we will have managed downside risks at the same time.

$150 per hour

i believe the rate of $150 per hour is too high and has not been appropriately explained. based on the requirements articulated there is no clear reason why an undergraduate comp sci major would be unwilling to effectively serve on the committee for a fraction of that rate

@yorgos hit the nail on the head.

But I will follow up by saying: we are not trying to hire the type of people who are ok with $50 per hour. There might very well be a new graduate who is a serial entrepreneur and who could handle the complexity of a product like Radicle. But such a person - new graduate or not - is worth more than $50 per hour. They can go work at a FAANG company for at least $100 per hour, when you consider base salary, equity, benefits.

Personally, I have another job as a data scientist and my time is worth a lot more than $100 per hour. I can’t speak for the other committee members, but if you click on the links provided for each committee member, I would argue that their time is worth even more than mine is.

We want to attract committee members who can provide value that goes beyond being an operational rubber stamp for grants. Please see the examples I mentioned, which many of our committee members are experts on.

Also, everything @yorgos said about this being “consulting” work is very salient.

$511K worth of RAD

we are putting aside $511K worth of RAD for the management of $1M of grant capital for 6 months does not pass a common sense smell test.

I will start with this equation:

RAD to Transfer = $270,000 / (AVG Price over 6 months - STD of price)
RAD to Transfer = $270,000 / ($10.80 - $4.68)
RAD to Transfer = $270,000 / $6.12
RAD to Transfer = 44,108
  • $270,000 for total compensation. If you agree with the points above, there is no debate on this number.
  • $10.80 average RAD:USD price over last 6 months. No debate here. It is a mathematical fact.
  • $4.68 standard deviation of RAD:USD price over last 6 months. No debate here. It is a mathematical fact.

Risk Management

We have to control for RAD:USDC price volatility. Fingers crossed that it doesn’t happen, but how would you pay committee members if the price of RAD dropped 80%? In the last 6 months, this has happened. It went from around $25 to $5. This is a very real risk, which must be controlled for until the price is more stable.

Your assessment that we are allocating $511K for compensation is missing the point. We are estimating $270,000, but also have to manage the risk of a downturn in the price of RAD.

This sort of equity compensation + risk management is something that would ideally be handled by a Compensation Committee.

I understand this is perhaps the “dangerous” part you are referring to. There is a danger that RAD’s price remains stable and we collectively find a way to raid the coffers to take all $511K that is there. Again, please see my notes above on short-term controls against this.

But I’d also add, I have voted “yes” on this proposal. I am bordumb.eth there. You can see how much RAD I already have and I am also staking my reputation on this risk management. I am expecting that I’d be ousted if these funds are mismanaged.

Main Takeaways

I think there is a lot less room for debate on the risk management side (my last point just above).

I also don’t see much room for debate on the hourly rate.

But perhaps there is room for debate around monthly hours.

@niloconthecob keeping in mind all the points on risk management, do you think we should also risk not being able to pay committee members what they are worth?

For example, imagine the following scenario.

Starting assumptions:

  • We allocate $100,000 of RAD at today’s price ~$12, so ~8,300 RAD, for committee compensation
  • Committee members are paid $150 USD:RAD
  • Committee members work 2 hours per week, or 8 monthly. This is using your assumption of less hours.
  • RAD:USD price drops back to $4, so we must pay 37.5 RAD per hour ($150 hourly rate / $4 RAD:USD)

How it plays out:

  • This amounts to 288 total hours worked over 6 months (6 voting seats * 6 months * 8 hours per month)
  • We would need 10,800 RAD (288 hours * 37.5 RAD per hour). We would be unable to pay committee members by over 2,000 RAD! :confused:

The risk of volatility in price is very real and cannot be understated. If we were the Ethereum Foundation paying out in ETH (which has a much more stable price), I might put less weight on controlling for volatility.

I hope that thought experiment helps you piece together some of the thinking here. But let me know if you still find disagreement with it and maybe some ideas on how you might better control for these variables :slight_smile:

1 Like

A bit late to the party, but I have a few questions.

Some of the committee members are already working for the Foundation, is the compensation stated here on top of any existing compensation they’re already given? And how should we expect the hours they work on the RGP to affect the hours they currently work?

On a similar note, am I understanding correctly that there’s essentially $1,000,000 - $270,000 left for grant projects?

There was a lot of text, so I might try to rephrase some of the above to see if I’m understanding the process correctly. There’s a committee that is the first bastion for taking applications from outside contributors to obtain a grant. These contributors will be rewarded grants by putting forward appropriate RFPs that are accepted by the committee (and core team members). They must then implement these RFPs, submit patches, and are rewarded further upon completion of this work. Is this a correct summary?

If so, I don’t see the hours spent by a core team reviewing the RFPs being accounted for as well :slight_smile: I’m also curious as to how the committee might have the expertise to gate RFPs for core projects? In particular, I’m thinking about radicle-link of course :grinning_face_with_smiling_eyes:

On another point, are the committee members logging their hour-by-hour work? And who reviews this? Who Watched The Watchmen, so to speak :male_detective:

And finally, I may have missed it, but how are we accounting for grantees work? Will there be some kind of log of their efforts too?

Sorry if some of this is covered in the above, I was trying to piece it all together as best I could :grinning_face_with_smiling_eyes:

:v:

Hi @fintohaps !

Great questions.

On a similar note, am I understanding correctly that there’s essentially $1,000,000 - $270,000 left for grant projects?

No.

It would be $1,000,000 USDC for grant work. This would be used to pay anyone who is working on an approved grant project.

@cloudhead raised the issue of controlling for volatility in RAD:USD(C) prices. So rather than lump the grant + compensation funds together as USDC, I am keeping them separate.

So in addition to the $1,000,000 USDC for grants funding, an additional ~44,000 RAD to cover compensation in RAD to committee members.

Please reference the discussion just above on how this ~44,000 RAD was determined.

Assuming that we use 100% of grants funding and RAD price remains completely stable, I estimate we will end up using $1,270,000 worth of assets in the first 6 months to pay for grant work + compensate committee members. Any remaining funds that go unused will be returned to the Treasury.

They must then implement these RFPs, submit patches, and are rewarded further upon completion of this work. Is this a correct summary?

Yes. That’s a very good summary of the process.

If so, I don’t see the hours spent by a core team reviewing the RFPs being accounted for as well :slight_smile: I’m also curious as to how the committee might have the expertise to gate RFPs for core projects?

I may not have enough date points on this topic, so I’m glad you’re raising it.

I asked several core developers whether they’d like to be on the committee, but the general consensus was that they were too busy to take on committee obligations (initial screenings, interviews, voting, meetings, etc.).

So the thinking here is that grant work - especially if it’s technical in nature - is no different than the responsibilities of core development work.

Please let me know if you have any input on this point and specifically how you might like it improved. I only spoke to about 1 person per product group (as it’s divided on Discord), so more data points may help :slight_smile:

On another point, are the committee members logging their hour-by-hour work? And who reviews this?

Yes, I will provide a template for people to fill out that will require logging of each hour worked.

All of this will be as a PR/patch, which makes it 100% public.

The community will be watching the watchmen.

I think this is less than ideal, but I also don’t see it lasting more than this first 6 months (please CTRL+F for “compensation committee” which is mentioned a few times above).

And finally, I may have missed it, but how are we accounting for grantees work? Will there be some kind of log of their efforts too?

This will all be project based payments.

For example, we might post a project like this:

  • Create video outlining onboarding to Radicle
  • Budget: $2,000

We won’t mind if it takes the person 10 hours to do the work or 100 hours. We might negotiate on the budget, but it will not be paid out on an hourly basis. It will be for work completed on a project basis.

Thanks again!

On a slightly different note, was there discussion during the design phase about grantees receiving some of their funding in RAD instead of USDC? This came to my mind as I was reading comments on “skin in the game” and “incentive alignment”. I know that other crypto projects do distribute their native token through grants but it sounds like the program discussed here will distribute only USDC. Is that correct? Definitely not saying that it should be reconsidered, esp. as grantees have the option to convert some of the USDC received into RAD. Just curious whether this came up or not.

hi all, i thank @yorgos and @bordumb for their clear responses. if the community feels we need to pay grant committee members $150 per hour then that is what the community wants. i personally would be very happy paying $50 per hour. what are getting for that extra $100 per hour?

if the current committee feels they require $150 per hour to do the work then based on this framework we don’t have much choice: $150 per hour it is.

if everyone agrees we should have a compensation committee decide grant committee compensation then we should have the compensation committee decide grant committee compensation. we should approve the rest of the governance proposal and wait to finalize the compensation question until such committee (or really any third party that is not inherently conflicted) can appropriately review and decide what the grant committee should be compensated.

my point is a macro one: the assumptions have been geared to set aside the biggest possible funding for compensation (maximum potential hours per month, very lower $ per RAD). i understand extra will be returned to treasury but i find the anchoring bias wrong.

i just ask this group to step back and look at the big picture. in this proposal we are currently considering setting aside 44,108 RAD (current market value of $882K, yes volatility can go both ways) to compensate 6 people for 6 months work of giving $1M of grant money. talk to someone at a coffee shop about that. talk to your mom about that. ask yourself if that makes sense. ask yourself if that puts a positive reflection on this project.

@bordumb my concrete proposal would be to cap the grant committee’s compensation to a reasonable fraction of the overall funds being distributed (15-20%). arguably that number should be lower (see here for an example of the UK’s science and technology’s grant funding compensation structure. UKRI distributes £7.6B in grants annually. the report shows that they are paying board members £37K per year, total remuneration of full-time senior staff is £1.8M, total remuneration for all staff is £400M. that means they are paying £0.05 for every £1 in grant money.) more examples would be great.

with that fixed budget of $150-200K we could then see what kind of caliber talent we can attract to distribute the grant money. this is a test after all…

1 Like

Hi All!

Thanks everyone for the continued discussion here. Seems like @bordumb has a couple more messages to reply to, but in the meantime I wanted to give an update from the Radicle Governance Working group on our proposed next steps after last week’s Snapshot poll.

Feel free to continue discussion here regarding improvements to the proposal, but please review the proposal from the working group. We will be discussing the proposal in next week’s monthly meeting.

Thanks!
Abbey

@niloconthecob thanks for finding and contributing extra data points. Even if we disagree on a couple of points, personally, I find this discussion a very valuable and worthwhile one, so thanks for that too! :slight_smile:

i just ask this group to step back and look at the big picture. in this proposal we are currently considering setting aside 44,108 RAD (current market value of $882K, yes volatility can go both ways) to compensate 6 people for 6 months work of giving $1M of grant money. talk to someone at a coffee shop about that. talk to your mom about that. ask yourself if that makes sense. ask yourself if that puts a positive reflection on this project.

I’m afraid this has nothing to do with radicle or this community. The high salaries that many people in IT are making these days is something that both someone and a coffee shop and my mom would find unreasonable (though I imagine my mom would probably find it less so :sweat_smile: ).

It is what it is however… As much as anyone may think it is unreasonable / a bubble waiting to burst, (or not!), there are several data points that can confirm that “salaries are high” (e.g. glassdoor.com, job ads that have salary ranges published, etc.)

Add to that reality the facts that:

  • this fee is in RAD, not EUR/USD (so, this bears similarities to startups offering equity)
  • this is “consulting” type of work (as per my previous post)

…and this brings me to the conclusion that the “150 usd / hour” isn’t all that unreasonable after all. I can’t say I speak for anyone other than myself in reaching this conclusion though.

arguably that number should be lower (see here for an example of the UK’s science and technology’s grant funding compensation structure. UKRI distributes £7.6B in grants annually. the report shows that they are paying board members £37K per year, total remuneration of full-time senior staff is £1.8M, total remuneration for all staff is £400M. that means they are paying £0.05 for every £1 in grant money.) more examples would be great.

It’s great to have extra data points like this. I am not sure whether it is 100% applicable (industry vs. academic research), but it certainly helps to have such data points. If anyone has more data points to contribute, I would love to hear about them.

with that fixed budget of $150-200K we could then see what kind of caliber talent we can attract to distribute the grant money. this is a test after all…

I would like to point out that the “150-200K” is only one outcome of applying the 15-20% cap of overall funds being distributed.

Another outcome would be to take the committee compensation as a constant and treat the total funds available to the grants program as the variable. :wink:

This was also my understanding, yes.

Side note: Assuming grants will be offered in RAD, I think it would help if we switched all discussions to use RAD rather than USD.

I am not sure that was covered, to be honest. My current understanding of the proposal is that any hours spent by the core team reviewing RFPs or patches is outside the scope of this proposal. Probably best if @bordumb offers the clarification here though… :wink:

On another point, are the committee members logging their hour-by-hour work? And who reviews this? Who Watched The Watchmen, so to speak :male_detective:

I see 2 options:

  • peer review, within committee members
  • someone from radicle foundation

And finally, I may have missed it, but how are we accounting for grantees work? Will there be some kind of log of their efforts too?

Does that really need to be logged? Grantees apply for funding and as long as the work they submit is approved / accepted, they should receive that funding. Does the Radicle Grants Program really need to know how much they worked to make that happen?

@bordumb has clarified that this isn’t actually the case :slight_smile:

My understanding from reading the proposal is that the grant allocation will be in USDC.

It doesn’t need to be as stringent, but we’re always talking about working in the open so yes, I think an open look at how grantees are progressing is important. There is the mention of milestones and of course, there will be commits, so perhaps this is enough. And on a further note, it would be important to set the grantees up for success to make this a successful endeavour. Being able to see how they progress and checking in with them would help make this successful.

I’m looking back over the proposal, my questions, and your answer @bordumb. I think some further clarifications might help me refine my thinking about this a bit better :slight_smile:

Can we clarify what these roles actually mean:

  • Radicle Community
  • Core Team
  • Ecosystem

I only have a vague idea what they mean, so some clarification would be helpful.

Going through the proposal again, at least to me, there seems to be more prose telling us how the committee members will get paid compared to what they will actually do. The most prose provided is regarding the grants lead. Admittedly, there are some sentences here and there about the committee members performing interviews or reviews, but I think a dedicated section the responsibilities would make this clearer – and might help understand the level of compensation.

On the note of compensation, I don’t think I’m seeing any explanation of why the committee members are compensated in RAD in the first place. If volatility and prices are a concern, why not just say $270,000 in USDC is the compensation, and whatever amount of RAD that is upon snapshot completion is what gets transferred?

It was also mentioned that RFPs can be written by core members, could you clarify:

  • If core members can apply for grants? – asking for a friend :stuck_out_tongue_winking_eye:
  • Or if the idea is for grantees to pick up the (non-)technical work of those RFPs?

On a final note, patches are mentioned to be received by Radicle or GitHub – radicle-link accepts patches via our mailing list :wink:

< Sidenote > (also thinking over the proposal as a whole):

I was thinking that this is starting to have all the signs of those MONSTER PRs that get very hard to review / get merged, simply because they are bringing about too much change, all at once.

I am not familiar with how similar subjects have been addressed in the past in this community, but… would it help reach consensus if we broke this down into many sub-proposals, each addressing the various points of contention?

</ Sidenote >

This relates to my question above. @bordumb I’m sure this info has already been communicated somewhere but will grants be paid out in RAD or USDC?

I mentioned this in another thread but the 5-member ZOMG committee (Zcash) launched with $500 per month for an estimated time commitment of 5 hours per month per member (i.e. $100 USD / hour). However, this turned out to be inadequate because the actual time commitment required was higher. For the second term of the committee, compensation has been increased to $1,500 USD for an estimated 15 hours per month per member (i.e. the rate stayed at $100 / hour), and the Zcash Foundation has committed to providing additional administrative support to ensure that committee members can focus primarily on assessing grant applications (comparable to the RGP lead role). In terms of what’s expected from committee members, I think the ZOMG is a good enough reference point for the RGP.

EDIT: There has been some discussion in paying ZOMG committee members in ZEC but, as things stand, members receive USD which they can convert to ZEC independently should they so choose.

EDIT2: This post is not arguing for a specific compensation package. It is simply presenting a data point from a similar context, as requested.

1 Like