[Discussion 🌱] Treasury Covers Costs for Creation of Radicle Orgs

[abbey]

The official discussion for the Treasury Covers Costs for Creation of Radicle Orgs proposal. With this post, the proposal has entered the second phase of the governance process. Please review the drafted proposal and contribute feedback by Sunday, November 7th.

Proposal Champions

Nassar Hayat - @nas | nas#9634
Abbey Titcomb - @abbey | abbey#5646

Description

We’d like the Treasury to fund a multi-sig for reimbursing gas fees incurred from creating Radicle Orgs. The goal of this initiative is to support the adoption of Radicle Orgs by reimbursing gas fees for the first 200 Orgs created on mainnet.

The reimbursement fund will be managed via a multi-sig governed by 3-5 individuals involved in Radicle project & community:

• @abbey* - Community Team Lead
• @nas* - Community Team Contributor (Partnerships Lead)
• @larry* - Radicle Governance Working Group Contributor

Potential additional candidates:

• @cloudhead - Alt-Clients Team Lead & Foundation Council
• @bordumb - Radicle Grants Lead

*committed/expressed interest

Users that create new orgs can submit a reimbursement request to the multi-sig to cover the transaction fees of their org creation.

The initiative would cost $200,000 USDC and be funded via an allocation from the Radicle Treasury (See Reasoning and Analysis for a cost breakdown).

Purpose & Background

Radicle Orgs are one of Radicle’s most exciting new features built on Ethereum. Radicle Orgs — on-chain entities owned by multi-sigs (i.e. Gnosis Safe) — offer a transparent & universally verifiable way to manage and distribute ownership of codebases.

Today, creating and deploying an org on mainnet is very expensive (up to $1k) and constantly fluctuating due to gas costs. This cost presents a barrier to entry for new users looking to starting using orgs.

As we wait for orgs to land on L2, it’s important that we think critically about how we can make onboarding projects to orgs easier so we can increase usage & adoption of Radicle’s Ethereum features.

Temperature Check

[Temperature Check] Treasury Covers Costs for Creation of Radicle Orgs

Hey folks, I would like to propose that the treasury covers the costs for creation of new Radicle Orgs in order to drive adoption of that feature. Context Radicle Orgs is one of the most exciting and differentiated Radicle features Creating the org contracts today is very expensive (many times 50-100$) Until Radicle Orgs land on layer-2 we need to all think creatively about how to help devs that want to start a Radicle Org do that, without bearing the un-necessary tx fees Proposal The treasu…

Reasoning & Analysis

This proposal is a short-term solution for stewarding adoption of Radicle Orgs. We believe this will get more people using & experimenting with orgs, which will support the success of the feature in the long-term. Additionally, our current onboarding efforts are significantly hindered by the cost burden of org creation (see below).

[Temperature Check] Treasury Covers Costs for Creation of Radicle Orgs

Hey all. Having worked with @carson of textile.io to onboard them onto orgs we came up against $1000 setup cost for the Org, so above the ceiling for just one of the steps. There are many more along the setup. It isn’t really practical to onboard teams whilst trying to time it for low gas fee period. So the two options I can see are: We hold off and wait for some form of layer 2 solution. I onboard partners to our partnership programme and we onboard them at the end of the year to Orgs just ah…

If reimbursed users don’t end up using or maintaining their org after subsidized creation, product teams can use this as a community signal that the orgs value proposition needs to be improved/revisited.

Radicle Orgs needs better marketing or the product features need to be enhanced to improve the value proposition to users. Either way, I believe the protocol should be willing to pay for this information via the subsidy of Radicle Orgs.

Budget Breakdown

Combining the initial cost breakdown from @cloudhead and the more recent onboarding experiences of @nas, we believe that allocating ~$1000 or .25ETH per org is a safe estimate (see below).

[Temperature Check] Treasury Covers Costs for Creation of Radicle Orgs

Makes sense. With regards to average cost: Org creation including a Gnosis Safe costs about 900K gas. With a “low” gas price of 50 gwei, this gives us about 0.04 ETH With a “high” gas price of 100 gwei, this gives us about 0.08 ETH If we want to include other things like setting up your ENS name etc., we can bump it up to 0.05-0.1 ETH on average. As gas prices are sometimes higher, eg. 150-200 gwei, I can imagine this going up more, so if we want to be really conservative, I’d budget 0.2 E…

While 1000 orgs was the original suggestion, @nas made the point that focusing on onboarding 100-200 well-established/larger projects could work better with our partnership strategy.

[Temperature Check] Treasury Covers Costs for Creation of Radicle Orgs

Hey all. Having worked with @carson of textile.io to onboard them onto orgs we came up against $1000 setup cost for the Org, so above the ceiling for just one of the steps. There are many more along the setup. It isn’t really practical to onboard teams whilst trying to time it for low gas fee period. So the two options I can see are: We hold off and wait for some form of layer 2 solution. I onboard partners to our partnership programme and we onboard them at the end of the year to Orgs just ah…

At the upper limit of that range, we’d expect a budget of ~$200,000k/50ETH. Incurred fees would be bundled per org, and the initiative would last until 200 orgs have been reimbursed or the funds depleted. From there, the community could evaluate the effectiveness of the program and decide on the parameters of its replenishment & continuation.

Technical Implementation

• A Gnosis Safe multi-sig managed by 3-5 individuals from the Radicle community (1 of 3/5 quorum) and funded by the Treasury ($200,000 USDC)
• An Airtable form & workspace for managing & tracking reimbursement requests
• [OPTIONAL] An official version-controlled repo documenting distributions for transparency. (maybe could be controlled by a Radicle Org managed by the members of the Growth Workstream?)

Impact

This proposal will make it easier and less expensive for new users to create orgs which we believe will help support long-term adoption of Radicle features.

Additionally, we believe that using the Treasury to fund growth & adoption initiatives is a very exciting opportunity. We’d like to use this proposal as case study for the type of Treasury-funded growth initiatives we see being created, proposed, and funded by the Growth Workstream.

[Temperature Check] Growth Workstream

Summary The setting up of a growth workstream was proposed by community members in our last governance working group call. Our go-to-market strategy is currently being developed and goes hand in hand with product development in pursuit of product/market fit. We need to agree on a strategy and then explore treasury funded initiatives. About Author A brief introduction of myself as a working group and core team member. My parents named me Nassar and then I grew up and started building digital pl…

Open Questions

• Who is responsible for managing reimbursement requests?
• Is 200 orgs a large enough sample size for testing the effectiveness of this initiative?
• Should we have this managed by a Growth Workstream org?
• What criteria do we want to introduce for reimbursement requests?

[niloconthecob]

This seems like an important way to increase initial Org adoption and overcome the “active energy” associated with catalyzing a Radicle reaction!

My sense is that this clearly fits the profile of Growth Initiative and so it would be appropriately fit underneath that. Also a good test case for future Growth Initiatives.

I think the clear decision points are around the criteria for eligibility and the number of orgs. In a way I think we may be trying to pre-determine too many factors. We should be fixing the total amount and the criteria but perhaps keeping the # of orgs loose. This would give the appropriate group or the applicants discretion to apply for different grant sizes according to their cost needs or according to how gas costs trend. This would also be fairer in that it wouldn’t discriminate as much according to who is “first in line” (it would in the sense that we have budgeted a fixed amount, but we could for example give a fewer $ amount to each project if we realize there are more eligible projects beyond say, 200)

Another important variable would be our timeline for L2 adoption

[abbey]

Hey @niloconthecob

@niloconthecob

We should be fixing the total amount and the criteria but perhaps keeping the # of orgs loose.

I don’t mind keeping the # of orgs loose. I think I was just using them as a metric to calculate the amount of ETH to distribute to the multi-sig. Would you say that $200,000 USDC is a good starting amount to test-drive the initiative?

@niloconthecob

Another important variable would be our timeline for L2 adoption

For sure. L2 integrations were being worked on for a bit by @igor, but are on pause to ship the Funding team’s MVP. I believe that it will be re-prioritized soon. We should consider this proposal as a temporary solution outside of our L2 roadmap!

[niloconthecob]

@abbey

Would you say that $200,000 USDC is a good starting amount to test-drive the initiative?

Seems like ~200 orgs at current gas prices sounds sensible. I guess I think about it like is this a deep enough sample from which we can learn? I would argue it is

[yorgos]

I think this proposal makes perfect sense and is no different than any traditional company subsiziding its first few customers, so that it has reference cases to point their next customers too.

Is 200 orgs a large enough sample size for testing the effectiveness of this initiative?

200 orgs definitely sounds like a large enough sample size, as long as their is a human approval process (to prevent, e.g. bots and malicious users from using up all the funds for “dummy” orgs).

In fact, I think it is more than enough and I would even consider making the sample size smaller, if the same budget could be used to ensure some high-profile projects would switch over to radicle. (quality over quantity).

What criteria do we want to introduce for reimbursement requests?

I would also leave this fairly open without strict criteria. Recent activity, number of contributors, issue activity are some of the things I would look at.