[Discussion] Fund Radworks Dependencies With Drips - Proposal

[lftherios]

Author:	lftherios
Type:	Treasury Distribution
Created:	2023-07-14
Status:	active

Purpose

The purpose of this proposal is to allocate funds through the Drips toolkit, to support the critical software dependencies of our DAO. By providing sustainable financial support to these essential projects over the course of one year, we aim to foster their growth, ensure their continued maintenance, and fortify the overall resilience and success of our DAO ecosystem.

Details

I propose to allocate a total of $1 million in RAD and USDC, split between the two tokens, to fund our critical dependencies. This funding will be distributed over a period of one year, allowing for consistent and reliable support to the projects that are crucial to our operations.

Each organization within our ecosystem will create their own Drip Lists, specifying their selected dependencies and the percentage allocation, and the DAO will fund them accordingly.

With regards to tokens, I believe that using RAD and USDC in equal amounts is the right approach. USDC provides a reliable and stable income for the recipients, while RAD gives recipients the ability to participate in the decision making of radworks and shape its future.

Considering the estimated number of 30-50 projects as recipients (an estimate I got by talking to different org leads), the proposed $1 million funding has the potential to make a significant impact. By distributing resources through Drips, we streamline the funding process, eliminating unnecessary complexity and ensuring that financial support seamlessly reaches its intended recipients.

Objectives

The objectives of this proposal are as follows:

1. Ecosystem Resilience: Strengthening our critical dependencies is vital to the overall resilience of our DAO ecosystem. By ensuring the continuous support and maintenance of these projects, we safeguard the stability and reliability of our infrastructure. This, in turn, enhances our ability to fulfill our mission and serve our community effectively.

2. Collaboration and Interdependence: Through this funding initiative, we emphasize the spirit of collaboration and interdependence within our ecosystem. By supporting our critical dependencies, we acknowledge the significant contributions they make to our success. This fosters a mutually beneficial relationship where the success of our DAO is intricately tied to the achievements of our dependencies. In addition, we create an opportunity to strengthen our relationship with them and onboard them to our ecosystem.

3. Long-Term Sustainability: The allocation of funds over a one-year period demonstrates our commitment to the long-term sustainability of our critical dependencies. By providing consistent financial support, we create an environment where these projects can thrive, attracting additional contributors and establishing a foundation for their continued development and maintenance.

4. Drips Ecosystem Growth: By adopting Drips as the mechanism for this proposal, we have the opportunity to showcase its strengths and attract new users.

Drips’ features, such as per-second streaming, flexibility in token choice as well as its flexible identity model where funders can stream to any git forge url (in addition to an Ethereum address), ensure a streamlined and user-friendly experience for both our DAO and the recipients of funding.

Overall, this proposal embodies our commitment to the long-term success of our DAO and the interconnected projects that contribute to our achievements.

[bordumb]

It would be good if the wallet addresses involved and who they belong to are more explicitly noted.

Based on the title, this sounds like the funds for dripping is coming from the Radworks Org (i.e. NOT the Drips team).

If that’s the case, does it make sense to have this workflow?

• Radworks Org (treasury wallet?) configures splits to each sub-DAO (Drips, Radicle, Grants, Foundation)
• Each sub-DAO configures their respective splits based on dependencies
• Radworks Org drips $1,000,000 to each respective sub-DAO as dependencies
• The $1,000,000 is piped from Radworks, down to each sub-DAO, and then their respective dependencies

Note: in the example above, the Radworks Grants Org would only need 50,000 of the 1,000,000 (or 5%) as that’s what we originally planned in our Org proposal. So I could imagine a split like: 45% to Drips, 45% to Radicle, 5% to Grants, 5% to Foundation.

I know this requires more overhead, but it seems more aligned with what we’re trying to show people in terms of funding a network of contributors.

Compiling an off-line list of dependencies from each sub-DAO and bundling that at the Radworks DAO level feels a bit backwards and antithetical to the autonomy of each sub-DAO.

I would vote in favor either way, just want to share this thought to play devil’s advocate. I could argue for going ahead with this initial method, but iterate in the future using the idea I’ve written above.

[shelb_ee]

@bordumb re the workflow you proposed above - would it probably not be the case that some of the Orgs have the same dependancies so they would be funded twice/more than others? I guess this isn’t necessarily a bad thing, but just wanted to point that out.

Would an alternative be that each Org proposes a list of dependancies here and that list is then compiled/condensed & voted on by token holders? I think it would be important for the final list of dependencies that would be funded by this initiative to be included in the proposal before folks vote on it.

[bordumb]

I think it would be important for the final list of dependencies that would be funded by this initiative to be included in the proposal before folks vote on it.

I agree.

re the workflow you proposed above - would it probably not be the case that some of the Orgs have the same dependancies so they would be funded twice/more than others?

It most definitely is the case that some Orgs would have overlapping groups.

One could argue that we should be operating independently and not “peeking” at a list beforehand. This level of dogfooding could be a good forcing function for us to figure out how to manage that post-hoc. This is essentially the problem set all DAOs will be dealing with on Drips (how do I know how much funding a dependency needs? how should I consider my Drips given our DAO’s overlapping with another DAO’s? etc.).

FWIW: I’m totally cool with us “peeking” during this first round, just because it’s probably more efficient, less overhead. I would vote “yes” on this proposal.

But I’d probably argue that in the longer term, we’d want to move towards handling Drips independently of each other. I’m of the opinion that the best litmus test for decentralization is control over funds, so “peeking” beforehand sticks out as not being decentralized.

[andrewd]

Hey @bordumb and @shelb_ee – thanks for the great comments! Everything you said really resonates with me. Some more specific responses inline below:

If that’s the case, does it make sense to have this workflow?

• Radworks Org (treasury wallet?) configures splits to each sub-DAO (Drips, Radicle, Grants, > Foundation)
• Each sub-DAO configures their respective splits based on dependencies
• Radworks Org drips $1,000,000 to each respective sub-DAO as dependencies
• The $1,000,000 is piped from Radworks, down to each sub-DAO, and then their respective dependencies

I love this and agree that this seems like a great way to go.

@bordumb re the workflow you proposed above - would it probably not be the case that some of the Orgs have the same dependancies so they would be funded twice/more than others? I guess this isn’t necessarily a bad thing, but just wanted to point that out.

I actually wonder about this. I think that some orgs would have dependencies in common, but I suspect that they would tend to be mostly different. And if they do overlap somewhat, my feeling is that it may be okay, since that means that the dependency is being more heavily depended on in aggregate. What do you think? Out of curiosity, did you have a particular dependency in mind that you think might end up being over-funded?

This level of dogfooding could be a good forcing function for us to figure out how to manage that post-hoc. This is essentially the problem set all DAOs will be dealing with on Drips (how do I know how much funding a dependency needs? how should I consider my Drips given our DAO’s overlapping with another DAO’s? etc.).

I agree with all of this and I also think that “peeking” (i.e. open discussion between the different orgs of what they are considering funding) is important to allow in this round and perhaps for some time into the future. If nothing else, I think there is tremendous value to being able to have open discussion about some of the particulars and to be able to use specific examples to reason from in those discussions.

As an example of this kind of discussion, another question that each sub-DAO will have to answer for themselves is whether they want to take into account the amount of funding that the dependency may already have, when deciding whether and how much to fund them. As we all know, in general some projects are wildly under-funded, whereas others have plenty of funding or are even over-funded. This is a question that our team (as well as many of the funders we’ve spoken with from other teams) has struggled with somewhat and I think there are great arguments on both sides.

Would love to hear what you and other folks from the other sub-DAOs think about this question…

[ange]

I really appreciate this proposal and the hands-on approach of the Drips Org to onboard the wider community to Drips, emphasize the importance of dependencies within software development, and support our own dependencies in the process. It seems like a win-win-win.

@bordumb

• Radworks Org (treasury wallet?) configures splits to each sub-DAO (Drips, Radicle, Grants, Foundation)
• Each sub-DAO configures their respective splits based on dependencies
• Radworks Org drips $1,000,000 to each respective sub-DAO as dependencies
• The $1,000,000 is piped from Radworks, down to each sub-DAO, and then their respective dependencies

I also like this proposed workflow. Also, just for linguistic consistency: Drips, Radicle, Grants, and Foundation are Orgs that are part of the Radworks ecosystem and supported by Radworks Treasury (which isn’t an Org). Radworks is a community-governed network. @shelb_ee Please feel free to correct me

@shelb_ee

I think it would be important for the final list of dependencies that would be funded by this initiative to be included in the proposal before folks vote on it.

I also agree with this.

@andrewd

And if they do overlap somewhat, my feeling is that it may be okay, since that means that the dependency is being more heavily depended on in aggregate. What do you think?

I absolutely agree. If one dependency is shared by multiple parts of the Radworks ecosystem, I don’t think that funding it (via this proposal) multiple times is a bad thing. In fact, if the Radworks ecosystem has a common strong dependency, we should support it more. But I think these shared dependencies should be identified and there should be a discussion with them about their need for such funds. This is a good chance to strengthen Radworks’ relationship with this (important) dependency and work with them to identify its own dependencies and setup splits for the (comparatively large amount of funds) they would receive.

@andrewd

I agree with all of this and I also think that “peeking” (i.e. open discussion between the different orgs of what they are considering funding) is important to allow in this round and perhaps for some time into the future. If nothing else, I think there is tremendous value to being able to have open discussion about some of the particulars and to be able to use specific examples to reason from in those discussions.

@bordumb

But I’d probably argue that in the longer term, we’d want to move towards handling Drips independently of each other. I’m of the opinion that the best litmus test for decentralization is control over funds, so “peeking” beforehand sticks out as not being decentralized.

I’m not quite understanding what it means to “peek” and why it’s potentially a bad thing. My understanding of the “Awesome Lists” feature is that it already provides a very simple way to “peek” and have some of these conversations about how or why to send funds to particular projects, at a high-level (e.g. a reputable contributor actively curating an “In Need” Awesome List). And the Drips App would already make it clear who the Radicle Project has identified as a dependency - and that’s a transparency feature of the product.

So isn’t Drips built on the assumption that “peeking” is important?

@andrewd

whether they want to take into account the amount of funding that the dependency may already have, when deciding whether and how much to fund them. As we all know, in general some projects are wildly under-funded, whereas others have plenty of funding or are even over-funded. This is a question that our team (as well as many of the funders we’ve spoken with from other teams) has struggled with somewhat and I think there are great arguments on both sides.

I think (I hope!) this dissemination of funds to the Radworks ecosystem’s dependencies will be a practical way of working through these critical questions alongside many different projects.

[shelb_ee]

@lftherios as it seems multiple folks in the comments so far agree that it would be a good idea to have a list of dependancies included in the proposal before folks vote on it, do you have a plan to try to get these lists together before the proposal goes through Formal Review (incl. Snapshot poll) next week?

[andrewd]

@lftherios as it seems multiple folks in the comments so far agree that it would be a good idea to have a list of dependancies included in the proposal before folks vote on it, do you have a plan to try to get these lists together before the proposal goes through Formal Review (incl. Snapshot poll) next week?

The Drips team discussed this this week and we agree that it would be great to share the dependency lists ahead of the vote! We also like @bordumb 's suggestion that each sub-DAO should independently determine and share their own lists.

With all of this in mind, would the sub-DAO leads be up for sharing the proposed dependency lists for your sub-DAOs here in the comments? @lftherios @cloudhead @abbey @ange

[shelb_ee]

Got it, thanks @andrewd! I also think this makes sense. My only concern is time, as this proposal is mean to move to Formal Review (Snapshot vote) on Monday, August 14th. Would be curious to see if Orgs think they can get a list of dependancies together by then.

[shelb_ee]

Proposal Review Reminder​:classical_building:

Join the Proposal Review call TODAY - Wednesday, August 9th at 5pm CET / 11am ET. As this is the only proposal for this cycle, the call will focus on discussing this proposal! The proposal author (@lftherios) will be on to present and answer questions.

Call details can be found in this Discord invite: Radworks

[abbey]

Super exciting proposal @lftherios! Thanks for posting.

Generally, I am very supportive of the concept. I believe that Drips can be a new tool for embedding resilience within open source ecosystems and experiments like these are a perfect way to start demonstrating that. I have a couple of questions about implementation that would be great to discuss here and during the proposal review to ensure an effective Formal Review.

First, I’d like to highlight that it’s highly recommended to have a draft of the proposal code included when this proposal moves to Formal Review. With that in mind, what will the actual proposal look like?

@bordumb

If that’s the case, does it make sense to have this workflow?

• Radworks Org (treasury wallet?) configures splits to each sub-DAO (Drips, Radicle, Grants, Foundation)
• Each sub-DAO configures their respective splits based on dependencies
• Radworks Org drips $1,000,000 to each respective sub-DAO as dependencies
• The $1,000,000 is piped from Radworks, down to each sub-DAO, and then their respective dependencies

“Configuring splits” is a contract call right? Does this mean the Treasury will be interacting directly with the Drips contracts to coordinate the first split to each Org? If so, are there any risks that should be taken into consideration with this approach? cc @andrewd @lftherios

@andrewd

I agree with all of this and I also think that “peeking” (i.e. open discussion between the different orgs of what they are considering funding) is important to allow in this round and perhaps for some time into the future. If nothing else, I think there is tremendous value to being able to have open discussion about some of the particulars and to be able to use specific examples to reason from in those discussions.

I definitely agree that the dependency lists should be made public and open for discussion before Orgs configure their own dependency splits! I think the question is if token holders should have any “say” in what dependencies are funded. IMO, Orgs should reserve the right to define their dependency lists, but should do so in a transparent manner, so token-holders can observe and voice in the case of mismanagement (e.g. siphoning funds, fake dependencies etc…).

@lftherios

This funding will be distributed over a period of one year, allowing for consistent and reliable support to the projects that are crucial to our operations.

After the streaming period concludes, is the expectation to continue dependency funding into the following year?

@lftherios

With regards to tokens, I believe that using RAD and USDC in equal amounts is the right approach. USDC provides a reliable and stable income for the recipients, while RAD gives recipients the ability to participate in the decision making of radworks and shape its future.

I agree!

So, moving into the Formal Review next week I think we need to see the following:

• A more detailed implementation plan, including proposal code
• Draft dependency lists for each Org*

*IMO these can totally be subject to change because I think each Org should reserve the power to manage their own lists, BUT I think it’s important for token-holders to have some understanding of what kind of dependencies will be funded via this proposal before voting

[shelb_ee]

@ange

Also, just for linguistic consistency: Drips, Radicle, Grants, and Foundation are Orgs that are part of the Radworks ecosystem and supported by Radworks Treasury (which isn’t an Org). Radworks is a community-governed network. @shelb_ee Please feel free to correct me

Yes! This is correct @ange! Thank you for highlighting.

[shelb_ee]

Hey folks! Just had a great Proposal Review call discussing this proposal. I will share the recording and a brief summary tomorrow, but wanted to share one topic that we wanted to bring to the forum for discussion that hasn’t been discussed yet and would be helpful to clarify before writing the final draft of the proposal.

In regards to splitting of the $1M RAD/USDC, how do folks feel the funds should be split between each Org? Some examples discussed on the call:

• All equal % split
• % based on proportion of funds allocated to each Org in the annual Org proposals
• Higher % for product Orgs who have clear software dependancies vs Foundation or Grants
• Should the Foundation Org be included? Or should the funds for dependancies be distributed amongst Orgs who have clear dependencies in this version of the proposal (i.e. Radicle, Drips, Grants)

Curious to hear thoughts, comments and questions on this topic before the proposal moves to Formal Review Monday.

[shelb_ee]

Proposal Review Notes & Recording

As promised, here is summary of main discussion points & questions on this proposal from the Proposal Review call yesterday. You can find the call recording here!

• Proposal Code - what will the contract calls be? Are there risks to be aware of?
  • Code will transfer 1M out of treasury & deposit into Drips protocol contract, create a dependancies list (made up of org lists), and start streaming into each Org lists
  • Fairly low risk, but still want to outline more clearly what the review process for the proposal code will be and model & run on testnet to prep (ok if this happens during Formal Review)
• Org Dependency lists
  • Drips already has a list together and has been in contact with other Org leads about theirs
  • There was a discussion around if these lists should be able to be changed over time or not. There seemed to be consensus that Orgs should be able to change the lists, but there should be a clear process around how and why, as well as how it will be communicated with the community for transparency
• Splitting of funds: (pasting from previous comment above)
  • In regards to splitting of the $1M RAD/USDC, how do folks feel the funds should be split between each Org? Some examples discussed on the call:
    • All equal % split
    • % based on proportion of funds allocated to each Org in the annual Org proposals
    • Higher % for product Orgs who have clear software dependancies vs Foundation or Grants
    • Should the Foundation Org be included? Or should the funds for dependancies be distributed amongst Orgs who have clear dependencies in this version of the proposal (i.e. Radicle, Drips, Grants)
  • Consensus of folks on call was that the fund split should be more focused on Orgs with clear software dependancies (which at the moment are the two product Orgs (Radicle & Drips) and possibly Grants, but not so much the Foundation Org).
  • Could also consider reducing the $1M if less Orgs are included? Argument being wanting to keep more USDC in the treasury.
• What happens after the funds have been streamed / does the support process for recipients of the funds being streamed look like?
  • The Drips team already has been in contact for folks on their list and has an outreach plan to get in contact with recipients from other Orgs’ lists once there has been a decent amount streamed. They will help recipients onboard and claim their funds.
• Is there anything you need support on or would like input on from the community?
  • Andrew: It would be great if Orgs could share more about their process on how they decided on dependancies for their Drips lists.

Recommended additions/clarifications to the next draft of the proposal that were discussed:

• Add proposal code & review process for code
• Clarify what Orgs are being included and why
• Include % of split across Orgs and average stream per dependency
• As there seemed to be consensus on the forum that duplicates of dependancies for different Orgs are ok - clearly state that & provide reasoning around why
• Include dependency lists from each Org that will be included (ask Org leads to give brief explanation of process for choosing dependancies)
• Clarify that a list can change & explain process for how/why and how communicated with community
• Clarify that dependancies on Org lists should be external recipients (outside of Radworks ecosystem) to avoid conflict of interest
• Explain how dependancies will be notified and supported after the streaming starts to make sure they know how to claim funds
• Fix proposal title to match format in Governance Manual: [Discussion/Formal Review/Submission][RGP - #] - [PROPOSAL TITLE]

[Lfada]

@shelb_ee

Explain how dependancies will be notified and supported after the streaming starts to make sure they know how to claim funds

Thanks for sharing this, @shelb_ee! Wanted to shed some light on this. Here’s the high-level process we have in mind:

• Our Partnerships lead will reach out to each project or maintainer using their preferred communication channel (tw, gh, email, etc). A set of scripts have been crafted.
• The aim is to inform them about the funding they’ll receive and provide some context about our work and sources of the funding.
• We’ll offer assistance in getting started, onboarding, and addressing any inquiries they have.
• Once they claim those funds (or if they decide not to), we’ll conduct a user research session or questionnaire to gather feedback.
• This feedback will help us identify strengths, weaknesses, and opportunities for improvement in our approach.

Fairly standard process for any user-facing initiative, and it will probably evolve. If you have any suggestions, please let us know

[lftherios]

Thanks you all for your comments. I’ve incorporated all feedback and posted for formal review here: [Formal Review][RGP - 16] - Fund Radworks Dependencies with Drips