[Formal Review][RGP-22] - Start the Radworks Seed Network (RSN) Org

This is the official draft and Snapshot poll for RGP-22. Please formally review the proposal and vote in the Snapshot poll by :rotating_light:17:00 CET - Monday, February 26th :rotating_light:

Thank you for all your comments on the discussion thread. I incorporated your feedback and have adjusted this post accordingly.

Author: lftherios
Type: Org
Discussion: [Discussion][RGP-22] - Start the Radworks Seed Network (RSN) Org
Formal review: [Formal Review][RGP-22] - Start the Radworks Seed Network (RSN) Org
Created: 2024-02-12
Status: active


The purpose of this org is to provide seed node services that makes hosting and fetching content from Radicle simple & performant for any developer.

Annual Strategy & Quarterly Objectives

Q1 2024

  1. Hire two engineers and bootstrap the team

Q2 2024

  1. Onboard new engineers
  2. Launch a production-ready centralised seed node service providing storage for Radicle projects and bandwidth, that is available for both FIAT and cryptocurrency payments.

A centralised seed node service for Radicle refers to a web-based service or server that allows users to access and retrieve content from the Radicle network through a centralized point of access. An example from the IPFS ecosystem is Pinata.

  1. Conduct and publish research on decentralised alternatives for content retrieval and assess their feasibility.
  2. Evaluate the viability and technical direction of a decentralised seed node network for Radicle.

Q3 2024

  1. Hire new team lead to replace Ele
  2. Iterate on the centralised offering based on user feedback and improve it’s reliability and UX
  3. Publicly release performance and adoption metrics for the centralised offering.

Q4 2024

  1. Continue refining the centralised offering in terms of performance, features and pricing.
  2. If applicable (see objective 4-Q1-2024), launch the first incentivised testnet for the decentralised service.

Organisational Structure

I (@lftherios ) propose that I kickstart this team as Org Lead. The objective would be to swiftly onboard three senior engineers to commence work on this topic. This also includes identifying and hiring a future team lead (one of the three hires) who will eventually succeed me as Org Lead. I will remain in the assembly of the association and a signer on the multi-sig until at least the end of 2024 - and will work with the new Org Lead to draft the 2025 Org proposal.

With regards to the organisational structure I am planning to create a new Swiss Association (identical to what we’ve done with Public Goods Association for the Drips Org), with the following known and trusted Radworks contributors as members:

In addition, any income created in 2024 from the centralized service will be applied against any 2025 budget this Org requests from Radworks. In the scenario, that the income generated is higher than the proposed budget for 2025, we will discuss and vote here on the forum and the association members will implement the community’s decision.

The Org will license any code developed under a permissive FOSS license and make Better Internet Foundation owner of any future trademarks and domains.


Website: A new website will be set up.
Discord: A new Discord server will be established.
Radicle: A new Radicle repository will be created.
We will attend and present our work at all Radworks community calls.
We will share quarterly updates, as every other team.

Reasoning & Analysis

My primary rationale stems from the following observation:

Radicle’s gossip-based peer-to-peer network suffices adequately in terms of performance for individual / hobbyist users. However, when considering professional developers, performance & convenience become significantly more crucial. Thus, there’s a high likelihood of demand for self-hosted or third-party gateways.

This trend mirrors what has occurred with IPFS, Scuttlebutt, or any other peer-to-peer network that gained adoption.

Why (Likely) Two Services

When it comes to this audience I believe that is wise to offer two services. The centralised offering should target convenience, while the decentralised offering should target a blend of censorship resistance and performance.

My thinking is this:

  • If you care about convenience: Radicle + 3rd party seed node > Radicle + decentralised network of seed nodes > Radicle’s gossip based network

  • If you care about censorship resistance for the content of your app: p2p gossip > Radicle + a decentralised network of seed nodes > Radicle + 3rd party seed node > db operated by a company

With regards to the decentralised offering that I describe above, my hypothesis is that there is a large number of well funded crypto related applications and protocols that care about censorship resistance but are looking for something more performant than p2p gossip and something more decentralised than relying on a single seed node (3rd party or self-hosted). I also believe this proposal enables us to manage risk appropriately, as the centralised service path is fairly trivial and will give us the opportunity to explore more innovative approaches for node coordination (the decentralised service) simultaneously.

Focus & Separation of Concerns

Establishing a dedicated team for seeds, allows the protocol team to focus on protocol development and serve all node operators impartially. The new team can concentrate on user-centric aspects such as UX, onboarding, community support, and customer service.

Try before you commit

As @yorgos wrote on the original discussion, it is a well established pattern for many open source projects to offer a hosted service as a quick way for end users to get acquainted with the project and try it for themselves before they decide to self-host and deal with the operational complexity of self-hosting.

End users are generally comfortable using such hosted services because:

  • they can reduce the investment / learning curve on this new piece of software, as they have less to learn (i.e. it is not just “more performant”, it is also “easier to use”),
  • they can find out if it is a good fit to their problem faster,
  • it is a nice way to support financially the maintainers/creators of the project,
  • there is no vendor lock-in, as they always have the option of self-hosting.

Equally, I think this will also help node operators in deciding whether they want to be involved with running Radicle nodes, because before deciding to offer / sell any service it is important to understand the service / features / advantages of whatever it is you’d be selling to your potential customers. Not having to self-host, to find that out, makes that path shorter.

Timing & Strategy

With Radicle 1.0 a few weeks away we have to start considering new challenges and opportunities. Bootstrapping a new team is something that always takes a lot of time (at best weeks, more realistically months), so I think it’s wise to start now in order to have a service in the market by the end of Q2.

As @yorgos wrote above, with Radicle essentially not having hit general availability yet, moving forward with this initiative will essentially lay a much smoother onboarding path for new users, assuming this new org is more focused towards that.

In addition, there is currently no established node operators network, so there is essentially no established competition between different entities at this point in time. If this happened 6 months in the future, when some hosting companies might have started investing in “hosted Radicle” services for their customers, such a move might be seen competitive to those community members. Doing this now allows us to set a different stage so that doesn’t happen.

This new organisation can also contribute valuable work to the community by providing documentation, deployment scripts, and operational know-how for deploying Radicle in various environments, addressing the current lack of information and limited deployment options.

Finally, achieving the centralised offering is in my opinion well within reach, and I have a high level of confidence in our ability to swiftly deliver a great service. An initial centralised offering will provide the necessary resources and time to thoroughly investigate the demands and viability of the decentralised offering. While the decentralised option is more intricate and ambitious in nature, it strongly aligns with Radworks’ values and overarching goals. I also think that this is the most natural sustainability model for Radworks and I am excited for Radworks to move beyond its current form.

Reporting & Success Criteria

The main success criteria for 2024 should be to:

  1. build the 3-person team
  2. ship the v1 for the centralised RSN offering
  3. decide on direction for the decentralised offering and start executing (if feasible)

Later in the year we will provide a lot more detailed metrics for each service with a focus on performance, user adoption and revenue.

Timeline & Budget

I am requesting $544,520 to be paid fully in RAD. Using last 30 days’ average closing price based on Radworks USD Historical Data | CoinGecko that would mean 289639 RAD. Break-down below:

Total Budget $544,520
Marketing $65,162
Team Offsites $4,000
Accounting $7,678
Operational expenses $3,190
Contributors $464,789

Like the other Orgs in the Radworks ecosystem, the RSN Org will publish monthly financial reports on Radworks-granted funds spent and income created by the Org.

Fund Management

DAO funds will be received on a 3:2 multisig (Safe) with association members as signers.

The RSN Org - also the “Grant Recipient” of Radworks, if this proposal is passed - hereby agrees to use the amount granted by Radworks in support of fulfilling the purpose outlined in the “Purpose” section above. The Grant Recipient understands and acknowledges that the awarded amount may be used only for this Purpose. Furthermore, any part of the grant that goes unused in the calendar year outlined in this proposal (for 2024) will either be returned to the Radworks Treasury (by March 2025) or rolled over into and applied towards the Org’s 2025 proposal and future grant from Radworks.

Technical Implementation

The actual code will be added during the on-chain proposal.

Finally I would like to thank @yorgos @vanton @cloudhead and everyone else that participated in the conversations on the forum & Discord. I would also like to thank @ange for her guidance with regards to the operational side of this proposal.

This proposal started from a personal idea and was co-developed in the open based on all of your feedback.


Hey @lftherios ! Thanks for incorporating all of the feedback from the Discussion phase.

Re proposal code: When you have the multisig setup, will you please add the executable code to the proposal code archive for review? Please add the link to the proposal code here when it is ready.

Thanks for the updated proposal @lftherios !

I really appreciate the application of community feedback into this proposal. With the proposed signers, transparent financial reporting, and commitment to applying any generated revenue to the 2025 Org budget there are now clear accountability mechanisms in place that alleviate most of the personal concerns I shared in the Discussion phase.

As you generate these job descriptions, I would send them over to Ops so they can get it posted on the jobs board that is hosted by the Foundation!

Looking forward to getting this work started :call_me_hand:

Just a quick note to say that, with my public node operator hat on, I am in support of this proposal.

On top of this being an initiative I’ve already previously explained why I think it makes sense, there is one new point I absolutely :heart_eyes: LOVE :heart_eyes: about this proposal is the following:

The Org will license any code developed under a permissive FOSS license and make Better Internet Foundation owner of any future trademarks and domains.

This is especially unusual for service providers! Typically, service providers who make their money by offering a service on top of an open source project, they do so with closed source deployment scripts, pipelines, tests and ops code in general… In most cases, the project may be open source, but the service is closed source.

To hear there is such an intent (IF I am understanding the above text correctly) is a-ma-zing ! :clap: :clap:

… or am I perhaps reading too much into the above statement? :thinking:

(For more inspiration on this topic, please refer to Open Source Services )


You are reading this correctly :slight_smile: That is my intention with this piece of work.


:sparkles: Formal Review Results :sparkles:

This proposal has PASSED :white_check_mark: with 5M RAD in favor of the proposal. It will be submitted on-chain this week for a final vote.

See final results: Snapshot

1 Like

After much consideration I decided to wait until the next cycle to submit this for final vote, as I would like to have some more time to figure out some of the operational topics before I receive the funds.

Thank you all for your contributions and the support this proposal received! :pray: