| Report Date | 2026/06/09 |
| Submitted by | Josep M Sobrepere |
I am requesting a fast-track promotion directly from Candidate to Rank II. My contributions since joining the Polkadot ecosystem in September 2021 clearly satisfy the requirements for Rank II as stated in Section 6 of the Manifesto. I considered requesting Rank III, but prefer to begin at Rank II and earn a promotion to Rank III through demonstrated Fellowship participation in the coming months.
Three clear examples of a substantial contribution to protocol development:
Polkadot-API (PAPI): I am the primary author and technical lead of PAPI, the recommended successor to polkadot.js. PAPI is a full implementation of the new JSON-RPC specification for the application layer: it is how the vast majority of modern dApps and wallets interact with Polkadot today. It has shipped 118+ releases across 4+ years of active development and is continuously funded by the Polkadot Treasury (6 approved referenda, each with near-unanimous support: #467, #695, #1103, #1462, #1856, #1874).
JSON-RPC interface spec contributions: As the primary implementer of the new JSON-RPC spec, I have contributed fixes and design proposals directly to paritytech/json-rpc-interface-spec: the transaction:searched event (#80), explicit finalized guarantees (#76), the inaccessible event fix (#65), rpc_methods return value (#129), and multiple design RFCs including batching storage requests (#47, #48) and stop event semantics (#86).
createTransaction RFC: I authored a detailed RFC (polkadot-js/api#6213, forum post) proposing a new, forward-compatible signer interface to replace signPayload. The core problem: signPayload predates Metadata V14, cannot handle custom extensions, and has broken nearly every dApp each time a signed extension has changed. The createTransaction interface passes full metadata and an explicit extension list, making it resilient to protocol evolution and compatible with Extrinsic V5. This RFC is driving the ecosystem-wide migration of the wallet/dApp signing boundary.
Involvement in designing components at publication standards:
I co-designed (with Victor Oliva) PAPI's fine-grained runtime compatibility system: the insight that metadata determines dApp compatibility, not raw SCALE encoding, and formalised it in a public technical deep-dive (PAPI and Runtime Upgrades, June 2025). The companion tool diff.papi.how is now used by runtime teams during upgrade reviews.
I designed the PolkadotProvider interface (forum post, October 2023): the standard interface decoupling dApp development from polkadot.js internals, which led directly to @polkadot-api/light-client-extension-helpers and transformed the @substrate/connect extension to comply with the new standard.
Knowledge of Polkadot's key goals, principles and tenets:
I graduated with distinction from the Polkadot Blockchain Academy, Cohort V (Singapore, May–June 2024): graduation NFT. For the following two PBA cohorts: Cohort VI (Lucerne) and Cohort VII (Bali), my team and I designed the dApps track curriculum from scratch and served as its primary instructors.
Primary individual responsible for the formalisation, implementation, or analytical improvement of a major component:
PAPI constitutes the application-layer implementation of Polkadot's standard JSON-RPC API, the primary interface through which the network is consumed by modern dApps, tools, and wallets. I am the primary author, architect, and technical lead. The work includes:
chainHead, transaction, and archive JSON-RPC namespacesstop events, runtime upgrade handling, and compatibility checking@polkadot-api/check-runtime, required gate in the Fellowship's CI:
The Manifesto explicitly lists "user-interface code required to practically execute upgrades to the Polkadot (Main) Network" as in scope. My @polkadot-api/check-runtime CLI (announcement) is integrated as a required check in the polkadot-fellows/runtimes CI pipeline: the check-runtimes job runs npx @polkadot-api/check-runtime@latest problems against every runtime WASM artifact before a PR can be merged. It is listed as a required dependency of the CI gate, no runtime upgrade to the Polkadot (Main) Network can be merged without passing this check.
Contributions to polkadot-fellows/runtimes and polkadot-sdk:
Beyond tooling, I have contributed directly to the Fellowship's runtimes and to the Polkadot SDK:
ExtrinsicBaseWeight constant with chain-specific values in fee calculation modules. A subtle but impactful correctness fix: the mismatch between the constant in use and the actual value in System.BlockWeights.per_class_normal.base_extrinsic caused fee calculation tools to silently produce wrong results. Merged March 2024.payout.expire_at on each valid payout attempt, fixing an edge case in Treasury payout expiry logic.I also contributed several fixes and improvements to smoldot (the light client itself): TypeScript type definition fixes that unblocked downstream type safety (#1710), browser error handling (#2171), and error naming (#2019).
The breadth and continuity of this work are evidenced by six consecutive Treasury referenda spanning from February 2024 to February 2027, each passed with near-unanimous community support.
At least one published long-form semi-technical article concerning Polkadot:
I have published extensively on the Polkadot Forum, including several substantial technical pieces:
createTransaction: Protocol-level RFC for the transaction-creators interface, explaining the failures of signPayload and the design of its replacement.Additional quarterly progress and technical updates: Q4 2023, Q1 2024, Q2 2024, Q1 2025, JSON-RPC Q3 2025.
I also presented at Polkadot Decoded 2024 in Brussels: Build a Modern dApp with Polkadot-API.
The depth and longevity of my contributions, the ecosystem-wide impact of PAPI, and my work shaping the JSON-RPC specification would justify a Rank III argument. However, I prefer to begin my Fellowship membership at Rank II, participate actively in technical discussions over the coming months, and demonstrate through that participation that I am ready for Rank III. I believe earning promotion through Fellowship engagement is more appropriate than requesting it upfront.
As a newly inducted Candidate, I have not yet been eligible to vote in any Fellowship referenda.
| Ranks | Activity thresholds | Agreement thresholds | Member's voting activities | Comments |
|---|---|---|---|---|
| I | 90% | N/A | N/A — inducted as Candidate on 2026/06/09 | |
| II | 80% | N/A | ||
| III | 70% | 100% | ||
| IV | 60% | 90% | ||
| V | 50% | 80% | ||
| VI | 40% | 70% |
Threshold