| Report Date | Date of submission (2025/01/09) |
| Submitted by | Cedric Decoster |
Explain why your contributions in relation to the Polkadot SDK are worthy of retention/promotion. Refer to the terms in Section 6 of the Manifesto and provide links to relevant content (i.e code, articles, media, etc.) to show that you are meeting all the requirements.
I have been actively contributing to the Substrate ecosystem since 2020 (first commit), working on open-source repositories and projects such as Ajuna Network, SubstrateGaming, and PolkadotPlay. As Founder and Core Contributor of Ajuna Network, and as core developer behind the entire Substrate C# Stack, including the Polkadot SDK for Unity.
GitHub handle: https://github.com/darkfriend77
Since September 2020, I have been working on the C# Stack for Substrate, focusing on building and maintaining critical projects that form the foundation of the C# Stack for Substrate, and also the base for the Polkadot SDK for Unity. These tools are essential for enabling game developers to utilize C# as the programming language for Substrate-based projects. Below are the key projects I have architected, developed, and continue to maintain:
Polkadot SDK for Unity Technical Verification: Successfully developed, published and passed the technical verification for the Polkadot SDK for Unity in early 2024. LINK
Async Backing Adoption: Led Ajuna Network to adopt asynchronous backing with runtime upgrades on Kusama and Polkadot, becoming the first non-common-good parachains to do so through runtime upgrades. Big learnings after breaking our rococo parachain as early adopters of async backing. LINK
BBB Android App: Developed and published the first production mobile Unity app/game in the Google Play Store, a full-onchain game running on top of a non-EVM Polkadot Parachain (ajuna network). LINK
S.A.G.E. Framework: Currently leading the architecture and development on the asset state transition engine for game backends. This framework abstracts Substrate/Rust code into basic transition functions and verification rules with free-to-play modules, anti-account farming measures, tournaments, rewards, and much more. LINK
One personal highlight from the past year was my new solution for representing Rust enums in C#. Rust enums posed a challenge due to their design in Rust versus the strongly-typed nature of C#. My initial implementation worked effectively with Mono for Unity but caused unexpected crashes when using Unity's IL2CPP (Intermediate Language to C++ scripting backend).
The crash occurred during the creation of production builds for the BBB game. After extensive debugging, I identified that IL2CPP had issues handling an excessive number of generic functions with varying argument counts—up to 255. These functions were generated as part of the Rust enum wrapper abstraction in the SDK. The issue was reported to Unity to raise awareness: Bug Report on Unity Discussions.
I redesigned the BaseEnumRust representation in the Substrate C# SDK to reduce unused code and unnecessary complexity in the wrapper abstraction.
Over the past four years, I have contributed to numerous artifacts and projects as part of various initiatives, including:
For many of these contributions, I played different multiple roles—some I authored and developed directly, while others I focused on providing solution architecture only. In all cases, I was responsible for inventing and shaping the ideas, as well as driving the vision and the narrative behind them.
If needed, I am happy to provide additional evidence of these contributions.
I have represented substrate-based projects and tools at various conferences, personally and as lead of the Ajuna team:
I was also a core contributor of Team Hexalem, which won at the Polkadot Winter Hackathon 2023
Additionally, there is a short bio presented by Nicholas at Polkadot Decoded 2022: Video link (timestamped)
Provide your voting record in relation to required thresholds for your rank.
Question(s):
Concern(s):
Comment(s):
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.
I agree with Jan and Alex, and switching my vote.
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.
The right approach here is to start/push for an Ecosystem Technical Fellowship - which should grow into an even bigger and arguably more impactful fellowship than the current Polkadot Technical Fellowship.
The Polkadot Technical Fellowship shall remain focused on the critical core infrastructure.
Hmm, I am a little bit surprised by the arguments here. I absolutely agree that these contributions would not count as evidence for retention or promotion for ranks higher than one. However, my take on this is:
As I said before, I believe it is about showing evidence for retention/promotion, I absolutely agree with above perspectives, but for entering Rank I, would have assumed that some technical understanding and long-term ecosystem activity (where he is outstanding) should be more than enough.
Establishing a separate Ecosystem Fellowship is impractical, and will not happen due to the immense challenges in defining its scope, evaluating diverse technologies, and maintaining governance. However, limiting the recognition of client library contributors to Rank 1 would mitigate these risks while ensuring that those who build critical tooling—such as SDKs, APIs, and integrations—are acknowledged.
This approach maintains the Fellowship’s core principles while preventing unnecessary fragmentation and governance overhead. If the Fellowship’s goal is to retain expertise vital to Polkadot’s longevity, then recognizing client library developers at Rank 1 is the most feasible and balanced solution.
I’ve said all I wanted to on this matter. Whether now or in the future, I hope this conversation helps shape a more inclusive approach.
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: