Date: Tuesday, 20 October 2026, 14:00 UTC
Host: Jesse Chejieh (@jessechejieh:matrix.org), Rank II
Agenda: help-center#22
Previous proceedings: 15 September 2026
Recording: Google Drive
Recap: x.com
Ankan Anurag walked us through Asset Hub Migration v2. The context is RFC 32: the relay chain was never supposed to have transactions, only to relay parachains. AHM v1 last year moved balances, staking and governance off it, and what remains is parachain-related: para registration, HRMP channel management and on-demand coretime. Clearing it is also a step towards the relay chain being replaced by the JAM parachain service. The end state is no tokens and no balances on the relay chain, no teleports into it, and no signed extrinsics supporting it. Unsigned extrinsics remain, so a code upgrade still works by sending the hash through the coretime chain and uploading the blob as today. AHM v2 moves everything to the coretime chain, not Asset Hub, because these are para-related flows and the coretime chain already handles coretime. Free balances go to Asset Hub; the holdings, which are registrar and HRMP deposits, go to the coretime chain plus a buffer so it can operate there. For HRMP, most of the logic stays in the relay chain and only the deposit part moves. Parachains will still call the relay chain, but with unpaid execution and rate limiting, roughly one UMP message per block, so their current XCM programs, which buy weight and execute, will have to be adjusted. On-demand coretime buying is the last piece. Moving it turned out to be a larger design change than anticipated, so the work was split: first a minimal move of ordering and payment to the coretime chain while the relay chain keeps the queue and scheduler, then RFC 175 replaces the backend. The path is written up in polkadot-sdk#13076: the relay-chain side of the RFC, from the PoC in polkadot-sdk#12936, is open for a Fellowship member to take and can start now. The migration itself should take under a few minutes, with a warm-up and cool-off; the one-hour window used in the earlier migration is probably more than this one needs. The whole working piece is about 14,000 lines, hard to review, and one change restarts the approval cycle, so it is being split into smaller PRs stacked on a state machine and primitives PR, with the stages following step by step (the stage machine, integrated PoC, lockdown, accounts and manager-multisig PRs are linked from the agenda). The accounts stage, runtimes#1324, is the last big one; the rest will be much smaller.
Alistair Singh of Snowfork demoed the offchain messaging MVP, work funded under a four-month delivery proposal. HRMP is a blocker for JAM because it puts the full message payload and the message queue state on the relay chain, which would quickly exhaust JAM’s limited storage and compute, roughly 48 KB per work item. Offchain messaging instead lets parachains send messages to each other directly over libp2p, manage their queue state inside their own runtimes and sync only fixed-size commitments on the relay chain. Demoed on zombienet with parachains 2000 and 2001 and no XCMP queues on either node: an XCM payload sent from 2000 was delivered on 2001 in the same block, with the origin tagged spec-msg, the marker the team uses for messages delivered this way (the spec-msg primitives are in polkadot-sdk#12676). Latency is usually one to three blocks, on par with HRMP today. The demo still runs against the relay chain rather than JAM. The remaining work over the rest of the engagement is peer discovery (MVP peers are hardcoded), monitoring, the port to JAM, and an adversarial test suite, with the goal that the code is ready for audit at the end of the four months. Alistair named the state of the JAM testnet as the main blocker: there is no good one yet, though the last week or two have brought progress.
Oliver Tale-Yazdi spoke on the JAM parachain service: the proof of concept runs fine on a local testnet, and its code is now being extracted, cleaned up and upstreamed into the SDK as production code, starting with the aura authorizer, which is waiting on reviews. Separately, Sebastian is preparing a document on how Asset Hub will manage the JKB token: how it moves between accounts and services, and how it can be leased or permanently allocated. Oliver raised two further topics that need Bastian and a wider group, so they were carried to the next call: the sponsorship requirement recently added to the Fellowship’s rules, and the forum discussion on whether the Polkadot Fellowship would maintain Kusama on JAM. On the first, the reworked retention and salary requirements in Evaluations#354 leave open questions about progression and sponsorship, and answers are needed by the end of the month because members have retentions coming due. Oliver added that members whose retention period ran entirely under the old rules are still judged by them, but the new rules need clarity, including what sponsorship means, since it works like a reputation system in which a nominee failing retention reflects back on their sponsor.
Clara van Staden reported that RFC 167, the Snowbridge circuit breaker presented at the September call, has passed and The Snowfork team expects to present an implementation proposal next year, and Alistair added that the work will be rolled into Snowbridge’s yearly maintenance proposal for operating the bridge as a work item.
Next call: Tuesday, 17 November 2026, the third Tuesday as always · agenda thread opens ~1 week out. Bastian’s JAM parachain service session and Embedded Polkadot are carried over to that call.