| Report Date | 2026/07/01 |
| Submitted by | Michał Kucharczyk |
@michal:parity.ioMy work is on the Substrate node. I own two areas: the fork-aware transaction pool and the genesis/chain-spec subsystem. I also work across the rest of the node and review a lot of code.
This is a request for a fast-track promotion to Rank III. I joined the Fellowship in June 2024, but I have worked on Polkadot core development since 2022 and attended the first Polkadot Blockchain Academy (PBA) that year. My on-chain tenure is therefore shorter than my actual involvement, which is why I am asking to skip Rank II.
I am the primary author of the fork-aware transaction pool, both its design and its implementation. It replaced the previous pool, which could not keep a correct transaction state across competing forks — a long-standing problem. I designed the new approach (design), implemented it (#4639), drove it to feature-completeness (roadmap), and it is now the network default (#8838). The transaction pool is within the Fellowship's scope: the Manifesto lists "the internals of all functional Polkadot node implementations".
Building on this, I also authored transactions/v2, a proposal for a new transaction-propagation protocol. It separates announcing a transaction from sending its full data, to reduce bandwidth. This is a design proposal and groundwork for a future RFC (#8128).
My second area is the genesis and chain-spec subsystem. This was part of the native-runtime-free effort started by bkchr (#62): genesis used to be built by the native runtime that was compiled into each node. I owned the genesis part of this work. I built the foundation (#1256), designed how to decouple the node from runtime types (#1984), and implemented it (#2714). The idea is to separate what runtime authors use (named genesis presets) from how the node builds genesis underneath, so the node builds genesis from the runtime's wasm instead of native code. This decoupling was the prerequisite for polkadot-omni-node, the generic, runtime-agnostic parachain node the ecosystem now uses. This work is within scope under the Manifesto's "runtime and host APIs".
The transaction pool is built to stay healthy under load, including adversarial load. When the pool is full, it keeps higher-priority transactions and drops lower-priority ones, so it does not get stuck. It also correctly rejects invalid transactions reported by the block builder.
I work across the whole node, not only my two main areas (authored PRs). I also reason about node-wide constraints. For example, the parachain PoV (proof-size) budget: I fixed a bug that spanned the runtime, the state machine, and the trie layers, where a block could go over the budget. The interface change is written up as RFC-158.
I support the transaction pool in production. I built its monitoring dashboards, and I am the person people come to for transaction and block-building problems. Often the problem is not the pool itself, but I can find where it really is, which needs knowledge of the whole stack.
I also review a lot of code across the stack (reviews).
I mentor other engineers: I onboarded a new team member into the transaction pool, and I mentored a teammate in node internals. I help external teams when they hit transaction-pool problems, and my code reviews are also a way to share knowledge.
I have written several semi-technical articles about Polkadot and Substrate — one forum post and five HackMD write-ups. They are listed under Publications below.
I have voted on 0 out of 0 referenda in which I was eligible to vote during this reporting period.
| Ranks | Activity | Agreement | Member's voting activities |
|---|---|---|---|
| I | 90% | N/A | I have voted on 0 out of 0 referenda in which I was eligible to vote during this reporting period. |
| III | 70% | 100% |
storage_proof_size host function