# Argument-0010: Retention at Rank II

|                 |                      |
| --------------- | ---------------------|
| **Report Date** | 2026/07/05           |
| **Submitted by**| s0me0ne-unkn0wn      |


## Member details

- Current rank: II
- Polkadot address: 13WGadgNgqSjiGQvfhimw9pX26mvGdYQ6XgrjPANSEDRoGMt
- Date of initial induction: 2024/04/22
- Date of last report: 2026/04/15
- Link to last report: https://github.com/polkadot-fellows/Evaluations/pull/278
- Area(s) of Expertise/Interest: WebAssembly, PolkaVM, PVF execution, host functions, statement store, proof of personhood

## Reporting period

- Start date: 2026/04/16
- End date: 2026/07/05

## Argument

During the reporting period, I stayed a core part of the team, carrying forward my established lines of work around PVF execution and host functions, and taking on a new major area — the statement store that underpins the Proof of Personhood effort.

**RFC-145 (runtime-side memory allocator and host functions).** I kept driving the reference implementation forward. The main PR ([#8641](https://github.com/paritytech/polkadot-sdk/pull/8641)) is under active review, and I peeled off self-contained improvements to make it landable in pieces — most notably public-keys caching ([#12099](https://github.com/paritytech/polkadot-sdk/pull/12099), merged), with a refactor of the storage cursor allocation ([#12200](https://github.com/paritytech/polkadot-sdk/pull/12200)) and passing the storage root hash unencoded ([#12117](https://github.com/paritytech/polkadot-sdk/pull/12117)) in flight. This is the long-awaited change that makes PVF execution more deterministic and faster, and it is now close to the finish line.

**BLS12-381 host functions (RFC-156).** I continued stabilizing the BLS signatures and their host functions ([#10327](https://github.com/paritytech/polkadot-sdk/pull/10327)), which are needed to equip BEEFY with BLS and are essential for the accountable light-client protocol. Along the way I tracked down and fixed two nasty defects on the `author_rotateKeys` / BEEFY paired-session-key path in the filesystem-backed keystore ([#12053](https://github.com/paritytech/polkadot-sdk/pull/12053)): a deterministic panic when generating `ecdsa_bls381` keys without a seed, and a keystore filename overflow for BLS381 / ECDSA_BLS381 keys that exceeded the 255-byte limit.

**Statement store — Proof of Personhood infrastructure.** I took over the index-scaling work for the statement store, which is the backbone of the Proof of Personhood effort. Following the roadmap in [#10910](https://github.com/paritytech/polkadot-sdk/issues/10910), I landed stage 1 ([#11480](https://github.com/paritytech/polkadot-sdk/pull/11480), merged), splitting the single index into independent read/write structures to cut lock contention, and I am now pushing stage 2a ([#12304](https://github.com/paritytech/polkadot-sdk/pull/12304)), which moves the read and "evicted" indexes to disk behind a cache and removes the RAM bound on how many statements a node can hold.

**Correctness and toolchain.** I root-caused and fixed a subtle state-trie bug where the `OverlayedChanges::storage_root` cache bled across `StateVersion` ([#11833](https://github.com/paritytech/polkadot-sdk/issues/11833) → [#11918](https://github.com/paritytech/polkadot-sdk/pull/11918), merged), and adapted the SDK to a `rust-lld` 1.96.0 regression that broke Wasm imports and could have blocked the toolchain upgrade ([#12440](https://github.com/paritytech/polkadot-sdk/pull/12440), merged).

**PolkaVM and virtualization.** I kept the [PolkaVM-for-parachain-runtimes MVP](https://github.com/paritytech/polkadot-sdk/pull/6704) rebased and alive pending RFC-145 adoption, and reviewed the `sp-virtualization` API rework ([#11767](https://github.com/paritytech/polkadot-sdk/pull/11767)) that builds on the virtualization work I landed in the previous period.

To summarize, my work during the reporting period was valuable, and therefore, I'm applying for retention at Rank II.

## Voting record

|  Ranks | Activity thresholds | Agreement thresholds | Member's voting activities | Comments |
|---|---|---|---|---|
|I  |90%   |N/A   |   |  |
|II |80%   |N/A   | I have voted on 0 out of 0 referenda in which I was eligible to vote (i.e NaN% voting activity). Out of 0 referenda in which members of higher ranks were in complete agreement, I have voted in line with the consensus 0 times (i.e NaN% voting agreement).  |  |
|III|70%   |100%  |   |  |
|IV |60%   |90%   |   |  |
|V  |50%   |80%   |   |  |
|VI |40%   |70%   |   |  |