| Report Date | 2026-05-06 |
| Submitted by | Timothy Wu |
During this reporting period, I continued to serve as Technical Team Lead for the Parity <> ChainSafe Q3/Q4 2025 engagement, guiding the team through the final phase of work on Speculative Availability, Approval Checking Rewards, and WebRTC transport improvements. The engagement concluded in this period with Approval Checking Rewards (Phase 1) and Speculative Availability ready for final upstream review, and the WebRTC PR chain progressing through upstream merges across five interdependent repositories. I have continued to support the team in driving these contributions through upstream review on Polkadot-SDK and its dependent crates, and we plan to continue providing support for testing and monitoring on testnets.
My individual contributions during this period include:
Continued driving PR #10563 to a merge-ready state. Since the previous report, the PR has been progressed to a state where it is awaiting final review, with all earlier feedback addressed and zombienet test coverage extended to validate chunk fetching behaviour for parachains using elastic scaling. The implementation introduces a principled distinction between speculative (Scheduled) and standard (Occupied) chunk request origins via new CoreInfo types, adds AvailabilityStoreMessage::NoteBackableCandidates to allow the availability store to hold metadata for early-fetched chunks without violating its existing invariants about backed state, and exposes a new origin label on the polkadot_parachain_fetched_chunks_total Prometheus metric so operators can observe the speculative-versus-standard fetch ratio in production. The feature is gated behind a --speculative-availability CLI flag, with a path to enabling it on Kusama and then Polkadot once it is shipped in a node release.
Following the merge of the precursor spelling/terminology fix PR (burdges/Polkadot-RFCs #2), I authored and opened a new RFC PR against the same fork: burdges/Polkadot-RFCs #3. This PR describes the process for nodes to send signed extrinsics containing each validator's ApprovalTallyMessage view from its own perspective, and specifies how validator points are derived from those tallies for submission to Asset Hub and downstream rewards distribution. The PR is currently soliciting feedback on the proposed signed-extrinsic submission mechanism and the median-of-medians consensus over cross-validator tallies, which we plan to upstream into the polkadot-fellows/RFCs repository once the design is settled.
Provided code review and technical direction on my teammate @EclesioMeloJunior's two implementation PRs: polkadot-sdk #9687 (the off-chain Phase 1 statistics collector, now awaiting final upstream review) and ChainSafe/polkadot-sdk #9 (the on-chain Phase 2 approvals-rewards pallet, feature-complete on our fork pending the Phase 1 merge). Both PRs implement the design described in the RFC PR above.
Enabling WebRTC-Direct support in Polkadot end-to-end required fixes across five layered open-source Rust projects (sctp-proto, str0m, litep2p, smoldot, and polkadot-sdk), which had to land bottom-up. In this period I authored fixes at four of those five layers, including the top-level Polkadot-SDK integration PR. I also coordinated the cross-repository delivery and reviewed contributions from teammates at the litep2p layer.
finalized_block_height = 0 instead of the peer's best_block_number; justification-verification errors triggering unnecessary 40-second peer bans during initial sync; and outbound substream retry loops with zero delay that starved WebRTC connections.In addition to my own authorship, I reviewed and coordinated my teammate @haikoschol's litep2p contributions — notably litep2p #554, which makes WebRTC-specific multistream-select negotiation spec-compliant and is required for smoldot interoperability — and a follow-up litep2p PR (currently carried on our ChainSafe/litep2p #17 working branch) covering ICE negotiation, race conditions, failed-substream reporting, request-response FIN handling, and SCTP backpressure.
Beyond direct code contributions, in this period I:
My contributions this period demonstrate continued expertise in:
NoteBackableCandidates signalling path and elastic-scaling test coverage.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 | I have voted on 0 out of 0 referenda in which I was eligible to vote. | |
| II | 80% | N/A | ||
| III | 70% | 100% | ||
| IV | 60% | 90% | ||
| V | 50% | 80% | ||
| VI | 40% | 70% |
Question(s):
Concern(s):
Comment(s):
Threshold