Threshold
Thank you, Alex, for your feedback.
I have presented what I believe to be my most valuable contributions. While my work has not directly contributed to the Polkadot SDK itself, I have developed and contributed to several pallets that have been used in proof-of-concept projects, are running in production on our parachain, or have been designed to enable real use cases on Substrate:
Additionally, the solution architecture and their underlying use-case for all of the pallets in the following repository were designed by me, even though the execution and development were carried out by my team:
I still believe that the client library and the Polkadot SDK for Unity have the greatest impact on the Polkadot ecosystem, as they provide essential tooling for developers and drive mainstream adoption by enabling the integration of Polkadot into gaming environments.
I have to agree with Alex. The contributions outlined here are out of scope when it comes to the Fellowship, which only covers core of the Polkadot and not the ecosystem as a whole. It's not an issue of whether they're valuable or how impactful they are, and this is not a value judgement on our part - the rules of the Fellowship simply say that we're not allowed to accept them as evidence.
Thank you for your feedback, Alex and Jan.
I understand that the Fellowship’s scope, as outlined in the manifesto, currently excludes client libraries and ecosystem tooling from being considered core contributions. However, I strongly believe this is a limitation that should be re-evaluated for the long-term health and growth of Polkadot.
The manifesto was written with a clear purpose: to ensure that the Polkadot network retains, incentivizes, and recognizes expertise critical to its continued operation and improvement. While the focus on protocol-level contributions makes sense, it also overlooks a vital component of the ecosystem—the tooling and infrastructure that allow developers to actually interact with Polkadot’s core technology.
Without client libraries, SDKs, and essential tools such as:
and others, the Polkadot SDK would remain largely inaccessible to builders. These components are not just "nice-to-haves"; they are the interfaces, the gateways, and the doors to the Polkadot SDK. They enable widespread developer adoption, integration into real-world applications, and ultimately, the mainstream usability of Polkadot.
If the goal of the Fellowship is to recognize and retain expertise essential to Polkadot’s long-term success, then the exclusion of those who build these foundational tools is a significant oversight.
I believe it is time to consider an amendment to the manifesto that formally acknowledges the importance of client libraries, ecosystem SDKs, and interoperability tools. Without these, Polkadot remains an isolated system with barriers to entry. If we only recognize protocol developers but not those who build the necessary interfaces, we risk alienating the very builders who enable real-world adoption.
I would welcome a discussion on how the Fellowship can evolve to recognize these contributions while maintaining its core principles. I am happy to contribute to shaping this conversation further.
If the goal of the Fellowship is to recognize and retain expertise essential to Polkadot’s long-term success
That's not the goal of the Fellowship. (: We don't have to speculate here; the manifesto explicitly says what is the goal:
"goal of the organisation is [...] that of building technical knowledge critical for the continued existance and evolution of the network protocol itself."
the exclusion of those who build these foundational tools is a significant oversight
It's not an oversight; it's a deliberate decision to keep the Fellowship focused.
Let me give you a real life analogy. Let's say you're a a wall painter. And you apply to join the American Society of Plumbers, because, well, both wall painters and plumbers are needed to build a house, right? And then you get rejected because you're not a plumber. So what do you do? Should you lobby the American Society of Plumbers to also include wall painting into its scope and accept wall painters as its members? Or maybe you should join the Painting Contractors Association, which is the association for wall painters, hm? (:
This is exactly the same situation. The scope of the Fellowship is the core of the network, and only the core. It helps to keep the Fellowship focused. But the Fellowship is not anything special, it's a fellowship, not the fellowship. There can exist multiple! If you don't like the fact that the Fellowship doesn't accept ecosystem work, well, create one that does! In fact, as far as I know, most of the Fellowship members (including me) would love to see an Ecosystem Fellowship and would support it.
Unfortunately, I have to vote nay here. Not because the work is not useful (it absolutely is in my opinion). A client library just doesn't fall within the scope. To quote the manifesto: