# Argument-0009: Retention at Rank II

|                 |                                                                                             |
| --------------- | ------------------------------------------------------------------------------------------- |
| **Report Date** | 2026/08/25 (YYYY/MM/DD)                                                                     |
| **Submitted by**| Francisco Aguirre                                                                           |

## Member details

- Matrix username: `@cisco:parity.io`
- Polkadot address: `129EYiTbv2J4LkYqRNssUfMuxNLYN8TW2LgfG1Gqyj8wCcs7`
- Current rank: `2`
- Date of initial induction: `2024/05/31`
- Date of last report: `2026/05/25`
- Area(s) of Expertise/Interest: `XCM, Bridges, Smart Contracts, JAM, Storage`

## Reporting period

- Start date: 2026/05/25
- End date: 2026/08/25

## Argument

This period I focused on Web3 Storage (Capacity): building an example application end-to-end to showcase and validate it, researching the provider node's database layer and hardening its CI.
At the same time, I continued improving Bulletin Chain and HOP, and did XCM hardening work across the SDK and the fellowship runtimes.

A big bulk of my time went to the example Photos dapp[\[1\]](https://github.com/paritytech/web3-storage/pull/152), an example application that showcases how a normal app uses Web3 Storage.
It's a simple app supporting uploads, albums with a computed root anchor, downloads, thumbnails and image editing.
This example app was my first real foray into the project and helped build my knowledge and intuition around it.

I then moved on to improve the storage in the provider node. I benchmarked database options and wrote up results to drive a decision[\[2\]](https://github.com/paritytech/web3-storage/pull/253).
I also audited all GitHub Actions workflows with zizmor and added a CI gate so it doesn't regress[\[3\]](https://github.com/paritytech/web3-storage/pull/158).

On Bulletin Chain, I continued hardening HOP: Submit signature v2 now binds the recipient list and the genesis hash to the signature[\[4\]](https://github.com/paritytech/polkadot-bulletin-chain/pull/575).

On the XCM side, I improved the XCM benchmarks in the SDK and regenerated weights across all runtimes, making sure weight accounting reflects reality[\[5\]](https://github.com/paritytech/polkadot-sdk/pull/12832).
I removed expensive aliasers from the unpaid execution barrier, both in the SDK[\[6\]](https://github.com/paritytech/polkadot-sdk/pull/12831) and in the fellowship runtimes[\[7\]](https://github.com/polkadot-fellows/runtimes/pull/1237), since there is no valid use-case for it.

Beyond authoring, I reviewed extensively across polkadot-sdk, polkadot-bulletin-chain, web3-storage and the fellowship runtimes.

As a member of JamBrains, I took part in the Milestone 1 interview for our JAM client, GrayMatter, which we passed[\[8\]](https://collectives.subsquare.io/fellowship/referenda/596). Started work on Milestone 2.

On the education side, I hosted a meetup in Montevideo to talk about the Polkadot Products Devnet[\[9\]](https://www.meetup.com/web3-meetup-init-uy/events/315909393/).
I plan to keep doing more to foster the local community.

## Voting record

|  Ranks | Activity thresholds | Agreement thresholds | Member's voting activities | Comments |
|---|---|---|---|---|
|I  |90%   |N/A   |   |  |
|II |80%   |N/A   |100%   |I have voted on 0 out of 0 referenda in which I was eligible to vote (i.e 100% voting activity).  |
|III|70%   |100%  |   |  |
|IV |60%   |90%   |   |  |
|V  |50%   |80%   |   |  |
|VI |40%   |70%   |   |  |