| Report Date | 2026/05/25 |
| Submitted by | Nasihudeen Jimoh |
I am Nasihudeen Jimoh (Kanasjnr on GitHub), a Fellowship Candidate inducted on 2025/10/31, seeking promotion to Rank I (Dan 1). My work since induction has focused on polkadot-sdk and, where it affects live networks, polkadot-fellows/runtimes , improving FRAME developer experience, transaction validation, benchmarking accuracy, bridge tooling, and system-chain configuration.
Per Manifesto §6.2.1, promotion to Rank I requires three clear examples of modest but substantial contribution to protocol development, among other qualities (independence, component involvement, protocol awareness). Below I address those requirements directly.
#[stored] procedural macro for FRAME storage typespolkadot-sdk#10195 introduces a #[stored] attribute that collapses the repetitive derives, scale_info/codec attributes, and trait bounds required when defining pallet storage types.
Why it matters: Storage definitions are a daily task for runtime developers; the previous pattern was verbose and easy to get wrong (especially around MaxEncodedLen and phantom types). This is a non-trivial simplification of a core FRAME workflow similar in spirit to improving the ergonomics of a language primitive used across every runtime.
async-std to tokio in bridge relay cratespolkadot-sdk#11214 removes the deprecated async-std dependency from the workspace and migrates affected bridges/relays crates (equivocation-detector, finality-relay, messages-relay, parachains-relay, relay-substrate-client, relay-utils, substrate-relay-helper) to tokio primitives already used elsewhere in the workspace.
Why it matters: Bridge relayers are operationally important for trust-free connectivity; keeping their async stack on a maintained runtime avoids security/maintenance drift and aligns the codebase with workspace standards.
polkadot-sdk#11107 adds optional metadata-based detection of the correct Aura authority ID type (ed25519 vs sr25519) instead of hard-coding assumptions per chain (e.g. Asset Hub vs others).
Why it matters: Wrong authority ID typing produces subtle, chain-specific failures in node tooling. Deriving the type from runtime metadata makes Omni-Node more correct and less error-prone for operators and integrators.
Deprecation cleanup as part of polkadot-sdk#11561, following review guidance to land one removal per PR:
WeightMeter::defensive_saturating_accrue (use consume)polkadot_runtime_common::NegativeImbalance (use fungible::Credit)parachains_common::ToStakingPot (use ResolveTo)frame_support::EnsureOneOf (use EitherOfDiverse)sp_core hashing re-exports (use sp_crypto_hashing)frame_support::error re-export module (use sp_runtime::traits::{BadOrigin, LookupError})Further merged removals under #11561 may land separately; see open PRs below.
Manifesto §6.2 expects knowledge-discovery and knowledge-sharing (forums, public discussion), not only merged code. Alongside SDK work I have published protocol-focused analysis on the Polkadot Forum and built substrate-consensus-lab, a minimal discrete-event simulator (SCALE + Blake3) to explore consensus behavior without FRAME macros.
Sassafras / future consensus: Can Sassafras make Polkadot faster and safer?, Part 2 synthesis of SSLE, Ring VRF ticket mechanics, and validator operational trade-offs.
Consensus lab series: Slot collisions & forks → P2P gossip & visibility lag → Partition re-org depth → GRANDPA-lite & finality bounds → Mempool flood control & state roots.
Further open PRs in polkadot-sdk and polkadot-fellows/runtimes, including descriptive module invalidity (#11724), storage visibility deprecation (#11695), XCM weight accounting (#11302), benchmark weight fixes (#11732), and Asset Hub safe-mode / tx-pause (runtimes#1164).
I intend to continue contributing to core polkadot-sdk and Fellowship runtimes, including #11561 and other in-flight work. I will increase participation in Fellowship channels and RFC discussion as my rank allows.
N/A — Candidate; not yet eligible for Fellowship referenda voting activity thresholds.
| Ranks | Activity thresholds | Agreement thresholds | Member's voting activities | Comments |
|---|---|---|---|---|
| I | 90% | N/A | N/A | Candidate |
| II | 80% | N/A | ||
| III | 70% | 100% | ||
| IV | 60% | 90% | ||
| V | 50% | 80% | ||
| VI | 40% | 70% |
Threshold