Proposing the Polkadot Tooling Collective (PoToC)

Polkadot Tooling Collective

This document proposes to the Polkadot tokenholders the inception of a new System Collective: The Polkadot Tooling Collective (PoToC).

After a formation period to establish members and display effectiveness, the collective will request funds from the main treasury to support a salary structure and sub-treasury. These ideas are laid out in the Phases section.


Thanks to Joe for helping with writing this and to Bryan and Nikos for feedback.

This proposal is uploaded to the Collectives chain, hackmd, gist and the archive.


The Polkadot Core Fellowship is currently the only System Collective for developers. This makes it the go-to spot for new developers who want to join Polkadot - regardless of the field in which they want to work.

The scope of the Core Fellowship is rather narrow, focusing primarily on implementations of the Polkadot Host and runtime code. But many developers are working on tools related to making Polkadot successful, both the maintenance and development of the core protocol and the libraries and abstractions for dApp developers. These developers often find that their contributions are not recognized within the mandate of the Core Fellowship.

But the system can host many collectives. The Core Fellowship should be just one of many Collectives that serve Polkadot in different ways. Each has its own set of members, scope, and expertise levels.

Having a narrow scope is critical for a Collective to ensure that it can fulfill its mission. Widening the scope leads to a softening of its direction and social cohesion and possibly a loss of vision.

The Polkadot Tooling Collective will serve Polkadot by recognizing and retaining developers who make significant contributions to tools and libraries that make Polkadot easier to maintain, use, and integrate.

The Mission

The Polkadot Tooling Collective acts in the best interest of Polkadot. It tries to have a positive impact on developer success in the Polkadot Ecosystem and intends to do this by working towards two main goals:

  • To maintain developer tools to build Polkadot itself (Core Tooling)
  • To maintain developer tools to build on Polkadot (dApp Tooling)

Since these definitions are not sufficiently precise, an exhaustive Mission List is provided by PoToC. This Mission List is the only source of truth about its mission.

Similar to the Core Fellowship, one of PoToC’s goals is to recognize and retain developers who make substantial contributions to these areas. Specifically, the collective should focus on people who have contributed to the specification or implementation of Polkadot tooling. Having an on-chain body will provide a means for these developers to align and organize.

PoToC may want to apply for treasury funding in the future; it is therefore clear that any infringement upon its mission statement must be treated as an attempt to exfiltrate governance funds.

Mission List

The Mission List contains all projects and services that are maintained by PoToC.

It is divided into two sections, solely to keep the requirements of each section clearly defined; Core and dApp. It can be updated through an on-chain 2/3-majority rank-weighted vote across all Members.

Some obvious cornerstones that must be upheld by all projects are:

  • Must be FOSS (Free and Open-Source Software).
  • Source code must be accessible without a login requirement.
  • All members of PoToC must have permission to propose changes and raise issues.

The Mission List will be defined as part of the initial seeding.

Core Tooling

Generally, all tools that are used by The Fellowship to craft, test, and validate updates fall into this category. But only the tools that are predominantly developed for this cause shall be maintained by PoToC. For example, the Rust language is not predominantly developed for Polkadot; hence, it does not fit here.

dApp Tooling

This category contains all tools and libraries that are used to build on Polkadot and are predominantly developed for this cause.


The initial structure shall be as minimalistic as possible, to limit maintenance and social drama. This has the downside of being less resilient against foreign takeovers, but in the beginning, I think it is fine to rather focus on social cohesion.

There is no differentiation between maintainers of “Core Tooling” and “dApp Tooling”. They both share the same set of members and rank structure. These terms are only used to clarify the mission goal.

Rank 0 - Candidate

Developers who want to join can be inducted by any Member into this rank. A vote for promotion to rank 1 can be started not earlier than six months after being inducted.

They are expected to be a maintainer for one of the tools on the mission list.

  • Voting weight: 0
  • Salary mult: task-based bounties

Rank 1 - Member

Members are expected to keep up the maintenance of at least one tool from the mission list. This includes extending them and creating new tools that are needed by the Polkadot developer community.

  • Voting weight: 1
  • Salary mult: 0.1 + task-based bounties

Further Ranks

The initial member seeding will show how many ranks need to be created to arrive at the correct granularity. The requirement for adding new ranks is that they are absolutely necessary.

We do not want to end in a situation where ranks are purely added to show off.

Salary Structure

There is no initial salary or bonus structure. In the future, after PoToC proves itself worthy, it is proposed to set up a bounty-centered pay structure.

Different tiers of bounties shall be defined, and a fairly low baseline salary will be paid to all members. This is done to provide an incentive for improving the tooling instead of sloth.

A member may apply for a specific bounty while providing evidence of fulfilling the bounty requirements. Granting of a bounty will be decided upon by a 50% on-chain vote. A cap on the monthly bounty payout should be established to prevent runaway spending and prioritize important changes. Bounty votes may only commence once per month to ease coordination between the Members.

The exact constants for the size of the bounties and baseline salary will be proposed through a secondary document in Phase II.

Initial Members

There shall be a seeding repo that allows anyone to apply to a rank. Applications should include a list of tools and contributions that show their past commitment to Polkadot tooling development. The applicant must justify why they are a good fit to join PoToC.

Eventually, there needs to be a social consensus on the initial set of members. This set would then be proposed to the tokenholders, either as part of the PoToC proposal itself or as a separate referendum.


There are a lot of questions unanswered by this document. In the beginning, we will use the Core Fellowship as a guiding light for processes and ethics as much as possible. Eventually, PoToC would develop its sub-culture (pun intended) and show more of its own identity.

A rough mid-term plan could look like this:

Phase I - Setup

This phase is for setting everything up and getting it enacted on-cain. It should take at most 6 months.

  • 1.1 Contacting all stakeholders: Tokenholders, Seeding members, and The Fellowship.
  • 1.2 Pitching the proposal to the community and incorporating feedback.
  • 2.1 Crafting a preliminary implementation to ensure that all important parameters are mentioned in the proposal.
  • 2.2 Binding governance vote via Wish-For-Change track. This is treated as the final signal on whether to pursue it or not.
  • 3.1 Final implementation and approval by The Fellowship.
  • 3.2 Enactment on-chain and beginning of operations.

Phase II - Probation Period

PoToC starts operating in a risk-reduced mode without governance funding. This phase will be used to evaluate the effectiveness and impact of PoToC.

Hopefully, the general public will deem it useful and approve of its future funding requests.

This phase should take from 6 months to 1 year.

Phase III - Business As Usual

PoToC enacts its salary structure. The creation and granting of bounties starts and attracts new developer talent.

This will demonstrate that creating a System Collective can be done by anyone, and hopefully inspire the wider community to further its decentralization efforts in that direction.


Hello everybody,

At R0GUE we are making a big effort on improving the DevEx the ecosystem offers to builders through our two Pop initiatives. Given that pop-cli highly aligns with PoToC’s mission, we are keen on joining forces with other teams and individuals in the collective.

We look forward to working together with other interested parties on making this happen.

Please, feel free to ask us anything at or Telegram: Contact @go_r0gue, or in this very same thread.


This sounds like an amazing proposal @OliverTY.

As someone from the Engineering Automation team who developed some sites and lots of tooling used by the fellowship’s runtimes (and the SDK), the idea of having a collective makes me feel very excited!

I often try to work on improving our DX, though I usually find myself interacting in many one on ones with developers to ask for feedback, while having a place where many stakeholders are available would facilitate this process, both for us and for external individuals.

I’m looking forward to the results of this proposal and very keen to collaborate as much as possible!


Generally very supportive of the idea. The main issue acknowledged here is something that I resonate with, it is time to resolve it:

…These developers often find that their contributions are not recognized within the mandate of the Core Fellowship.

Drawing further on what you coined “Core Tooling”, to further clarify the scope, I suggest considering removing the following (see here) from the core fellowship, either now or later, and make it be solely part of the PoToC:

  • user-interface code required to practically execute upgrades to the Polkadot (Main) Network; and
  • code or technology required by, and utilised primarily for, any code or technology already included.

I think the definition of what is required to execute upgrade upgrades is fuzzy, and falls more reasonably in PoToC rather than core fellowship.

In the most extreme case, I could argue that all that is needed to do basic interaction with the Polkadot network and execute runtime upgrades is merely having a computer with curl and access to the internet to execute transactions.

Some tools in each category that come to my mind (personal opinion):

Core Tooling: Low level RPC/Chain APIs, such as PJS-API, SubXT, substrate-py-interface. PJS-Apps or an equivalent “developer console” UIs(see here), Metadata Portals, Block Explorers. (Hardware) Wallets/Dashboards that provide at least (cross chain)transfer functionality, and/or ability to interact with core Polkadot features, such as Staking and Governance, Multisigs and Proxies.

dApp Tooling: Faucets and Test networks. CLIs. Notification services. Portfolios. Analytics dashboards. High level libraries.

I think the main bottleneck is to come up with a definition of what counts as “Tooling” for either Core or dApp. The distinction between the two can be something that is later fleshed out by the collective itself. I hope my list above helps with that.


Applications for the Polkadot Tooling Collective are now open :tada:
Please read the constitution and note that we only look for Senior Devs who contributed in the past to the mission. For example: PJS, Subxt, Chopsticks… etc.
More junior applications can follow in the next phase.

The current state just allows manual YAML file editing or a convenience CLI. @wirednkod is building a Website with nice application form - so if you can wait till EOW then you can use that instead :smile:


From the Front end & Integrations team at Parity we can add our extensive experience in building tooling to make the Polkadot Eco more accessible. Currently, we play a critical role in this regard by maintaining and actively developing PJS (the entire project), Subxt, API Sidecar, Substrate Connect and Asset Transfer API among others.

I am personally happy to help by refining the Mission List and setting up the initial phases of PoToC. Count me in.


As @OliverTY mentioned the front page for the Tooling Collective is now ready and can be seen here:

Anyone who thinks that had contributed in the past with tooling etc can use the newly created application form:

to construct the said YAML file easily:

and then open a PR to the Tooling collective repository with the generated YAML file.


Hey everyone! Nico here from Velocity Labs.

The gaps in both tooling and token infrastructure were some of the motivations for us to start Velocity. As we continue to build our technical team and begin contributing to both in-house and existing tools, we would be happy to join the PoToC.

Our first initiative towards this goal is the DeFi Infra and Tooling Bounty, which was recently funded and will soon begin accepting applications. With curators from longstanding parachains, we aim to provide firsthand insights from the parachain teams who will ultimately be users of some of the tooling being developed through the bounty. Additionally, we’ll implement a milestone-based approach to ensure that the end product meets the expectations set from the beginning. By having a technical curator set, we’ll be able to better assess the value of existing tools and make more educated decisions on which tools should continue to be maintained and which shouldn’t.

We aim to simplify the process for teams looking to develop tooling solutions on Polkadot, ensuring they have better support from idea generation all the way to GTM and maintenance. We hope this approach will result in better tooling for the ecosystem.

Given the focus and parallels with some of our initiatives, we think Velocity can contribute with some of our experiences and resources to the PoToC.


Thanks for the reply @alejandro and @nico_a!

Yes i hope that we can somehow bundle our interests and work together towards this common goal. I will invite you to the channels, once everything is set up.
The mandate of PoToC is not finalized yet, so there could be the possibility of integrating sub-collectives (eg. legal entities) into it.

1 Like

Awesome initiative @OliverTY / @wirednkod :raised_hands:, I think capture and incentivize all the work done (and to be done) in the tooling around the polkadot ecosystem.


1 Like

Great to see initiatives like this gaining momentum. I’ve always been interested in building tools that benefit & help other developers. Would be keen to follow this development and collaborate if possible :smiley:

I’m actually in the midst of developing a library that aims to improve DX for front-end developer working on Substrate DApps.

1 Like

Hey Hey, this sounds like a brilliant initiative.
Is anyone from you joining Polkadot Decoded?

There is a Polkadot Community Hub Space which reserved a slot for (originally folks working with javascript in polkadot) but could be extended to general tooling. I am one of the organisers.
The event is happening on tge 11th from 3pm-4pm.

Would be great to see some of you there to discuss this topic in person and maybe get to know each other :slightly_smiling_face:


Yea I will be there and plan to checkout the event :smile:

Nice! This looks like a good fit for PoToC :rocket: We can setup a vote for admission once everything is live on-chain.


I will be joining as well Decoded and also plan to checkout the event :muscle:

1 Like

is there a way to reach you or others on telegram, matrix or discord? :slightly_smiling_face:

You can find Oliver, myself and the rest if you join the Element channel here.