ambassador

senior_ambassador

head_ambassador

members

proficient_members

fellows

architects

architects_adept

grand_architects

masters

masters_constant

grand_masters

retain_at_i_dan

retain_at_ii_dan

retain_at_iii_dan

retain_at_iv_dan

retain_at_v_dan

retain_at_vi_dan

promote_to_i_dan

promote_to_ii_dan

promote_to_iii_dan

promote_to_iv_dan

promote_to_v_dan

promote_to_vi_dan

fast_promote_to_i_dan

fast_promote_to_ii_dan

fast_promote_to_iii_dan

### Background Information

I am Jamal Jones, a fullstack blockchain engineer specializing in Rust/Solidity Smart contract development and also Blockchain integrations using Rust/Typescript with strong interests in cryptography, Blockchain Interoperability, Wallet UX and Protocol architectures. I worked in the past on DeFi teams, Dev Advocacy (including for Polkadot Africa), Fullstack development focusing on community engagement, product architecture. On my personal hours, I build Blockchain tooling and other interesting products having worked on PVM Precompiles that exposes Soldiity interfaces for interacting the revive-exposed precompiles logic. 

### Motivations for Applying

I have been bullish on the Polkadot ecosystem and consider the Fellowship as a great way to further my journey within the Blockchain ecosystem. After spending time exploring the product and building D'apps, I am driven to explore contributions to the core protocol itself. I greatly admire the core engineers within the fellowship and appreciate the opportunity to learn from them and focus my efforts to the long-term progression and improvements of the ecosystem. The fellowship is the most direct way to achieve this goal.

### Areas of Interest

My interests are deeply tied to the core layers around 

- Interoperability: concerning with XCM operations, testing, benchmarking and developer experience (and education).
- Smart Contracts Functionality: including Precompiles logic(s), Pallet Revive, Asset(s), Staking and related functionalities
- Benchmarking and Integration Testing: Improving the quality of code within the ecosystem and learning from the high end patterns used 
- Ecosystem Tooling: like SubXt, Zombienet, PAPI e.t.c

### Contributions to Polkadot SDK

I have done some work contributing to the SDK, and joining the fellowship will allow me to be able to further the pursue the chance(s) to be more useful to the ecosystem. Some of them are:

1. Fix/Improvement: [On_demand_assigner](https://substrate.stackexchange.com/questions/11366/ondemandassignmentprovider-ondemandorderplaced-event-was-removed/11389#11389# events improvements on Relay runtime, [PR@4339](https://github.com/paritytech/polkadot-sdk/pull/4339)
2. XCM Benchmark Trait Generation: Removed redundant boilerplate code in the XCM versions' definitions and allow auto generated traits in [Pr#12298](https://github.com/paritytech/polkadot-sdk/pull/12298) and also implemented another logic to totally remove the boilerplate logic that every runtime must deal with when benchmarking their XCM instructions in [PR#12407](https://github.com/paritytech/polkadot-sdk/pull/12407).

I am currently working on resolving more XCM improvements within the codebase while also working (on my personal fork) on some cryptographic precompiles logic related to pallet-revive that can be used by Solidity developers.

**GitHub Profile**: https://github.com/bolajahmad
**Polkadot Address**: 16kBSj4Za5JGtqr2um1t5vsdomeTVVw6feEuN6jm7nL2WBBv

Polkadot Fellowship Application - Jamal Jones

**Background information of the applicant**
My name is Stephen Lawrence, a software engineer with years of experience building and operating complex software systems. I'm deeply passionate about open source, and much of my work involves contributing to both Web2 and Web3 projects. My journey into the Polkadot ecosystem started with the SDK, an interest that was sparked during a workshop previously organized by Polkadot Africa. That experience really opened my eyes to the possibilities within the ecosystem, and I've been contributing consistently ever since.

**Motivation(s) for applying to the Polkadot Technical Fellowship**
As I've contributed more deeply to the SDK, I've developed a strong sense of ownership over the quality and reliability of the codebase. Over the past months my work has moved from isolated feature additions into the parts of the stack that runtimes actually depend on in production: staking and election payouts on Asset Hub, XCM dry running, offchain state tooling, and the remote proxy path in the Fellowship runtimes. Joining the Fellowship feels like the right way to formalize that commitment, taking on greater responsibility, upholding high technical standards, and contributing to the long term sustainability of the infrastructure we all depend on.

**Area(s) of interest in relation to the Polkadot ecosystem**
- Node SDK and runtime development
- FRAME
- Staking, elections and governance pallets
- JAM

**Contribution(s) to Polkadot SDK**

- **[EPMB] Configurable reward source and slash destination for the signed phase** ([PR 12843](https://github.com/paritytech/polkadot-sdk/pull/12843), merged). I introduced `type RewardSource` and `type Slash` to `pallet-election-provider-multi-block::signed::Config` so signed submission rewards are paid from a pot account instead of being minted, and slashed deposits are routed to a handler instead of being burned. This keeps `TotalIssuance` reconcilable with the DAP emission curve on Asset Hub. The change was backported to stable2609.

- **pallet-accumulate-and-forward: measure the transfer period from the last forward** ([PR 13153](https://github.com/paritytech/polkadot-sdk/pull/13153), merged). `on_idle` required the block number to be an exact multiple of `TransferPeriod`, which a parachain reading the relay chain block number can miss indefinitely, stalling forwarding. It now records the block of the last forwarding attempt and forwards once the period has elapsed. Backported to stable2606 and stable2609.

- **pallet-xcm: fix dry run storage side effects leaking into xcm-emulator** ([PR 12807](https://github.com/paritytech/polkadot-sdk/pull/12807), merged). `dry_run_call` and `dry_run_xcm` mutated caller state, so dry run outbound messages were silently delivered by `process_messages()` in the emulator. Both are now wrapped in a rolled back storage transaction, so simulation no longer has real effects.

- **remote-ext: fix silent state corruption from lagging RPC providers** ([PR 12268](https://github.com/paritytech/polkadot-sdk/pull/12268), merged). Per item RPC errors were being treated as empty values, producing silently incomplete snapshots for `try-runtime` and testing. Errors are now treated as batch failures, the computed storage root is verified against the block header before a snapshot is cached, and providers that lack the target block are excluded up front.

- **[EPMB] Let DAP own and authorise payouts from its buffer** ([issue 13127](https://github.com/paritytech/polkadot-sdk/issues/13127), open, in progress). I opened and scoped this off the back of review discussion on PR 12843 with [@sigurpol](https://github.com/sigurpol), who reviewed that PR in depth and helped shape the direction. DAP already owns deactivation on inflow, so reactivation on outflow belongs there too. The proposal registers the signed phase pot in DAP as a capped recipient and moves the payout plus the reactivation into DAP, so the pallet requests a payment instead of drawing on the pot itself. I am actively working on this now and the implementation is open for review at [PR 13173](https://github.com/paritytech/polkadot-sdk/pull/13173).

- **Ensure broker parachain reachability in coretime benchmarks** ([PR 11080](https://github.com/paritytech/polkadot-sdk/pull/11080), approved). Uses `SendXcm::ensure_successful_delivery()` so the required XCM routing infrastructure is initialized before the coretime benchmarks run.

- **frame-benchmarking: refactor the pallet benchmarking backend** ([PR 11758](https://github.com/paritytech/polkadot-sdk/pull/11758), approved). Deduplicates the analysis logic, formalizes `BenchmarkBatch::split()`, improves API ergonomics, error handling and documentation, and deprecates the v1 macro system in favour of v2.

- **frame-system: require explicit weight configuration in default configs** ([PR 10901](https://github.com/paritytech/polkadot-sdk/pull/10901), approved, second review pending). `SystemWeightInfo` and `ExtensionsWeightInfo` are marked `#[pallet::no_default]` and lose their `()` defaults, so runtimes can no longer silently inherit the Substrate reference weights and must set their own benchmarked values.

- **pallet_balances: remove `FreezeIdentifier` and `MaxFreezes` in favour of `RuntimeFreezeReason`** ([PR 12900](https://github.com/paritytech/polkadot-sdk/pull/12900), approved). `RuntimeFreezeReason` becomes the freeze identifier and bounds `Freezes` with its variant count, retiring two redundant config items and the integrity test that policed them across all runtimes.

- **pallet-broker: add an extrinsic to register a potential renewal** ([PR 10824](https://github.com/paritytech/polkadot-sdk/pull/10824), approved). Gives network administrators, especially in testnet and governance contexts, direct control over coretime renewals, making it easier to manage allocations and schedule renewals with precision.

- **Deprecating the `para_id` field from chain specifications** ([PR 7546](https://github.com/paritytech/polkadot-sdk/pull/7546), closed). My PR laid the groundwork by introducing the idea of retrieving the parachain ID via a runtime API. That direction was later expanded on and fully realized in [PR 8651](https://github.com/paritytech/polkadot-sdk/pull/8651), which completed the transition to a dynamic, runtime driven approach.

**Contribution(s) to the Fellowship runtimes**

- **Fix remote proxy dropping the newest relay root when multiple parachain blocks share a relay parent** ([PR 1234](https://github.com/polkadot-fellows/runtimes/pull/1234), merged). `pallet-remote-proxy` skipped duplicate `BlockToRoot` entries for the same relay parent and evicted the oldest entry instead of the newest when the bounded vector was full, so remote proxy proofs anchored at recent relay blocks failed with `UnknownProofAnchorBlock`. This closed [issue 1230](https://github.com/polkadot-fellows/runtimes/issues/1230).

- **Wire pallet-election-provider-multi-block Slash/RewardSource to DAP on Polkadot Asset Hub** ([issue 1239](https://github.com/polkadot-fellows/runtimes/issues/1239), open). Polkadot Asset Hub needs the same wiring that PR 12843 added for Westend Asset Hub, so I filed and scoped the follow up here for the next polkadot-sdk bump, again alongside [@sigurpol](https://github.com/sigurpol), who is carrying it with me.

**Ongoing contributions**

- Polkadot SDK: https://github.com/paritytech/polkadot-sdk/pulls?q=is%3Apr+state%3Aopen+author%3AStephenlawrence00
- Fellowship runtimes: https://github.com/polkadot-fellows/runtimes/pulls?q=is%3Apr+state%3Aopen+author%3AStephenlawrence00

These cover, among others, `try_state` invariant checks for a set of pallets (proxy, multisig, vesting, identity, preimage, scheduler, whitelist, salary), the `Currency` to `fungible` migrations across alliance, society, vesting, democracy, assets, nfts and uniques, the scheduler overweight task handling fix, and the VersionedCall refactor for pallets that store calls.

**Link to the GitHub profile of the applicant**
https://github.com/Stephenlawrence00

Polkadot address with a verified on-chain identity
16Xj1rSgNBtzHch3Jb9SfW7dK749s9WbCqKcwmZCFkR2pnai

Polkadot Technical Fellowship Application: Stephen Lawrence

# Polkadot Technical Fellowship application: Michał Gil

## Background

My name is Michał Gil. I hold a Master's degree in Computer Science from the Wrocław University of Science and Technology (Politechnika Wrocławska), with a specialty in Data Science and Machine Learning. I have worked in the IT industry since 2016, full time as a software engineer since 2018, across companies of various sizes and domains. Before joining the Polkadot ecosystem I worked on a trading platform for digital assets ([t-dx.com](https://app.t-dx.com)), where I led delivery of the retail-focused part of the platform.

Since October 2024 I have worked at Parity Technologies as a Runtime Engineer. About 2 months after my onboarding I joined the Proof of Personhood project and worked on the People Chain, its runtime pallets and its integration with the rest of the Polkadot ecosystem.

## Motivation

Joining the Fellowship is a natural continuation of the work I already do every day on Polkadot's runtime layer. Knowing the internals of the Polkadot SDK, I can assess runtime upgrades and other technical proposals. I understand the importance of Polkadot's decentralization while keeping the network secure and reliable, and I want to contribute that perspective to the technical governance of the protocol. Fellowship membership would formalize my ongoing contributions and align my work on Proof of Personhood with the ecosystem's technical direction.

## Areas of interest

- Proof of Personhood: means of proving personhood (DIMs), personhood distribution across chains
- FRAME runtime engineering: offchain worker, transaction pool, benchmarking and weights
- XCM and cross-chain protocol design
- Cryptography used in Proof of Personhood, e.g. ring VRF, ZK proofs

## Contributions

During nearly 2 years on the Proof of Personhood project I have authored various contributions. Highlights:

- **Cross-chain personhood distribution**: I designed and implemented the mechanism by which the People Chain shares ring roots (cryptographic commitments to member sets) with other chains: the [members-notifier](https://github.com/paritytech/individuality-community/tree/main/pallets/members-notifier) pallet (publisher, People Chain) and the [members-subscriber](https://github.com/paritytech/individuality-community/tree/main/pallets/members-subscriber) pallet (consumer, e.g. Asset Hub), letting any chain verify ring VRF personhood proofs locally.
- **The dotNS gateway**: I designed the solution and wrote the specification for integrating dotNS username reservation and registration into the personhood induction flow, then implemented the [dotns-gateway](https://github.com/paritytech/individuality-community/tree/main/pallets/dotns-gateway) pallet on Asset Hub and led the cross-team delivery with the dotNS and Identity Backend teams.
- **People Chain bootstrap**: the [storage-initialization](https://github.com/paritytech/individuality-community/tree/main/pallets/storage-initialization) pallet, a multi-block state machine that initializes the chain's economic state via a real XCM asset transfer from Asset Hub.
- **People pallet hardening**: benchmark suite, unit tests for ring merges, suspensions and onboarding, VRF ring baking as an offchain worker job, statement store validation for proven people.
- **Personhood building blocks**: tests, benchmarks and offchain worker processing for mob-rule (decentralized judgements); invitations and incremental referrals for proof-of-ink; scheduling, benchmarks and weights for the game pallet (Proof of Video Interaction).

The project was developed in the private paritytech/individuality repository, to which many Fellowship members have access; the codebase has since been published at [paritytech/individuality-community](https://github.com/paritytech/individuality-community).

## Contact

- GitHub: [Zebedeusz](https://github.com/Zebedeusz)
- Polkadot address: `15tQbv1FDUU9WcNtiXsCWUiWMzDEL9r6N6k43bAjjGFQF3ig`


Polkadot Technical Fellowship Induction Application - Michał Gil

Hi everyone,

I'm Maheswaran, a full-stack blockchain developer from Tamil Nadu, India 
and a Polkadot Blockchain Academy graduate.

Shipped work:

- Stylus-Toolkit — CLI toolkit for building, deploying, and profiling 
  Arbitrum Stylus contracts. Arbitrum Foundation grant, both milestones 
  delivered, live on NPM with 224+ downloads, 20 GitHub stars, 32.6% 
  average gas reduction in benchmarks.

- Rootstock Python SDK — first Python SDK for RSK, published to PyPI, 
  RootstockCollective grant.

- Rootstock Agentic DeFi Framework — MCP-based AI agent runtime for 
  autonomous DeFi on Rootstock.

Smart contract security research on Sherlock, Code4rena and cantina  — 
20+ confirmed findings including High severity reports.

PBA gave me a solid foundation in Polkadot's architecture. I want to go 
deeper into the protocol layer, contribute to developer tooling and runtime 
development, and be useful to the ecosystem long term.

GitHub: https://github.com/soloking1412

Maheswaran Velmurugan — Induction Request 

## Background

I'm Josep M Sobrepere ([@josepot](https://github.com/josepot)), a software engineer based in Barcelona. I have been contributing to the Polkadot ecosystem since September 2021, when I joined Parity Technologies to work on substrate-connect and smoldot.

In early 2024, I left Parity to found **Streamsphere Labs**, a small company (3 people) dedicated full-time to the Polkadot ecosystem. Streamsphere Labs is the team behind **Polkadot-API (PAPI)**, which has been continuously funded by the Polkadot Treasury since February 2024.

## Motivation

I have spent the last ~5 years building the libraries and infrastructure that Polkadot developers rely on daily. Joining the Fellowship is a natural next step: it gives me a formal role in the technical governance of the protocol I am already deeply committed to, and ensures that the developer-facing layer of Polkadot evolves in step with the core protocol. I want to contribute more directly and consistently to Polkadot's technical evolution, not just by building the tools that consume the protocol, but by helping shape the protocol itself.

## Areas of Interest

- **JSON-RPC interface specification**: I have been one of the primary consumers and co-designers of the new JSON-RPC spec, raising issues, proposing changes, and contributing fixes that shaped the current API surface.
- **Light-client infrastructure**: building dApps and libraries that treat the light client as a first-class runtime environment, reducing ecosystem dependence on centralized RPC providers.
- **Transaction and extrinsic formats**: the boundary between the application layer and the runtime, including wallet interfaces, signed extension handling, and Extrinsic V5 adoption.
- **Developer tooling**: type-safe, metadata-driven APIs that make it substantially easier to build correct, chain-agnostic applications on Polkadot.

## Contributions

### Polkadot-API (PAPI)

**Primary author and technical lead** - [github.com/polkadot-api/polkadot-api](https://github.com/polkadot-api/polkadot-api)

PAPI is the officially recommended successor to polkadot.js for building dApps on Polkadot and Substrate-based chains. I conceived, architected, and built PAPI from scratch while at Parity, and have continued leading its development full-time since founding Streamsphere Labs. Key design decisions I made:

- **Light-client first**: built on the new JSON-RPC spec to natively support smoldot, dApps no longer need a trusted RPC provider.
- **Metadata-driven type generation**: all TypeScript types are generated from on-chain metadata, making the API inherently chain-agnostic and runtime-upgrade-aware.
- **Modular architecture**: libraries are composable and tree-shakeable, keeping bundle sizes under 50 KB.
- **Observable + Promise dual API**: both reactive (RxJS) and async/await interfaces with shared internals.

The library has shipped 118+ releases, has 1,326 commits, and is used across the ecosystem by wallets, dApps, and tooling teams. It was transferred from Parity Technologies to the independent `polkadot-api` GitHub organization in February 2024.

Presented at **Polkadot Decoded 2024**: _"Build a Modern dApp with Polkadot-API"_, [youtube.com/watch?v=fj63gYJmuIk](https://www.youtube.com/watch?v=fj63gYJmuIk)

### JSON-RPC Interface Specification

**Active contributor and co-designer** - [github.com/paritytech/json-rpc-interface-spec](https://github.com/paritytech/json-rpc-interface-spec)

As the primary implementer of the new JSON-RPC spec in PAPI, I identified issues and gaps in the spec itself and contributed fixes and proposals back upstream. Selected contributions:

- [#80](https://github.com/paritytech/json-rpc-interface-spec/pull/80): `transaction`: add `searched` event
- [#76](https://github.com/paritytech/json-rpc-interface-spec/pull/76): explicit guarantees on the `finalized` event of `submitAndWatch`
- [#65](https://github.com/paritytech/json-rpc-interface-spec/pull/65): fix: `inaccessible` event on `chainHead_unstable_call`
- [#129](https://github.com/paritytech/json-rpc-interface-spec/pull/129): fix: `rpc_methods` return value
- [#169](https://github.com/paritytech/json-rpc-interface-spec/pull/169): fix: `archive_v1_storage` wrong reference
- Multiple RFCs and design issues: batching storage requests (#47, #48), `chainHead_unstable_unpin` accepting multiple hashes (#46), `stop` event semantics (#86), `system_accountNextIndex` alternative (#156)

These contributions came directly from building PAPI against the spec and discovering ambiguities or missing guarantees that would otherwise cause subtle client bugs.

### `createTransaction` RFC: Wallet Interface Redesign

[polkadot-js/api#6213](https://github.com/polkadot-js/api/issues/6213)

I authored a detailed RFC proposing `createTransaction` as a forward-compatible replacement for the `signPayload` interface used by all Polkadot wallet extensions. The core problem: `signPayload` predates Metadata V14, cannot support custom signed extensions, and breaks with every non-trivial chain upgrade (e.g. `CheckMetadataHash`, Extrinsic V5). My proposal defines a `TxPayloadV1` structure that passes complete metadata and extension definitions, making it resilient to protocol evolution and compatible with both online and offline signers (hardware wallets, browser extensions).

This RFC has driven ecosystem-wide discussion around the wallet/dApp boundary and is informing how the extension communication protocol evolves.

### substrate-connect

**Significant contributor**: [github.com/paritytech/substrate-connect](https://github.com/paritytech/substrate-connect)

During my time at Parity I made numerous contributions to substrate-connect, the browser extension and library that enables light-client connections for dApps. Selected PRs:

- [#909](https://github.com/paritytech/substrate-connect/pull/909): remove `createPolkadotJsScClient` (API simplification)
- [#835](https://github.com/paritytech/substrate-connect/pull/835): improve `healthChecker` API
- [#787](https://github.com/paritytech/substrate-connect/pull/787): improvements and fixes on the Polkadot RPC Provider
- [#836](https://github.com/paritytech/substrate-connect/pull/836): fixes usage in Node.js environments
- Multiple dependency upgrades, CI improvements, and smoldot version bumps

### smoldot

**Contributor**: [github.com/paritytech/smoldot](https://github.com/paritytech/smoldot)

- [#1710](https://github.com/paritytech/smoldot/pull/1710) smoldot light improvements: fixed TypeScript definition mismatches (downstream projects like `substrate-connect` were forced to use `any` types as a workaround) and standardized `client.terminate()` behavior between Node.js and browser environments, fixing memory leaks and race conditions.
- [#2171](https://github.com/paritytech/smoldot/pull/2171) fix: improve error handling on the browser
- [#2019](https://github.com/paritytech/smoldot/pull/2019) add `name` property to smoldot-light errors

### polkadot-fellows/runtimes

- [#1117](https://github.com/polkadot-fellows/runtimes/pull/1117) Use chain-specific `ExtrinsicBaseWeight` in fee constants. A subtle but important correctness fix: the runtime was using a generic constant that didn't match the value in `System.BlockWeights.per_class_normal.base_extrinsic`, causing discrepancies in fee calculation tools. Merged March 2024.

### polkadot-sdk

- [#7959](https://github.com/paritytech/polkadot-sdk/pull/7959) Treasury: update expire date on payout. Fixes the `payout.expire_at` field to reset with `PayoutPeriod` on each valid payout attempt.

### Treasury-Funded PAPI Development

Since February 2024, PAPI has been fully funded by the Polkadot Treasury through a series of referenda. Starting with a modest 2-month proposal, we progressively earned the community's trust by consistently over-delivering and growing the library from early beta to the de-facto standard for Polkadot application development.

## Contact

- **GitHub:** [github.com/josepot](https://github.com/josepot)
- **On-chain address:** `15roJ4ZrgrZam5BQWJgiGHpgp7ShFQBRNLq6qUfiNqXDZjMK`

Application to Join the Polkadot Technical Fellowship - Josep M Sobrepere

## Background information of the applicant

My name is Victor Oliva. I am a software engineer with a degree in Computer Science, and more than 12 years of professional experience building software systems across several companies, with a particular focus on financial, trading, and real-time systems.

I have been involved in the Polkadot ecosystem as a core developer of **Polkadot-API** since February 2024, contributing to the development of tooling and libraries that improve the developer experience for teams building on Polkadot. Alongside this work, I have also contributed to the **Polkadot SDK**, **Smoldot**, and Acala **Chopsticks**.

In 2024, I graduated with distinction from the Polkadot Blockchain Academy protocol track in Singapore. Proof of graduation with distinction is available on Asset Hub Polkadot as [NFT #171-20](https://assethub-polkadot.subscan.io/nft_item/171-20).

## Motivation for applying to the Polkadot Technical Fellowship

I am applying to the Polkadot Technical Fellowship to formalise and deepen my ongoing contributions to the Polkadot ecosystem.

Over the past year, my work has focused primarily on improving developer-facing infrastructure around Polkadot, especially through Polkadot-API and contributions to related tooling. This has given me a practical understanding of the challenges faced by developers integrating with Polkadot, building applications, and interacting with core runtime and node APIs.

Joining the Fellowship would allow me to align my work more closely with the long-term technical direction of the ecosystem, collaborate more directly with other contributors, and increase the scope and impact of my contributions. In particular, I am interested in expanding my involvement in the Polkadot SDK itself, with improvements to developer tooling, runtime APIs, FRAME pallet ergonomics, and in a future JAM services.

I see the Fellowship as an opportunity to take on greater responsibility, contribute more consistently to core protocol and SDK work, and help make Polkadot more accessible, robust, and productive for developers.

## Areas of interest in relation to the Polkadot ecosystem

My main areas of interest are:

1. **Developer tooling**
   I am interested in improving the end-to-end experience for developers building on Polkadot, including APIs and libraries, testing workflows, debugging tools, and integration tooling. My work on Polkadot-API has given me a strong perspective on how tooling can reduce friction and make the ecosystem easier to adopt.

2. **FRAME pallet UX**
   I am interested in improving the ergonomics and usability of FRAME pallets, both for runtime developers and application developers interacting with pallets externally. This includes clearer APIs, better metadata, improved runtime interfaces, and more consistent developer-facing patterns.

3. **JAM services**
   I am interested in the evolution of JAM and the developer-facing services that may emerge around it. I would like to contribute to tooling, abstractions, and infrastructure that help developers build effectively in the next stage of Polkadot’s architecture.

## Contributions to Polkadot SDK and related ecosystem projects

In addition to my work as a core developer of Polkadot-API, I have made the following external contributions to the Polkadot ecosystem:

1. [[pallet-revive] add get_storage_var_key for variable-sized keys](https://github.com/paritytech/polkadot-sdk/pull/8274)
2. [feat(revive): add contract instantiated event](https://github.com/paritytech/polkadot-sdk/pull/8789)
3. [fix(rpc-spec-v2): best block not announced immediately after initialised](https://github.com/paritytech/polkadot-sdk/pull/10525)
4. [[referenda] Add `slash_submission_deposit` extrinsic](https://github.com/paritytech/polkadot-sdk/pull/11524)
5. [Issue contributions to Polkadot SDK](https://github.com/paritytech/polkadot-sdk/issues?q=author%3Avoliva)
6. [PRs authored in Smoldot](https://github.com/paritytech/smoldot-archive/pulls?q=author%3Avoliva)
7. [PRs authored in Chopsticks](https://github.com/AcalaNetwork/chopsticks/pulls?q=is%3Apr+author%3Avoliva)

## GitHub profile

https://github.com/voliva

## Polkadot address with verified on-chain identity:

16JGzEsi8gcySKjpmxHVrkLTHdFHodRepEz8n244gNZpr9J


Polkadot Technical Fellowship Application: Victor Oliva

# Application to Join the Polkadot Technical Fellowship - Carlo Sala

## Background Information

My name is Carlo Sala. I am a software engineer and open-source maintainer focused on developer tooling and client-side infrastructure for the Polkadot ecosystem.

I am a maintainer and developer of [Polkadot-API](https://github.com/polkadot-api/polkadot-api), a suite of TypeScript libraries designed around a light-client-first approach to building applications for Polkadot SDK-based chains. My work is centered on making interaction with Polkadot reliable and type-safe for developers, while staying aligned with the underlying protocol and runtime interfaces.

My background combines software engineering, open-source maintenance, and mathematics. I also maintain open-source software through [Oh My Zsh](https://github.com/ohmyzsh/ohmyzsh), which has given me long-term experience with public collaboration, review processes, and widely used developer-facing tooling.

## Motivation for Applying

I am applying to the Polkadot Technical Fellowship because I want to contribute more directly and consistently to the technical evolution of Polkadot.

Most of my work sits at the boundary between protocol/runtime behavior and the developers who build applications on top of it. Through Polkadot-API, I regularly deal with runtime metadata, transaction construction, signing, RPC behavior, XCM-facing APIs, and light-client integration. This has made clear to me how important close coordination is between runtime engineers, SDK contributors, tooling maintainers, and application developers.

Joining the Fellowship would give me a more structured way to participate in those technical discussions, share implementation feedback from the tooling side, and help improve the interfaces that developers rely on when building on Polkadot. I want to bring downstream implementation feedback into Fellowship discussions earlier, especially when changes to metadata, extrinsics, RPCs, or runtime interfaces affect wallets, light clients, and application tooling.

I also see the Fellowship as a long-term commitment mechanism. I want to be accountable to the technical community around Polkadot and to continue contributing in a way that is visible, reviewable, and useful to the ecosystem.

## Areas of Interest

My main areas of interest in the Polkadot ecosystem are:

- Runtime metadata and runtime/off-chain communication
- Developer tooling and SDK ergonomics
- Light-client-first application and tool development
- JSON-RPC interfaces and client behavior
- Transaction construction, signing flows, and transaction extensions
- Coordination between SDK/runtime changes and downstream tooling

## Contributions

My primary contribution to the Polkadot ecosystem is my work on [Polkadot-API](https://github.com/polkadot-api/polkadot-api). Polkadot-API provides a composable TypeScript library stack for interacting with Polkadot SDK-based chains, with a strong focus on light-client usage, type safety, and developer ergonomics.

Within Polkadot-API, my work includes API architecture, light-client-focused design, runtime metadata integration, typed interfaces, application-facing abstractions, and upstream coordination when SDK or runtime behavior affects downstream tooling. The goal is to make it practical for application developers to build against Polkadot chains using modern TypeScript tooling while preserving correctness and compatibility with the underlying chain interfaces.

I have also contributed directly to `paritytech/polkadot-sdk`, including merged pull requests such as:

- [#10592: fix: ensure metadata v15 is generated by frame-metadata](https://github.com/paritytech/polkadot-sdk/pull/10592)
- [#7201: xcm: avoid subtracting delivery fees twice](https://github.com/paritytech/polkadot-sdk/pull/7201)
- [#7134: xcm: convert properly assets in xcmpayment apis](https://github.com/paritytech/polkadot-sdk/pull/7134)

The metadata v15 fix was also backported across multiple release branches. These SDK contributions are closely connected to my Polkadot-API maintenance responsibilities, where SDK changes often have direct impact on application developers and client libraries.

In `polkadot-fellows/RFCs`, I have contributed to protocol and interface discussions around metadata, transaction formats, and offline signing. In particular, I contributed as a co-author to [#78: Merkleized metadata](https://github.com/polkadot-fellows/RFCs/pull/78), and I opened [#148: RFC-0078 adaptation to Metadata V16 and Extrinsic V5](https://github.com/polkadot-fellows/RFCs/issues/148) to continue the discussion around Metadata V16, Extrinsic V5, and the information offline signers need in order to decode and verify transactions correctly.

## GitHub Profile

https://github.com/carlosala

## Polkadot Address With Verified On-Chain Identity

16JskuojL6mSp6HNcjiHYa9jqksWbLD8L9YGWU1ppiPWQ9sa


Polkadot Fellowship Application - Carlo Sala

**Background information of the applicant**

Hi, my name is Nnamdi, and I’m a software engineer with 5+ years of experience building and scaling backend systems. I **lead backend engineering** at my company, and I am responsible for ensuring our services are up and responsive. I do this by upholding **good engineering practices**, including **robust test coverage**, **CI/CD pipelines**, and ensuring proper **monitoring** of our services using observability tools, such as Prometheus and Grafana.

I’ve been an open-source contributor in the Web3 space for over a year. In that time, I have contributed to popular open-source projects like **Ethereum’s Foundry**, **Starknet Foundry**, and the **Polkadot SDK**. I’m a graduate of **PBAX Wave 5** and have mastered the foundational concepts of Polkadot.

**Motivation(s) for applying to the Polkadot Technical Fellowship**

I am interested in joining the fellowship to play a part in the success of the ecosystem and contribute to the development of the Polkadot technology. I am impressed by the **technical depth** and **cutting-edge innovations** Polkadot has consistently delivered to the **Web3 space**, and I want to be a part of that innovation. I aim to learn more about the technology by building it. I believe that getting hands-on is the fastest way to **master the technology**.

I’m also excited about the next phase of **Polkadot - JAM**; I am studying the JAM Gray paper. I look forward to contributing to the development of JAM, starting with **Polkavm** and building services on top of JAM.

**Area(s) of interest in relation to the Polkadot ecosystem**

I have a broad interest in the Polkadot ecosystem. Ultimately, my goal is to master the core areas that make the technology function. My areas of interest include;

- **FRAME Runtime Development**
- **Node and Networking (litep2p)**
- **Codec (SCALE)**
- **JAM (PolkaVM)**

**Contribution(s) to Polkadot SDK (if any)**

I have numerous contributions and open PRs across the Polkadot SDK and Polkadot Ecosystem Tests repositories.

- **Polkadot SDK Contributions:** https://github.com/paritytech/polkadot-sdk/pulls/naijauser
- **Polkadot Ecosystem Tests:** https://github.com/open-web3-stack/polkadot-ecosystem-tests/pulls/naijauser

More contributions in other repositories are in the works.

**Link to the GitHub profile of the applicant**

https://github.com/naijauser

**Polkadot address with a verified on-chain identity**

12mzp6SdXsT9NbCwYptcTNeALheiaBVRSM7XpCb4Z3HP9wLP

Application to Join the Fellowship - Nnamdi Aninye

**Background information of the applicant**

My name is **Jason Mansfield**. I am a **software engineer** and **systems architect** with over twenty years of experience building and operating complex software systems.

I founded and lead **Method5**, a technology consultancy that designs and delivers **enterprise software solutions** for organizations ranging from startups to established companies. Our work spans backend platforms, APIs, distributed systems, and other large-scale software infrastructure. Over the course of my career I have helped organizations **design system architectures, implement core services, and bring technically demanding products into production**.

Although I operate at an architectural level, I remain **deeply hands-on**. Much of my work involves **concurrency design**, **performance optimization**, and **diagnosing difficult system-level issues**. I have a long-standing interest in **deterministic systems**, **virtual machine behavior**, and the engineering challenges involved in building infrastructure that must behave consistently across platforms and runtime environments.

**Motivation for Applying**

I am applying to the **Polkadot Technical Fellowship** because I would like to contribute more directly to the **protocol’s technical evolutio**n, particularly as Polkadot transitions toward **JAM**.

JAM introduces a significant shift in **execution architecture and protocol responsibilities**. Over the past **year and a half** I have spent considerable time studying the **JAM Graypaper** and **implementing its semantics** in practice. That experience reinforced how important **independent implementations** and **careful technical review** are for the health of a decentralized protocol.

In my experience, **specification clarity emerges through implementation**. Edge cases, ambiguities, and practical constraints tend to surface when systems are built and tested in real environments. I am interested in contributing to that process by sharing **implementation-driven feedback**, helping strengthen **cross-client validation**, and participating in technical discussions around **protocol design** and **execution semantics**.

The Fellowship offers a structured way to contribute to these efforts alongside others working on the protocol.

**Areas of Interest**

My primary areas of interest within the Polkadot ecosystem include:

- **JAM protocol architecture** and **execution semantics**
- **Independent client development** and **protocol decentralization**
- **Cross-implementation validation** and **specification clarity**
- **Protocol-level performance engineering**
- Developer tooling and SDK support

**Contributions**

I am the **founder and lead developer** of **[JavaJAM](https://github.com/javajamio)**, an independent clean-room implementation of the JAM protocol. The project includes a full **PVM interpreter** and **multi-architecture JIT recompilers** (AArch64 and x86-64), a specification-aligned sandboxed memory model, **erasure coding** support, and **deterministic testing infrastructure**.

https://x.com/javajam_io

https://github.com/javajamio

I also developed and maintain **[Jot](https://github.com/methodfive/jot)**, a **Java-based SDK for Polkadot** designed to provide a robust developer interface for interacting with the ecosystem.

https://github.com/methodfive/jot

Through this work I have engaged deeply with the **JAM Graypaper** and its **execution semantics**, often resolving ambiguities through **implementation and testing**. My focus has been on **correctness**, **determinism**, and **building infrastructure that remains maintainable** and portable across platforms.

I plan to continue contributing through independent implementation work, specification feedback, and long-term participation in the **technical development of the Polkadot protocol**.

**GitHub Profile**

https://github.com/jaymansfield

**Polkadot Address**

12pveVa6g97U7z5uK89fWNfNKpduzJeqPhtsU4PiiohKeUza

Application to join the Polkadot Fellowship: Jason Mansfield

**Background information**

My name is Nathaniel, a full-stack developer specializing in Rust and Flutter with a deep interest in embedded systems, permissionless architectures, and web security. Previously at Cyborg Network, I contributed to the Cyborg Parachain, a decentralized AI computing network. My work focused on building resilient, on-chain systems, including a task management and worker reputation framework with automatic penalties; integrating FIAT and multi-asset payments via Asset Hub; implementing secure model encryption; and establishing cross-chain communication (XCM) for asset teleportation. Beyond my professional work, I actively explore new paradigms, having developed NOSTR-contract—an ink! smart contract that manages decentralized reporting by tracking user-to-relayer subscriptions and implementing methods for sending and challenging reports.

**Motivation for applying**

I view the Fellowship as the essential next step in my journey within Polkadot. My unique perspective on the technology's evolution has solidified my desire to move from observation to core contribution. I am applying to collaborate with the engineers I deeply respect, to learn from them, and to dedicate my efforts to the long-term sustainability of the ecosystem—ensuring its innovative foundations remain performant and builder-friendly for years to come.


**Area of interest**

- The Core Stack: Directly contributing to the resilience and scalability of the network through runtime engineering (FRAME, governance) and node development/SDK work.
- The Connective Tissue: Enhancing cross-chain communication (XCM) to be more robust and programmable, which is essential for a unified ecosystem.
- The On-Ramp: Leveraging innovations like Pallet Revive to create accessible smart contract capabilities, thereby lowering the barrier to entry for developers and bridging ecosystems.

**Contributions **
Contributions to the Polkadot SDK include the addition of a ProxyApi runtime API to the Proxy pallet, introducing view functions for runtime-specific type configuration to enable on-chain verification of call permissions and proxy-type hierarchies, thereby enhancing proxy management flexibility and security. https://github.com/paritytech/polkadot-sdk/pull/7320
Further contributions extend the XCM framework with a generic ExternalConsensusLocationsConverterFor struct to facilitate account conversion for external blockchain ecosystems beyond Polkadot's native parachains, broadening the network's interoperability scope and enabling seamless, backward-compatible integration with independent external blockchains. https://github.com/paritytech/polkadot-sdk/pull/7313

Further contributions include improving the developer experience and tooling efficiency within the ecosystem, I am actively contributing to the foundational JSON-RPC interface. I recently authored and proposed archive_unstable_transactionReceipt, a new RPC method designed to enable efficient, stateless lookup of transaction receipts—eliminating the need for costly full block downloads. This work involves both specification in the json-rpc-interface-spec repository and its subsequent implementation in the polkadot-sdk, directly enhancing the node-level tooling and data accessibility for builders. https://github.com/paritytech/json-rpc-interface-spec/pull/182

Other ongoing contributions include: https://github.com/paritytech/polkadot-sdk/pulls?q=is%3Apr+is%3Aopen+nathy-bajo


**Link to the GitHub profile of the applicant**
https://github.com/Nathy-bajo

**Polkadot address with a verified on-chain identity**
1HXh7kCk2Z9Er4TpqF7TPX6ivSnJTECesp44RP7jnP7RCeL

Application to join Polkadot Fellowship - Nathaniel Bajo

## Background Information

My name is **Daniel Cukier**, and I hold a **PhD in Computer Science** from the University of São Paulo. 
My doctoral research focused on modeling and understanding [software startup ecosystems](https://link.springer.com/article/10.1186/s13731-018-0091-6) using formal qualitative methods, resulting in a published framework for ecosystem maturity.

This experience strengthened my ability to analyze complex systems, build conceptual models, and work with evolving structures — skills that have been valuable throughout my engineering career.

Recently, my work has centered on the **JAM protocol**. I am one of the core developers of **Jamixir**, an independent Elixir implementation of JAM. This includes interpreting the Graypaper, translating formal definitions into executable semantics, implementing PVM behavior, and experimenting with early node architecture ideas.

I have worked in the software industry for more than twenty years as a developer, founder, and technology leader. I founded a **music analytics startup** that processed billions of data points to help artists understand their audience and receive fair compensation. The company operated for six years and was eventually acquired in Brazil. Although not a large exit, it provided deep experience in building real systems, handling large-scale data, and navigating both technical and organizational complexity.

I also served as CTO of **Elo7** (later acquired by Etsy) and CTO of **Pravaler**, and I have been active in developer communities and engineering education, including contributing to [WEB3DEV](https://w3d.community), the largest Web3 developer community in Latin America.

---

## Motivations for Applying

I am applying to the Polkadot Fellowship because I want to contribute to the long-term evolution of the protocol, especially during its transition into JAM. 
Over the last year, I have spent significant time studying JAM and implementing its components. This has made me want to participate more formally in the work around specification clarity and protocol understanding.

My motivations include:

- **Deepening my protocol expertise** by collaborating with others who are exploring related problems. 
- **Contributing to decentralization** by helping develop and validate alternative implementations. 
- **Improving specification clarity**, both through implementation feedback and direct contributions. 
- **Supporting developer onboarding and education**, helping newcomers understand JAM’s execution model and core concepts. 
- **Participating in a community that values humility, rigor, and long-term commitment.**

I see the Fellowship as the right structure to continue contributing meaningfully in these areas.

---

## Areas of Interest in the Polkadot Ecosystem

My technical areas of interest include:

- JAM architecture and formal semantics 
- Node and runtime responsibilities under JAM 
- Cross-implementation alignment and specification clarity 
- Live network operational challenges 

I am also strongly interested in **developer experience and onboarding**. Throughout my career, I have worked to make complex concepts accessible, and I would like to help produce clearer explanations, runnable examples, and educational materials for developers entering the Polkadot ecosystem.

---

## Contributions to Polkadot / Protocol Work

My contributions so far are primarily related to JAM:

- I am developing **[Jamixir](https://github.com/jamixir)**, an Elixir implementation of the JAM protocol. 
- I have **15 accepted commits to the official JAM Graypaper**, improving clarity, correcting inconsistencies, and refining definitions: 
 <https://github.com/gavofyork/graypaper/commits?author=danicuki> 
- I have taken part in discussions around semantics, determinism, architecture boundaries, and specification interpretation. 
- I have created diagrams, explanations, and conceptual demos to help others understand JAM’s structure and goals. 
- I helped organize JAM meetups and community calls, including the JAM Experience gathering in Lisbon (May 2025).

These contributions reflect both practical implementation work and a sustained engagement with the protocol’s underlying ideas. As JAM evolves, I plan to continue contributing to validation, specification refinement, and developer accessibility.

---

## GitHub Profile 
<https://github.com/danicuki>

---

## Polkadot Address (with verified on-chain identity) 
127XreSJZW91qLc91hwepYZ9pBfuNveqDERv9KDrm2oQf4Lu

Polkadot Technical Fellowship Application: Daniel Cukier

### Background

I'm **Prasad Kumkar**, a software engineer and technical lead with 5+ years of hands-on experience building blockchain protocols, DeFi systems, and cryptographic infrastructure.

I currently lead engineering at **ChainScore Labs**, where I have worked extensively across Ethereum, Polkadot, Substrate, Solana, NEAR, and more recently **JAM**. My work spans node clients, protocol implementations, cryptography libraries, SDKs, developer tooling, and performance-critical systems.

I am a Polkadot Blockchain Academy Cohort 4 (HK) alumnus and have been deeply involved in Polkadot protocol-level development over the last several years.

GitHub: [https://github.com/prasad-kumkar](https://github.com/prasad-kumkar)

---

### Motivation for Applying to the Polkadot Technical Fellowship

Polkadot is the ecosystem where I have consistently found the deepest technical challenges and the strongest culture of rigorous engineering since been to PBA.

I believe with **JAM**, Polkadot is entering a phase that demands long-term, protocol-first contributors who are willing to invest years into correctness, performance, and developer experience. My motivation for applying to the Technical Fellowship is to formally commit to this long-term stewardship role.

I am already spending the majority of my time working on JAM related infrastructure, including clean-room client implementation, cryptography, and developer tooling. The Fellowship aligns well with how I am already contributing and would allow me to deepen this work in closer coordination with the wider Polkadot technical community.

---

### Areas of Interest in the Polkadot Ecosystem

My primary areas of interest are:

* JAM client implementation
* PVM execution, compilation and performance optimization
* Cryptography for consensus and randomness (VRFs, ring proofs)
* Developer tooling and SDKs for JAM adoption
* Data availability, networking, and protocol correctness

---

### Contributions to Polkadot and JAM

#### **Tessera – JAM Node Client (Python)**

I lead the **Tessera** team, which is building a clean-room implementation of the JAM protocol in Python.

Contributions include:

* PVM interpreter 
* Codec and protocol modules
* QUIC-based P2P networking and gossip
* Erasure coding for JAM data availability
* x86 recompiler for PVM focused on high throughput execution

Repository: [https://github.com/Chainscore/tessera](https://github.com/Chainscore/tessera)

---

#### **Dotring – Cryptography Libraries for Polkadot / JAM**

I worked on **Dotring**, an open source cryptography library implementing:

* IETF VRF
* Pedersen VRF
* Ring signatures and ring proofs
* Fiat–Shamir transcripts
* Support for multiple Twisted Edwards curves including Jubjub, Ed25519, Bandersnatch

This work is based on Web3 Foundation research and is intended for use in Polkadot and JAM consensus related components.

Repository: [https://github.com/chainscore/dot-ring](https://github.com/chainscore/dot-ring)

---

#### **Jamcode.fun – JAM Developer Playground**

I built **Jamcode.fun**, an IDE style playground for developing and invoking services on JAM. The goal is to significantly lower the barrier for developers experimenting with JAM services and execution.

Website: [https://jamcode.fun](https://jamcode.fun)

---

#### **Ajanta – JAM SDK (C, C++ and Python)**

I'm currently working on Ajanta, a multi-language JAM SDK designed to make building applications and services on JAM accessible.

Repository: [https://github.com/Chainscore/ajanta](https://github.com/Chainscore/ajanta)

---

### Closing

I am applying to the Polkadot Technical Fellowship to formalize and deepen my long-term commitment to Polkadot and JAM. My focus is on protocol-level work that improves resilience, performance, and developer experience, and I intend to continue contributing at this level for years to come.

Thank you for your time and consideration.

Application for Technical Fellowship: Prasad Kumkar

### Background information of the applicant
My name is Rohit Sarpotdar. I began working in Solana & ICP ecosystem, building contracts for social interactions since 2020. I graduated from PBAW5 and later joined Parity in Bridges team.
Since last 10 months I'm focusing on building features and maintaining bridges & runtimes.

### Motivation(s) for applying to the Polkadot Technical Fellowship
I’m applying to the Polkadot Technical Fellowship because I work on Polkadot, and would like to add my voice to this collective.

### Area(s) of interest in relation to the Polkadot ecosystem.
- Enhancing Bridges, System Parachains and Runtimes
- Development of CoreJAM and VMs
- SCC and Bulletin chain

### Contribution(s) to Polkadot SDK (if any)

- [Polkadot SDK contributions](https://github.com/paritytech/polkadot-sdk/issues?q=is%3Aissue%20is%3Apr%20author%3Arosarp) : I have contributed to the polkadot-sdk by implementing small features aimed at improving the overall development experience.
- [Bridges Contributions](https://github.com/paritytech/parity-bridges-common/issues?q=is%3Aissue%20is%3Apr%20author%3Arosarp) : I have contributed small features, upgraded and deployed P/K bridge substrate-relayer & runtimes.
- Contributed to SCC testing
- Currently working on testing Bulletin chain


### Link to the GitHub profile of the applicant

https://github.com/rosarp/

### Polkadot address with a verified on-chain identity

[143KKEzwsyjmTAjjpk75mCM4DYopmXTM52s6Lnj8udvX9Pxf](https://polkadot.subsquare.io/user/143KKEzwsyjmTAjjpk75mCM4DYopmXTM52s6Lnj8udvX9Pxf/identity)


Fellowship Application - Rohit Sarpotdar

## Background information of the applicant

My name is Alexandre Baldé. I began working in what is now called Web3 in 2016, in the Cardano protocol.
I currently work at Parity, in the System Parachains team.
I focus on testing, and have, for that purpose, contributed to the Polkadot SDK, the [Polkadot Fellowship runtimes](https://github.com/polkadot-fellows/runtimes)
and the Polkadot Ecosystem Tests [(PET)](https://github.com/open-web3-stack/polkadot-ecosystem-tests) project.

## Motivation(s) for applying to the Polkadot Technical Fellowship

From the Polkadot Fellowship Manifesto: "The Fellowship can be seen as a political collective in that it has an on-chain voice [...]".
I’m applying to the Polkadot Technical Fellowship because I work on Polkadot, and would like to add my voice to this collective.

From my work on PET, I have ideas on how to improve the testing process of Polkadot SDK development.
The Polkadot Technical Fellowship offers a venue in which to discuss and refine these ideas with other techincal
contributors, so that these improvements benefit everyone building on Polkadot.

## Area(s) of interest in relation to the Polkadot ecosystem.

System Parachains, Runtime/FRAME development and testing.

## Contribution(s) to Polkadot SDK (if any)

My contributions to the Polkadot SDK mostly relate to/result from my work on PET.
- I am part of the team working on the Asset Hub Migration, where I assist with testing
    - in paritcular, I've helped test the post-migration relay/asset hub runtimes via Chopsticks/PET
- I've found some issues with FRAME pallets
    - a minor issue with irremovable pure proxy accounts of some types
    - an issue with burning funds on Kusama relay chain post-AHM
    - missing events in some FRAME pallets' extrinsics
        - nomination pools, conviction voting, proxy, identity, vesting
- A refactor of `pallet-revive` to have its gas metering functionality be EIP-150-compliant
- I extended tests for people chain runtimes with the `xcm-emulator` tool

### Links

[Polkadot SDK monorepo contributions](https://github.com/paritytech/polkadot-sdk/issues?q=is%3Aissue%20is%3Apr%20author%3Arockbmb)

[Fellowship Runtimes contributions](https://github.com/polkadot-fellows/runtimes/pulls?q=is%3Apr+author%3Arockbmb)

[Pre-monorepo contributions (from 2019)](https://github.com/paritytech/substrate/pulls?q=is%3Apr+is%3Aissue+author%3Arockbmb+)

## Link to the GitHub profile of the applicant

https://github.com/rockbmb

## Polkadot address with a verified on-chain identity

13jBAtYJar4xujPaEx41FxjSt9PqU7LqJRbySJiVdMtuWN42


Application to join Polkadot Fellowship - Alexandre Baldé

**Background information of the applicant**

My name is Christopher Kalule I am based in Uganda. I come with 8+ years of experience in full stack development but now more focused on Rust & Blockchain. In the past, I have  worked with Golang, Javascript and QA. Proving my ability to build reliable, performant, scalable, and secure Web2 and Web3 systems. I believe open source would help me grow into a better engineer and that is how I stumbled onto Polkadot-SDK. With good rust skills which I earned in the Let's Get Rusty Live program. [Link to certificate](https://drive.google.com/file/d/1yZ9f5L0ap5yOOTmN-8LvvCaO7xnen9a_/view).  Allowed me to tackle some contributions I will Elaborate on below. And also a graduate of [PBA-X Wave #4](https://app.kajabi.com/certificates/d22ebcca). This was a mind blowing experience.  I also volunteered as a technical mentor at Polkadot Africa(Uganda) technical workshop in preparation for sub0, where is spoke on why blockchain & tokens  to building a [Poet Auction smart contract](https://dev.to/chri5_kalul3/building-a-poetry-auction-smart-contract-on-polkadot-with-ink-4aj9) with ink!v6. 

**Motivation(s) for applying to the Polkadot Technical Fellowship**

Becoming Developer Advocate for Polkadot Africa (Uganda) on October 9th crystallized what I want to accomplish. The Fellowship represents the technical depth I need to be effective in that role not just explaining Polkadot, but actively building with it. I want to contribute to the SDK while staying plugged into new implementations so I can create relevant, timely content for developers in my region and others. Working with experienced engineers would accelerate my web3 principles and Rust development while ensuring the guidance I give other developers is grounded in real practice, not just documentation.

**Area(s) of interest in relation to the Polkadot ecosystem.**
    - I'm interested in Node SDK work and runtime development—building the core components that parachains depend on. Smart contracts, especially through Pallet Revive, also fascinate me because that's where we're lowering barriers for developers coming from other ecosystems. It's the intersection of infrastructure and accessibility
    - JAM

**Contribution(s) to Polkadot SDK (if any)**
    - My work on Polkadot SDK spans three main areas: building out runtime support for XCM benchmarking across sibling parachains, collaborating with maintainers to remove legacy feature gates and reduce technical debt in core subsystems, and automating testnet setup for Omni Node to make development more efficient [Link to Contributions](https://github.com/paritytech/polkadot-sdk/pulls?q=is%3Apr+is%3Aclosed+author%3AEleisonC)

**Link to the GitHub profile of the applicant**
    - https://github.com/EleisonC

Application To Join FellowShip - Christopher

### Background

My name is Enoch, a full-stack developer specializing in Rust and TypeScript. Deeply interested in permissionless systems, web security, performance, and accessibility. I’ve made contributions to the Polkadot ecosystem as well as other Substrate-based [codebases](https://github.com/darwinia-network/darwinia/pull/953), and have built several open-source projects focused on developer experience and payment integrations.

I have contributed to the Polkadot ecosystem across its architectural evolution—beginning with the separate polyrepo structure (Substrate, Polkadot) and now actively contributing to the consolidated polkadot-sdk monorepo as runcomet. My engagement deepened after participating in the early [Runtime Developer Guide](https://youtu.be/J2JaavOEDN8?si=G5A-S2k4lXGGMVkD) sessions and its initial study group.

### Motivation
Having been around the ecosystem for some time now I have a unique perspective on the evolution of the technology, The Fellowship represents the next logical step for me to deepen my commitment. I am particularly eager to engage in the technical discussions and RFC processes that shape the platform, as evidenced by my initiative to work on [RFC-0097](https://polkadot-fellows.github.io/RFCs/approved/0097-unbonding_queue.html#proposed-parameters).

### Areas of interest

* Runtime
* Node Development & Tooling
* Join-Accumulate Machine (JAM)

### Contributions to the SDK

Polyrepo Era:
* [Substrate](https://github.com/paritytech/substrate/pulls?q=is%3Apr+author%3AECJ222+is%3Aclosed+is%3Amerged)
* [Polkadot](https://github.com/paritytech/polkadot/pulls/ECJ222)

Monorepo Era (as runcomet):
* [Polkadot-SDK](https://github.com/paritytech/polkadot-sdk/pulls?q=is%3Apr+author%3Aruncomet+is%3Aclosed+is%3Amerged)
* [RFC #0097 (Implementation)](https://github.com/paritytech/polkadot-sdk/pull/7398)

Link to GitHub Profile
* [Current (Primary)](https://github.com/runcomet)
* [Historical](https://github.com/ECJ222)



Application - Runcomet

Dear Polkadot Fellowship Team,

My name is Kaushik and I recently completed the PBA course in Bali where I got to learn so much about the inner workings of everything from Merkle storage to how the different ways in which XCM can make cross chain transfers! After leaving, I have this feeling like I want to contribute more and make a meaningful impact to the ecosystem, so I want to join the fellowship to see how I can do that alongside my current job :)

**Background Information**

I am a blockchain engineer currently working at Dakota, where I contribute to building a stablecoin banking platform. Prior to this, I worked in different-levels of blockchain development, including MEV execution client work, a Solana Trader API to enable traders to more easily trade on market makers like Jupiter and Serum and have even worked on an [open-souce game engine](https://github.com/curio-research/keystone)! I recently graduated from the Polkadot Blockchain Academy in Bali, where I deepened my understanding of Substrate, FRAME, XCM, and consensus mechanisms. My academic background also includes research in computational neuroscience, where I applied mathematical modeling to zebrafish neural activity. I am largely self-taught in programming, beginning after college, and have since built a career at the intersection of protocol engineering, applied cryptography, and distributed systems.

**Motivation for Applying**
I am applying to the Fellowship because I want to contribute to the long-term sustainability of the Polkadot ecosystem. Polkadot has consistently pushed the boundaries of what decentralized networks can achieve—from flexible runtime upgrades to secure cross-chain communication. I want to be part of the technical community that ensures these innovations remain robust, performant, and accessible to builders. The Fellowship also represents an opportunity to learn from and collaborate with engineers whose work I deeply respect, while sharing my own insights from both my PBA experience and ongoing protocol-level development.

**Areas of Interest**

My main areas of interest include:
1. Runtime engineering and governance: designing and refining FRAME pallets, validator/delegator logic, and governance mechanisms that make Polkadot resilient. 
2. Cross-chain communication: improving the developer and user experience of XCM, particularly around asset transfers, error handling, and cross-chain programmability. 
3. Consensus and scalability: exploring performance bottlenecks and contributing to solutions that enhance Polkadot’s throughput and security.

**Work Relevant to Polkadot SDK:**

- Implemented and tested a Delegated Proof-of-Stake pallet during PBA, including partially supporting delegation cycles, validator registering/staking, and reward distribution logic.

- Designed and tested XCM asset transfer flows between parachains and the relay chain, ensuring proper encoding/decoding of messages and error handling.

**GitHub Profile**
https://github.com/kdonthi

**Polkadot Address**
14fnnUEFRnJ1GxXPWxt7paewtKqjcjmAhiNKr1qavTkPRsxk

I look forward to use what I've learned and hopefully get to make an impact :) 

**Resume**
https://docs.google.com/document/d/1-z1mQyb_wbv1prlQ6paTAUX_7nW9zfqeKVNvygj_Csc/edit?usp=sharing


PBA Protocol Graduate and Blockchain Dev with ~4 years of Experience Interested in Making Polkadot Great

### Background Information

Hello, my name is Rodrigo Quelhas. I’m based in Portugal and currently work as a core developer at Moonbeam. I have over seven years of experience as a Blockchain Engineer, with the past four years focused primarily on the Polkadot ecosystem.

### Motivation

Having worked extensively with Substrate, Polkadot, and Cumulus for the past four years, I am eager to take a more active role in shaping the future of the ecosystem. Joining the Polkadot Technical Fellowship would give me the opportunity to stay closely aligned with the direction of core development, participate in important technical discussions, and contribute directly to the long-term health and evolution of the network.

### Areas of Interest

- Enhancing core libraries, runtime development, and performance optimization;
- Consensus and networking.

### Contributions to Polkadot SDK

I have contributed to the polkadot-sdk by fixing bugs, refactoring code, and implementing small features aimed at improving the overall development experience. These contributions have helped enhance code quality, maintainability, and usability for other developers working within the ecosystem.
A list of my merged pull requests can be found here:  [Polkadot SDK Contributions](https://github.com/paritytech/polkadot-sdk/pulls?q=is:pr+author:RomarQ+is:closed)

### GitHub Profile

You can find my GitHub profile here: https://github.com/RomarQ

Rodrigo Quelhas - Application

Dear Polkadot Community,

My name is Juan, and I am a graduate of PBA7 – Bali.

**Background**

I am a Full Stack Developer with 5 years of professional experience. I began my career in blockchain, but later transitioned into Web2 after receiving an opportunity to work on CERN’s open-source project, Indico: https://github.com/indico/indico

My main focus was developing a private plugin for this platform, which serves millions of users worldwide. While most of my contributions remain private, I successfully resolved several bugs and contributed features to the open-source project as well.

At the end of my contract in late 2024, I decided to return to Web3, completing both PBA-X and PBA programs.

**Motivation**

I am now eager to contribute to open-source projects within the Web3 space, and recently discovered the Polkadot Fellowship. My goal is to actively support the growth of the Polkadot ecosystem and, over time, advance within this community based on merit and contribution.

At present, I am familiarizing myself with the initial PR process and actively engaging with the community on Discord to identify areas where I can be most helpful. While my expertise is in backend development, I am also capable of working on frontend tasks, particularly with React, when necessary.

Here is my **GitHub profile** for reference: https://github.com/jbtwist

Given my current stage, I would like to kindly request the **Level 0 rank**.

Sincerely,
Juan

Applicant - Juan

<!DOCTYPE html>
<html lang="en">
<head>
 <meta charset="UTF-8">
</head>
<body>
 My name is Giorge Abdala, and I have over 15 years of experience as a Software Engineer and have been a passionate Linux enthusiast for more than two decades. I have developed a strong foundation in system architecture, complex problem-solving, and a deep passion for open-source technology.

 My involvement with the Polkadot ecosystem is active and growing. As an ambassador, I have represented Polkadot at major events in Brazil such as Blockchain Rio, Blockchain São Paulo, Smart City Expo (2024 and 2025) and Futurecom 2024.

 I co-organized the Decoded Party View Curitiba (2023) and gave talks at events such as 
 <a href="https://x.com/johnrhodelb/status/1802537176682377561?t=fo2umwqFT_zE5a621Z59NQ&s=19" target="_blank">Connection Week 2024</a> and 
 <a href="https://lu.ma/modularcuritiba?tk=SDzWVr" target="_blank">Modular Cripto 2024</a>, where I presented on Substrate and JAM.
 

 In 2025, I also participated in a 
 <a href="https://www.youtube.com/live/Bzs5IQRlagI?si=LEhz0K1S1PKUrZM6" target="_blank">podcast hosted by the Prefeitura de Curitiba</a>, where I spoke about Polkadot.
 

 These efforts reflect my commitment to knowledge-sharing and community building, which are core pillars of the Fellowship (Manifesto, sections 2.3.4 – Nurturing; 6.2 – I Dan). I am also responsible for running the first Polkadot full node in South America.

 It has always been a dream of mine to become a Substrate developer and join the Fellowship. Over the last two years, I have pursued a focused path of study, which included:

 <ul>
 <li>A deep dive into fundamental blockchain concepts: validation, consensus mechanisms, rollup functionality, and Layer 2 solutions.</li>
 <li>Progressive mastery of Rust:</li>
 </ul>

 I have read the entire Rust Book.

 
 I completed the course 
 <a href="https://www.udemy.com/certificate/UC-d98b39b2-f792-46a7-9758-b090d675dc10/" target="_blank">
 Rust: The Complete Developer's Guide</a> by Stephen Grider, which greatly clarified my understanding of ownership, borrowing, and generics.
 

 I also read 
 <a href="https://www.linkedin.com/posts/giorgeabdala_rust-rustaceans-programming-activity-7329130765433180160-B5Dk?utm_source=share&utm_medium=member_desktop&rcm=ACoAAD2V9AwBPpalTaVx7Kn3Rod0t-mv3uWkRsg" target="_blank">
 Rust for Rustaceans</a>, which explores advanced memory management concepts, concurrent programming, ownership, WASM, among others.


 This dedication to learning Rust resulted in practical applications. Professionally, I completely restructured a complex legacy system for processing tax credit requests for the state of Paraná/Brazil. I replaced an outdated architecture with a modern, high-performance Rust-based solution, reducing processing time from up to 48 hours to less than 30 seconds. This transformation demonstrates my ability to deliver “modest but substantial contribution to protocol development” (Manifesto, 6.2.1 - I Dan) and “elegant and, at least sometimes, reusable” implementations (Manifesto, p.9, III Dan).

 To complement my blockchain studies:

 I completed the Rust, Blockchain, and Polkadot Developer Formation course offered by Pontifical Catholic University of Paraná: 
 An advanced training focused on decentralized systems, smart contract development, Rust programming, Substrate-based blockchain networks, and Polkadot parachain architecture.
 

 I completed 
 <a href="https://app.kajabi.com/certificates/7360cc03" target="_blank">PBA-X</a>, the cohort-based, online blockchain course by the Polkadot Blockchain Academy — covering fundamental concepts in cryptography, economics, governance, interoperability, and using the Polkadot SDK.
 

I just finished reading the book 
 <a href="https://www.linkedin.com/posts/giorgeabdala_rust-blockchain-smartcontracts-activity-7335370243084541952-GUuO?utm_source=share&utm_medium=member_desktop&rcm=ACoAAD2V9AwBPpalTaVx7Kn3Rod0t-mv3uWkRsg" target="_blank">
 Rust for Blockchain</a>, which focuses on Rust concepts applied to blockchain, Substrate programming, pallets, FRAME, etc.


 In addition, I completed the 
 <a href="https://www.udemy.com/course/web3-academy-masterclass-rust/learn/lecture/45812449#overview" target="_blank">Web3 Academy Masterclass Rust</a> course by Web3 Surf. This course deepened my knowledge in developing pallets using Substrate FRAME, testing and benchmarking, working with off-chain workers, and performing runtime upgrades and migrations.
 

 I am currently practicing and studying through the Polkadot developer documentation (<a href="https://docs.polkadot.com/" target="_blank">https://docs.polkadot.com/</a>).

 My goal is to become a proficient Substrate developer, and I believe that the Polkadot Fellowship is the ideal environment to accelerate this growth. My aspiration is to reach the level of "Humble Member" (I Dan) and advance further over time. 
 I believe I am ready to face this challenge, and my intention is to start by solving GitHub issues, learning from more experienced members, and gradually taking on more responsibility. If anyone has suggestions for a “better path” or is willing to mentor me, I am completely open to discussion.

 
 Giorge Abdala 
 <a href="mailto:giorgeabdala@gmail.com">giorgeabdala@gmail.com</a> 
 <a href="https://www.linkedin.com/in/giorgeabdala" target="_blank">https://www.linkedin.com/in/giorgeabdala</a> 
 <a href="https://github.com/giorgeabdala" target="_blank">https://github.com/giorgeabdala</a>
 
</body>
</html>

Applicant - Giorge Abdala



## Background information of the applicant

My name is **Kunal Drall**, and I am a blockchain developer with hands-on experience in **Rust, Go, and Python**. I have been actively involved in the Substrate and Polkadot ecosystem through **hackathons, grants, and open-source development**, focusing on building practical, production-oriented systems.

I recently graduated from **PBA-X Wave 5**, where I gained a strong foundation in decentralized systems, cryptography, governance, interoperability, and hands-on usage of the Polkadot SDK. This experience significantly strengthened my understanding of Polkadot’s architecture and governance model.

---

## Motivation(s) for applying to the Polkadot Technical Fellowship

I am applying to join the **Polkadot Technical Fellowship** because I want to contribute to the **long-term technical development and governance of the Polkadot network**.

I strongly align with the Fellowship’s guiding principles:
- Upholding Polkadot’s long-term interests  
- Respecting its technical philosophy and governance processes  
- Collaborating openly and respectfully with the community  

The Fellowship represents a technical collective where I can learn from experienced contributors while progressively adding value through sustained open-source work.

---

## Area(s) of interest in relation to the Polkadot ecosystem

My primary areas of interest include:

- Substrate & FRAME development  
- Runtime development and core components for parachains  
- Development of CoreJAM and virtual machines  
- Smart contracts, particularly through **Pallet Revive**, to reduce onboarding friction for developers from other ecosystems  
- Improving developer experience while preserving protocol robustness  

I am especially interested in the intersection of **infrastructure and accessibility** within the Polkadot ecosystem.

---

## Contribution(s) to Polkadot SDK (if any)

While I am currently at an early stage of direct Polkadot SDK contributions, I am actively building within the ecosystem.

I am currently working on **Powergrid Network**, a **virtual power plant solution on Polkadot**, applying Substrate-based design patterns to real-world infrastructure coordination.

My near-term contribution goals include:
- Solving beginner- to intermediate-level Polkadot SDK GitHub issues  
- Improving documentation and developer tooling  
- Gradually contributing to runtime- and pallet-level code  

---

## Link to the GitHub profile of the applicant

- GitHub: https://github.com/kunal-drall  
- Project (Powergrid Network): https://github.com/kunal-drall/powergrid_network  

---

## Polkadot address with a verified on-chain identity

- Polkadot address:  
  `1U3JboaBjPViEFDwwzKpFLVeV2LHQx9Jy31FuMgHuRBnmxq`


Application to join the Polkadot Technical Fellowship — Kunal Drall

**Background**

I am a Computer Science & Engineering undergraduate based in India, with hands-on experience in full-stack development, cloud infrastructure, and blockchain systems. I have worked on production web applications deployed on AWS, built crypto wallets supporting Ethereum and Solana, and implemented secure backend systems using modern frameworks and databases. My technical interests lie at the intersection of distributed systems, developer tooling, and secure, user-friendly blockchain infrastructure.

I actively participate in hackathons and technical projects and maintain a strong problem-solving background through competitive programming. While I am still early in my Polkadot-specific contribution journey, I bring strong systems thinking, a willingness to learn deeply, and a long-term commitment to open-source ecosystems.

**Motivation**

I am applying to the Polkadot Technical Fellowship because I strongly believe in Polkadot’s vision of scalable, interoperable, and well-governed decentralized systems. The Fellowship’s merit-based, on-chain governance model resonates with my belief that technical expertise and sustained contributions should guide protocol evolution. I see the Fellowship as a structured path to grow into a responsible technical contributor while being held to high standards of rigor, transparency, and community accountability.

**Areas of Interest**

My primary areas of interest within the Polkadot ecosystem include:
- Polkadot SDK and runtime architecture
- Developer experience, tooling, and onboarding
- Cross-chain communication and interoperability
- Security, correctness, and maintainability of protocol-level code
I am particularly interested in understanding how Substrate-based systems are designed, reviewed, and evolved at scale.

Contributions to Polkadot SDK

I have not yet made direct contributions to the Polkadot SDK. However, I am actively studying the codebase and documentation and intend to begin contributing through issues, reviews, and incremental improvements. I view this application as a commitment to sustained, high-quality contributions rather than a claim of prior work.

Links
Portfolio: https://tusharshah.me/
GitHub: https://github.com/tusharshah21

Polkadot Address (with verified on-chain identity):
12xntR5vgCMqMzuF5BWer3YX27SvLY9So9Eq4V6ff4XfFbs7

Application to Join the Polkadot Technical Fellowship

<h2>Background information of the applicant</h2>My name is&nbsp;Kunal Drall, and I am a blockchain developer with hands-on experience in&nbsp;Rust, Go, and Python. I have been actively involved in the Substrate and Polkadot ecosystem through&nbsp;hackathons, grants, and open-source development, focusing on building practical, production-oriented systems.I recently graduated from&nbsp;PBA-X Wave 5, where I gained a strong foundation in decentralized systems, cryptography, governance, interoperability, and hands-on usage of the Polkadot SDK. This experience significantly strengthened my understanding of Polkadot’s architecture and governance model.<h2>Motivation(s) for applying to the Polkadot Technical Fellowship</h2>I am applying to join the&nbsp;Polkadot Technical Fellowship&nbsp;because I want to contribute to the&nbsp;long-term technical development and governance of the Polkadot network.I strongly align with the Fellowship’s guiding principles:<ol><li data-list="bullet">Upholding Polkadot’s long-term interests</li><li data-list="bullet">Respecting its technical philosophy and governance processes</li><li data-list="bullet">Collaborating openly and respectfully with the community</li></ol>The Fellowship represents a technical collective where I can learn from experienced contributors while progressively adding value through sustained open-source work.<h2>Area(s) of interest in relation to the Polkadot ecosystem</h2>My primary areas of interest include:<ol><li data-list="bullet">Substrate &amp; FRAME development</li><li data-list="bullet">Runtime development and core components for parachains</li><li data-list="bullet">Development of CoreJAM and virtual machines</li><li data-list="bullet">Smart contracts, particularly through&nbsp;Pallet Revive, to reduce onboarding friction for developers from other ecosystems</li><li data-list="bullet">Improving developer experience while preserving protocol robustness</li></ol>I am especially interested in the intersection of&nbsp;infrastructure and accessibility&nbsp;within the Polkadot ecosystem.<h2>Contribution(s) to Polkadot SDK (if any)</h2>I’ve made my first contribution to the polkadot-sdk here:👉&nbsp;<a href="https://github.com/paritytech/polkadot-sdk/pull/10713" rel="noopener noreferrer" target="_blank">https://github.com/paritytech/polkadot-sdk/pull/10713</a>This PR fixes an off-by-one bug in&nbsp;pallet-child-bounties&nbsp;and adds test coverage to strictly enforce&nbsp;MaxActiveChildBountyCount, I am actively building within the ecosystem.I am currently working on&nbsp;Powergrid Network, a&nbsp;virtual power plant solution on Polkadot, applying Substrate-based design patterns to real-world infrastructure coordination.My near-term contribution goals include:<ol><li data-list="bullet">Solving beginner- to intermediate-level Polkadot SDK GitHub issues</li><li data-list="bullet">Improving documentation and developer tooling</li><li data-list="bullet">Gradually contributing to runtime- and pallet-level code</li></ol><h2>Link to the GitHub profile of the applicant</h2><ol><li data-list="bullet">GitHub:&nbsp;<a href="https://github.com/kunal-drall" rel="noopener noreferrer" target="_blank">https://github.com/kunal-drall</a></li><li data-list="bullet">Project (Powergrid Network):&nbsp;<a href="https://github.com/kunal-drall/powergrid_network" rel="noopener noreferrer" target="_blank">https://github.com/kunal-drall/powergrid_network</a></li></ol><h2>Polkadot address with a verified on-chain identity</h2><ol><li data-list="bullet">Polkadot address:</li><li data-list="bullet">1U3JboaBjPViEFDwwzKpFLVeV2LHQx9Jy31FuMgHuRBnmxq</li></ol>

**Background information of the applicant**
My name is Stephen Lawrence, a software engineer with years of experience building and operating complex software systems. I’m deeply passionate about open source, and much of my work involves contributing to both Web2 and Web3 projects. My journey into the Polkadot ecosystem started with the SDK, an interest that was sparked during a workshop previously organized by Polkadot Africa. That experience really opened my eyes to the possibilities within the ecosystem, and I’ve been excited to contribute ever since.

**Motivation(s) for applying to the Polkadot Technical Fellowship**
As I've contributed more deeply to the SDK, I've developed a strong sense of ownership over the quality and reliability of the codebase. Joining the Fellowship feels like the right way to formalize that commitment, taking on greater responsibility, upholding high technical standards, and contributing to the long-term sustainability of the infrastructure we all depend on.

**Area(s) of interest in relation to the Polkadot ecosystem**
- Node SDK and runtime development
- FRAME
- JAM

**Contribution(s) to Polkadot SDK**
- I worked on deprecating the para_id field from chain specifications in favor of a more flexible runtime-based approach. While my initial PR (https://github.com/paritytech/polkadot-sdk/pull/7546) was closed, it helped lay the groundwork by introducing the idea of retrieving the parachain ID via a runtime API. That direction was later expanded upon and fully realized in https://github.com/paritytech/polkadot-sdk/pull/8651, which completed the transition to a dynamic, runtime-driven approach.

- I also added a new add_potential_renewal() extrinsic to the Coretime Broker pallet (https://github.com/paritytech/polkadot-sdk/pull/10824). This gives network administrators, especially in testnet and governance contexts, more direct control over coretime renewals, making it easier to manage allocations and schedule renewals with precision.

- Currently, I’m working on a larger refactor to introduce VersionedCall across pallets that store calls (such as Scheduler, Multisig, Lottery, Collective, and Democracy). The goal is to make stored calls version-aware so they can’t be executed in ways that become invalid after runtime upgrades. This improves safety, prevents unintended behavior, and strengthens the reliability of governance and scheduled execution. You can follow along here: https://github.com/paritytech/polkadot-sdk/pull/10931.

- You can also check out my other ongoing contributions here: https://github.com/paritytech/polkadot-sdk/issues?q=is%3Apr+is%3Aopen+author%3AStephenlawrence00

**Link to the GitHub profile of the applicant**
https://github.com/Stephenlawrence00

Polkadot address with a verified on-chain identity
16Xj1rSgNBtzHch3Jb9SfW7dK749s9WbCqKcwmZCFkR2pnai

Applications