Argument-0007: Retention at Rank 1

Report Date	2026-08-28
Submitted by	Timothy Wu

Member details

• Matrix username: @timwu20:matrix.org
• Polkadot address: 1RaxuqWvyd6sdAEiansxmtget47PVcsSR38d9V2uPzKu2vo
• Current rank: 1
• Date of initial induction: Seeding
• Date of last report: 2026-05-06
• Area(s) of Expertise/Interest: Consensus protocols, Networking, Availability, Parachain consensus, JAM

Reporting period

• Start date: 2026-05-06
• End date: 2026-08-28

Argument

The WebRTC-Direct transport work I led and authored during the Parity <> ChainSafe engagement reached the Polkadot node. In the previous report I described a chain of interdependent fixes across five repositories that had to land bottom-up before browser-to-node WebRTC connectivity was possible; in this period the top of that chain closed. Parity took our litep2p branches upstream, merged WebRTC-Direct support into Polkadot-SDK behind an experimental flag, and has now opened the PR to enable the transport by default on full nodes. My lower-layer fixes at the SCTP and WebRTC-library layers are in the released crates it is built on.

As Technical Lead for ChainSafe's JAM implementation (Go-JAM), I led it through M1 IMPORTER conformance, published on 2026-06-05 and now awaiting its milestone interview. This is where the majority of my direct engineering output has gone this period.

WebRTC-Direct: the transport reached the Polkadot node

Both ChainSafe WebRTC branches I was responsible for were taken upstream by Parity in this period, and the upstream PRs say so in their own descriptions. litep2p #573, merged on 2026-05-20, wraps the work from #554, a teammate's spec-compliant multistream-select negotiation that I reviewed and coordinated. litep2p #574 wraps the work already done in ChainSafe/litep2p #17, my own PR, and carries five of my commits. Rather than land that as one change, Parity re-landed our fork's work as their own follow-up series (#652, #653, #657, #658), fixing the substream open-failure and teardown defects our fork had diagnosed.

Underneath that, litep2p v0.14.1 (2026-06-10) is the first release to pin str0m 0.18.1 and with it sctp-proto 0.9, bringing my fixes at both of those layers into the transport (str0m #883, sctp-proto #30 and #37): a panic in data-channel establishment, and two stream-ID reuse defects that break data-channel reuse under packet loss. These only surface under real data-channel churn, and were found by driving a Polkadot node against a browser light client. Polkadot-SDK enabled litep2p's webrtc feature on 2026-06-23, and an open PR (#12870) would accept WebRTC connections by default on full nodes.

Technical leadership: Go-JAM, and M1 IMPORTER conformance

Go-JAM passed M1 IMPORTER conformance, with the full suite published on 2026-06-05 and the attestation recorded on-chain on Asset Hub. We are awaiting the milestone interview.

Our passing run (image ghcr.io/chainsafe/go-jam:v0.7.2.10) cleared every lane with zero restarts:

Lane	Configuration	Result
Minifuzz preflight	—	pass
L2a	1,000,000 steps, 335,307 blocks, tiny spec, mutations, safrole off	pass, rc=0
L2b	100,000 steps, full spec, mutations, safrole off	pass, rc=0
L3a	100,000 steps, tiny spec, safrole on, validators-management workload	pass, rc=0
L3b	100,000 steps, safrole on, empty workload	pass, rc=0

The blocker on previous submissions was not protocol correctness but resource behavior under million-step sessions. The harness runs each target in a roughly 16 GiB cgroup, and ours was OOM-killed about 2,000 steps in, surfacing only as a silent connection reset. Per-block allocation churn was around 30 MB, dominated by accumulation-context deep copies and a ~1.1 MB SRS deserialization performed on every block. I addressed this by caching the ring context once per run instead of rebuilding it per block, dropping rayon from ring-verifier-key construction, memoizing the state root to skip redundant Merklization per block, and tuning the conformance container's garbage collection and memory limit. Together with a fix for Rust-allocated FFI objects leaking across the cgo boundary, those changes went into v0.7.2.10, the first image to survive a full 1,000,000-step L2a run.

Most of my time this period went into planning, implementing, and reviewing the engineering behind that result and the work required for M2 conformance, spanning:

• Correctness under mutation — rejecting headers that name a block author outside the validator set, recording a service's output commitment even when its accumulation produced nothing, keeping empty and absent values distinct when decoding, and deep-copying ancestor block state rather than sharing it between blocks.
• PVM safety hardening — stopping a guest program from killing the node by requesting unbounded allocations through host calls, in both the interpreter and the recompiler, and keeping the machine's rollback point correct when a host call runs out of gas partway through.
• State and storage — the trie layer end to end: the Gray Paper's node encoding and key representation, an in-memory trie, a persistent node store with lazy loading and transactional commits, the proofs needed to serve state requests to peers, and a read cache for nodes and values.
• Networking — the network-bridge interface contract and a router implementing it over the transport, connection-lifecycle event streams, per-frame CE request/response handling, the full JAMNP-S CE/UP stream-kind registry, validator grid topology neighbor sets, and validator connectivity driven by a connection-policy domain.
• Conformance infrastructure — landing the M1 submission traces as CI fixtures, enabling the full trace suite in CI on arm64, and gating coverage per package.

Voting record

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.	There were no referenda available for my rank to vote on during the reporting period.
II	80%	N/A
III	70%	100%
IV	60%	90%
V	50%	80%
VI	40%	70%

Misc

• Question(s):

• Concern(s):

• Comment(s):