Add promotion argument: josepot Candidate → Rank II

argument/josepot/0001-josepot-promotion-rank-2.md

@@ -0,0 +1,117 @@
+# Argument-0001: Promotion to Rank II
+
+|                 |                                                                             |
+| --------------- | --------------------------------------------------------------------------- |
+| **Report Date** | 2026/06/09                                                                  |
+| **Submitted by**| Josep M Sobrepere                                                           |
+
+
+## Member details
+
+- Matrix username: @josepot:matrix.org
+- Polkadot address: 15roJ4ZrgrZam5BQWJgiGHpgp7ShFQBRNLq6qUfiNqXDZjMK
+- Current rank: Candidate (0)
+- Date of initial induction: 2026/06/09
+- Date of last report: N/A
+- Area(s) of Expertise/Interest: Standard RPCs (new JSON-RPC spec), light-clients, developer-facing protocol APIs, transaction/extrinsic format design, runtime upgrade tooling.
+
+
+## Reporting period
+
+- Start date: 2021/09/01
+- End date: 2026/06/09
+
+
+## Argument
+
+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.
+
+---
+
+### Rank I criteria (exceeded)
+
+**Three clear examples of a substantial contribution to protocol development:**
+
+1. **Polkadot-API (PAPI)**: I am the primary author and technical lead of [PAPI](https://github.com/polkadot-api/polkadot-api), 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](https://polkadot.subsquare.io/referenda/467), [#695](https://polkadot.subsquare.io/referenda/695), [#1103](https://polkadot.subsquare.io/referenda/1103), [#1462](https://polkadot.subsquare.io/referenda/1462), [#1856](https://polkadot.subsquare.io/referenda/1856), [#1874](https://polkadot.subsquare.io/referenda/1874)).
+
+2. **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](https://github.com/paritytech/json-rpc-interface-spec): the `transaction:searched` event ([#80](https://github.com/paritytech/json-rpc-interface-spec/pull/80)), explicit `finalized` guarantees ([#76](https://github.com/paritytech/json-rpc-interface-spec/pull/76)), the `inaccessible` event fix ([#65](https://github.com/paritytech/json-rpc-interface-spec/pull/65)), `rpc_methods` return value ([#129](https://github.com/paritytech/json-rpc-interface-spec/pull/129)), and multiple design RFCs including batching storage requests ([#47](https://github.com/paritytech/json-rpc-interface-spec/issues/47), [#48](https://github.com/paritytech/json-rpc-interface-spec/issues/48)) and `stop` event semantics ([#86](https://github.com/paritytech/json-rpc-interface-spec/issues/86)).
+
+3. **`createTransaction` RFC**: I authored a detailed RFC ([polkadot-js/api#6213](https://github.com/polkadot-js/api/issues/6213), [forum post](https://forum.polkadot.network/t/toward-an-interoperable-transaction-interface-introducing-createtransaction/15060)) 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](https://forum.polkadot.network/t/papi-and-runtime-upgrades-making-dapps-truly-resilient/13178)). The companion tool [diff.papi.how](https://diff.papi.how) is now used by runtime teams during upgrade reviews.
+
+I designed the `PolkadotProvider` interface ([forum post, October 2023](https://forum.polkadot.network/t/polkadot-provider-api-a-common-interface-for-building-decentralized-applications/4128)): 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](https://assethub-polkadot.subscan.io/nft_item?collection_id=171&address=15roJ4ZrgrZam5BQWJgiGHpgp7ShFQBRNLq6qUfiNqXDZjMK). 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**.
+
+---
+
+### Rank II criteria
+
+**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:
+
+- Full TypeScript implementation of the `chainHead`, `transaction`, and `archive` JSON-RPC namespaces
+- A metadata-driven type system that generates strongly typed, chain-agnostic descriptors from on-chain metadata
+- Recovery from `stop` events, runtime upgrade handling, and compatibility checking
+- A modular provider system enabling light-client (smoldot) and WebSocket backends interchangeably
+- Performance benchmarks and integration tests.
+
+**`@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](https://forum.polkadot.network/t/introducing-polkadot-api-check-runtime-quick-checks-for-runtime-upgrades-library-cli/15225)) is integrated as a **required check** in the `polkadot-fellows/runtimes` CI pipeline: the [`check-runtimes` job](https://github.com/polkadot-fellows/runtimes/blob/main/.github/workflows/test.yml) 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:
+
+- [polkadot-fellows/runtimes#1117](https://github.com/polkadot-fellows/runtimes/pull/1117): Replaced the generic `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.
+- [paritytech/polkadot-sdk#7959](https://github.com/paritytech/polkadot-sdk/pull/7959): Treasury: reset `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](https://github.com/paritytech/smoldot/pull/1710)), browser error handling ([#2171](https://github.com/paritytech/smoldot/pull/2171)), and error naming ([#2019](https://github.com/paritytech/smoldot/pull/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:
+
+- [Toward an Interoperable Transaction Interface: Introducing `createTransaction`](https://forum.polkadot.network/t/toward-an-interoperable-transaction-interface-introducing-createtransaction/15060): Protocol-level RFC for the transaction-creators interface, explaining the failures of `signPayload` and the design of its replacement.
+- [New JSON-RPC API Q4 2024 Update](https://forum.polkadot.network/t/new-json-rpc-api-q4-2024-update/10541): Ecosystem-wide compliance audit identifying 13 non-compliant parachains and proposing remediation paths.
+- [Can pallet-revive help improve Polkadot's UX?](https://forum.polkadot.network/t/can-pallet-revive-help-improve-polkadots-ux/12923): Technical analysis of the precompile approach and its impedance mismatch with Polkadot's evolving pallet model.
+- [PAPI and Runtime Upgrades: Making dApps Truly Resilient](https://forum.polkadot.network/t/papi-and-runtime-upgrades-making-dapps-truly-resilient/13178): Deep technical analysis of metadata-driven compatibility checking and the runtime upgrade resilience problem.
+- [Why Polkadot-API](https://forum.polkadot.network/t/why-polkadot-api/15468): Architectural rationale: tight coupling and leaky abstractions in the existing ecosystem, and how PAPI's composable design addresses them. Includes performance benchmarks.
+
+Additional quarterly progress and technical updates: [Q4 2023](https://forum.polkadot.network/t/polkadot-api-2023-q4-update/5318), [Q1 2024](https://forum.polkadot.network/t/polkadot-api-2024-q1-update/7462), [Q2 2024](https://forum.polkadot.network/t/polkadot-api-2024-2nd-update/9673), [Q1 2025](https://forum.polkadot.network/t/polkadot-api-2025-q1-update/11906), [JSON-RPC Q3 2025](https://forum.polkadot.network/t/new-json-rpc-api-q3-2025-update-introducing-legacy-provider-and-moar/14394).
+
+I also presented at **Polkadot Decoded 2024** in Brussels: [*Build a Modern dApp with Polkadot-API*](https://www.youtube.com/watch?v=fj63gYJmuIk).
+
+---
+
+### On the choice of Rank II over Rank III
+
+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.
+
+
+## Voting record
+
+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%   | | |
+
+
+## Misc
+
+- [ ] I am open to any questions from Fellowship members about the scope or depth of the contributions described above.