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 treasury reimburses developers that start a Radicle Org from a multi-sig, so it becomes free for them to do that.
What I am proposing is creating a multi-sig and manually and transparently doing the above. The process could look like that:
devs start a Radicle Org and anchor at least one of their projects
devs join a discord or matrix channel for reimbursement and share their repo and tx hash for the creation of the org
multi-sig reimburses as long as it’s a real project. Important here to keep this last step very light. Ideally no question asked as long as there is a real human behind the project.
Open question
Should there be some upper limit on how much money can be sent in that reimbursement process?
I think it would make sense to have 3-5 individuals that have demonstrated their commitment to Radicle by participating actively in the community over time and are interested in helping with the verification. @abbey@bordumb@viraptor@cloudhead@larry@derek are some names that come to mind.
For amount, I would approach it the following way:
snapshot is a tool that has significant adoption with DAOs. It currently shows that there are 1.7k DAOs using it Snapshot so it’s fair to assume that there are roughly 1.7k active DAOs out there. Another way to approach that would be to look at Gnosis multi-sigs, but not sure if there is a number out there. Any folks from dxdao that might know that number out there?
we need to come up with an estimate of tx costs for org creation today. any help there is appreciated.
then I would calculate “amount of DAOs” x “avg tx cost”
then maybe add a premium so we don’t need to do this frequently (maybe 2x the above amount or more).
I like this idea.
Some notes below on why I am not too worried about fraud.
On the topic of fraud, I’ll just say I’m not too worried about it in this case (so long as we have some reasonable checks). I’ll just share a few tangential anecdotes:
Gift card fraud is pretty common in markets where the local currency is not very stable or weak relative to another currency. The “fraud” here is usually a case where people buy a giftcard in one country, then sell it online to someone in another country for some stable currency like the USD. Effectively, the use the gift card as a medium for foreign exchange arbitrage. The fraudster has some overhead, but can make money on this arbitrage.
Another common fraud I’ve seen is with referral bonuses. For example, if user A refers user B, they get $X as a referral bonus. In these schemes, it sets up incentives for user A to refer a lot of “fake” users. The fraudster has some overhead, but can get $X per referral.
In most cases with fraud, the important factor is:
The fraudster is getting more benefit in return for their own costs (they have positive ROI)
Based on what @lftherios posted, I don’t see any real incentive to commit fraud.
The users have to pay RAD, then go through a check by one of us to be reimbursed for that RAD. And the only benefit is being repaid the RAD they paid in the first place. So their net cost/benefit is technically $0 + free Org creation / the overhead of going through the process.
For people who truly need the Org, their net benefit will be $0 + the free Org creation.
For anyone who is attempting to commit fraud, their net benefit will be $0 + the time/effort to create an Org. So anyone fraudsters would actually be losing out in this scenario.
Do we want to have some sort of cut-off for this or do we want it to be indefinitely free?
Like, would we want this to be free for the first 1000, 2000, 5000 orgs?
If I had to guess, the highest quality Orgs will be the ones who sign up first.
Like, I can’t remember ever seeing a product where the first people to adopt it aren’t also the highest quality users (anyone else?). If I had to guess, anyone after 5,000 or so will be a long tail of lower quality users (i.e. don’t use all the features, aren’t actively developing, etc.)
Having a limit would also help with budgeting, for example:
If the limit is 5000 and the cost is $100 per Org
We know our upper limit for funds is around $500,000
And I suppose we could always turn it back on.
For example, say “We will be refunding the first 2000 Orgs to start.”
Then revisit the idea whenever we surpass that.
If there is still a lot of demand, then we restart it.
And if people are happy to pay, then we don’t.
Or we can also pivot it to something that is more needs based later on.
I could imagine Radicle having part of the treasury go towards supporting developers who are working on special projects, whether they be charity type work or some sort of needy/at-risk projects.
The idea of subsidizing the creation of Radicle Orgs strikes me as a no-brainer. I strongly support the creation of a multi-sig that covers the cost of admission, particularly for early users who are likely to stick around (see @bordumb’s excellent point on the matter). I’d be thrilled to sit on the multi-sig too.
The upside is more people try and use Radicle Orgs, which in my mind, is the definition of success.
The downside is the protocol pays for the formation of Radicle Orgs but users don’t end up using them. If that happens, the protocol will have learned a valuable lesson — either 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.
On the question of how much RAD to fund the multi-sig with, I think it’s better we fill it with more RAD than less RAD. If we find ourselves in the position of having more RAD than needed, we can always send it back to the treasury. In my mind, this is a far better outcome than the inverse: not having enough and needing to go back to governance for a time-consuming “refill.”
Nice to hear that the idea resonates with a lot of folks.
I don’t have a strong opinion on limit of orgs. We would anyways need to go iteratively and evaluate how this initiative is performing within a reasonable timeframe, so I am totally ok with having (a generous) limit to start. Timeframe could be a month or a quarter.
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 ETH per org as a ceiling/max, the average being less of course.
So if we multiply this by 1700 orgs, we get 340 ETH as the maximum we should allocate for this project. Now, that is a considerable amount of money, so perhaps we can offer this only to the first 1000 orgs?
Great initiative @lftherios! I think this is a great idea to support adoption of Radicle Orgs.
Based on @cloudhead’s calculations I think the first 1000 Orgs makes sense. Although, I’m wondering if we should include setting up ENS names - my gut is it will be too hard to track all the transactions associated with setting up the ENS name (registration, setting it to an org, updating records etc…). Interested to know what other people think here. I’d like to highlight that this is sort of related to another active Temp Check. Reducing the name registration fee would probably be enough to make the ENS registration process easier, and we could let this process be specifically about costs associated with Org Creation.
In terms of execution, I have a couple thoughts…
I think having the program run for a certain amount of time & for a certain amount of Orgs is a good idea. Maybe we limit it to a quarter or 1000 Orgs - whichever comes first?
Reimbursement requests will be too hard to track if they are via Discord/Matrix. I’d rather have an Airtable form that collects all the information and organizes it. The process can be hosted in a README in a Radicle repo and anchored to an Org. This will also give us a better way to track how many Orgs we’ve reimbursed.
Weekly reimbursements? Should set a time in which the transactions are made, and put someone in charge for submitting them.
The multi-sig could manage a Radicle Org that manages a repository with all relevant information. We could update this repository as the multi-sig distributes funds and even log all of the data from the airtable form for transparency sake
Ideally, we track the amount of Orgs created week to week via the Airtable form so we can try to evaluate the efficacy of this initiative. We can use this data to objectively re-evaluate if the program should be continued post- 1000 Orgs.
Happy to sit on the multi-sig and probably would like to see @nas there too as he’s leading the Growth Workstream in the Governance Working Group which is really relevant to this proposal.
I haven’t looked at the contract on how Radicle Orgs are created so I am kinda shooting a suggestion blindly. I apologise in advance.
how easy would it be to upgrade the contract to create new orgs by providing a wallet signature - this would null and void the need for reimbursements.
I’ve suggested this in another post and this discussion is similar so, now I’m wondering whether this has been thought of already.
Also, before a reimbursements program, I think sorting a treasury mgmt solution might be a priority? For example, I was on a gov call in ARCx community this week and they had their treasury mgmt liaison (llama community) giving updates about their treasury.
This would be possible, but I think the proposal here suggests that we can’t simply trust this to an automated flow. Ie. we want to be able to not reimburse certain orgs if we see that they are just taking advantage of the system.
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 ahead of the launch of contribution features.
We reduce the number of orgs we fund to 100-200, with a focus on larger and established projects that we are setting up a more meaningful partnership with.
If we agree with this, I believe the next steps are getting this setup.
create a gnosis multisig with myself, @abbey, @cloudhead - anyone else? can add others that are onboarding DAOs when needed?
get approval from the treasury via a snapshot poll to then send funds to multisig
when partners complete their setup someone on core team (probably me) will read the transactions made by org creating wallet and calculate the reimbursement. Can’t ask teams that are already doing a bunch of setup schlep to add more imo.
A record of wallet, transactions, and amount can then be added to an airtable or repo for transparency and record keeping.
ideally the multisig would have a 1 of 3 quorum on it as we should reimburse teams asap imo + in some cases I think it’s best to send them funds while they’re doing the setup on a call as getting the right wallet and funds sorted can add 20 mins to a setup call that is already fairly chunky.
What’s the best way to take this to a vote and setup? I’m happy to create multisig and add members. How do we format things to take to snapshot vote?
] Treasury Covers Costs for Creation of Radicle Orgs