Argument-0001: Promotion to Rank I Dan

Report Date	Date of submission (2025-11-19)
Submitted by	rockbmb

Member details

• Matrix username: @alexandre.balde@parity.io
• Polkadot address: 13jBAtYJar4xujPaEx41FxjSt9PqU7LqJRbySJiVdMtuWN42
• Current rank: Candidate
• Date of initial induction: 2025-10-28
• Date of last report: N/A
• Area(s) of Expertise/Interest: System Parachains, Polkadot Runtime

Reporting period

• Start date: 2024-09-01
• End date: 2024-11-15

Argument

I have been working on Polkadot continuously since September 2024.

During this time, as mentioned in my request for induction, I have focused mainly on testing protocol components of the Polkadot SDK, such as pallets, runtimes and networks, through the Polkadot Ecosystem Tests project.

For promotion to I Dan, the Manifesto states as a requirement:

Three clear examples of a modest but substantial contribution to protocol development

Below, I list these, and explain why they are sufficient for I Dan.

AHM Testing

About I Dan, the Manifesto also states that one expectation is:

being available and playing a crucial operational role for a network fix

I assisted with the testing process for the Asset Hub Migration in the Westened and Paseo testnets, and in the Kusama and Polkadot networks. During the run-up to the migration, the tests I wrote as part of PET were used to validate the functionality of relay chain/asset hub runtimes (and other runtimes, too)

Furthermore, upon the Kusama (Oct 7th)/Polkadot (Nov 4th) migrations, these PET tests were part of larger manual + automated (CI) testing processes to validate the migration's result, validation which was provided in real-time. For more, see the ahm-dryrun project, where PET was used in AHM dry-runs to validate relay/AH runtimes.

Some examples of findings (Polkadot SDK/Fellowship Runtimes):

1. Issue with burning funds in post-migration relay chains
2. Issue with missing call filters for some relay chain proxy types
3. Issue regarding pure proxies

General Runtime Testing

As part of the previous point, but also as its own endeavour, I used PET to test protocol components of the Kusama/Polkadot networks. An extensive (but not exhaustive) list of pallets/components tested can be found here.

From this came some contributions to the Polkadot SDK:

1. Added event emission to some pallets' extrinsics (identity, vesting, proxy, conviction voting, nomination pools)
2. Improved unit tests in some pallets (e.g. vesting, staking)
3. As a follow-up to the liquidity restriction issue (issue opened by Fellowship member RomarQ), I created a multi-network regression suite engineered to fail on (combinations of) this problem, giving visibility into which networks are still affected. It can be run against any runtime in which this error occurs (i.e. ones combining pallets using Currency traits and others using Fungible), and once the runtime consumes the upstream fix, the suite can be switched to ensure compliance.

EIP-150 compliance in pallet-revive gas-metering

Under the supervision of Fellowship Member Alex, I worked on implementing EIP-150 in pallet-revive's gas metering. Ultimately, the conclusion was that it was not possible at the time, as it removed the possibility of dry-running a contract call's execution - this is essential to estimating the computational cost in Polkadot-native units (ref time/proof size).

Voting record

N/A

Misc

• Question(s):

• Concern(s):

• Comment(s):

Acknowledgements

Thanks to seadanda, Oliver, muharem, Ankan, kianenigma, Alex for all the assistance with my work in the Polkadot SDK, and Bryan Chen for reviewing all of my PET/Chopsticks contributions.