| Report Date | Date of submission (2026/09/24) |
| Submitted by | Branislav Kontur |
Levity (Bulletin), Capacity (Web3 Storage), Bridges, XCM, System Parachains, governance, benchmarking, testing, integration, IPFS, BitswapThis summary outlines my work during the reporting period (July–September 2026). The two main things are that Levity Polkadot went live on Polkadot, and that Capacity grew from a demo into a real implementation project that I help drive. I was on holiday for most of August.
Levity is now a working storage chain on Polkadot, not a prototype any more. Following the staged plan I prepared for onboarding it into the Fellows runtimes [1], we brought the Levity storage and HOP business into the runtime — pallets, runtime APIs and configuration [2] — thanks to the Levity team (Karol (@karolk91), Cisco (@franciscoaguirre), Rohit (@rosarp), Anthony (@antkve), Andrii (@dr333ws), Rafal (@RafalMirowski1), Naren (@mudigal)). It shipped in Fellows runtimes v2.4.0 [3] and was enacted on Polkadot by fellowship referendum 603 [4], with Karol helping on the governance side with the referenda, and covering the discussions and setup with the Levity collators. Levity is part of the Products Platform infrastructure, for example for hosting SPAs for the DotNS machinery.
My own focus was mostly on coordinating the work behind it — preparing the plan, testing, creating issues [5] and doing reviews — and on the work around the runtime change rather than the change itself: setting up the release and the rest of the preparation [6]. The chain is live and ready, now waiting for the products to use it.
Capacity is the staked-provider storage system designed by Robert Klotzner (@eskimor), where the chain is a credible threat instead of the hot path. I am one of the people pushing it forward [7].
As with Levity, most of my time goes into moving the work forward rather than only writing code: keeping the design document and the code in sync [8], taking the resulting decisions back into the document [9], reporting the bugs I find on the way [10], and doing my share of the implementation and the reviews [11]. Next to that I am doing research and investigation on what is needed to bring Capacity live and make it usable for the Products platform.
Together with Rohit (@rosarp) I am the maintainer of the Polkadot<>Kusama bridge stack. It is in maintenance mode, but we recently improved the internal testing with zombienet-sdk [12], and those tests cover both our Polkadot SDK testnet runtimes and the latest Fellowship runtimes for the BridgeHubs and AssetHubs [13] [14] [15].
Looking ahead, I created issues about what JAM means for the bridges and for the parachain service [16] [17]. We are also prototyping the use of a smoldot light client for the bridge relayers, where I identified the missing pieces around GRANDPA justifications [18] [19], and Rohit added a smoldot side-car for the zombienet tests [20].
I am a regular reviewer in the Levity [21], Polkadot SDK [22] and Fellows [23] repositories. I stayed the technical contact for Levity and Capacity across teams.
Provide your voting record in relation to required thresholds for your rank.
| 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 0 % voting activity). | There were no referenda I could vote on during the reporting period. |
| III | 70% | 100% | ||
| IV | 60% | 90% | ||
| V | 50% | 80% | ||
| VI | 40% | 70% |
Threshold