2025-10-21 Technical Fellowship OpenDev Call

Summary

  • Kusama Asset Hub migration completed successfully; Polkadot migration scheduled for November 4th

  • Staking system bug discovered on Kusama affecting validator reward calculations; fix in pipeline with treasury refund planned

  • Capped inflation implementation progressing toward March timeline; discussion on handling burns vs snapshots

  • Elastic scaling continues bug fixes; runtime upgrade tests now in CI

  • Block confidence reaching 99% on single core; working toward 100% target

  • Snowbridge incident: 6 transactions ($100k value) failed during runtime upgrade due to timing dependency between Asset Hub and Bridge Hub; referendum passed to replay transactions

  • Snowbridge V2 launched with XCM v5 support

  • Storage reclaim feature coming to Kusama

  • Multiple pallet migrations ongoing (currency → fungible traits)

  • Ambassador program technical work ready but funding/governance questions remain

  • BLS host functions progressing for Westend testing

Common Abbreviations used in these notes:

  • AH - Asset Hub

  • KAH - Kusama AH

  • PAH - Polkadot AH

  • KAHM - KAH migration

  • PAHM - PAH migration

Rank 5

Kian:

  • Staking system bug on Kusama

  • Asset Hub migration status

    • KAHM went pretty well overall :partying_face:

    • Staking testing for AH looking good

    • Expects no issues for Polkadot migration on November 4th

    • Will improve dashboard to clarify expected failures (garbage accounts, missing pre-images)

  • Upcoming work post-PAHM

    • Capped inflation: code complete, needs final review and audit

    • Unbonding queue: code complete, needs final review and audit

  • Tokenomics changes discussions:

    • Discussion on accounting for burned tokens

      • implementation snapshots total issuance once, doesn’t account for burns. May never reach target cap without reinspecting total issuance

      • Decision: will quote current approach for now; can refine implementation later while respecting cap

    • Timeline commitments

      • March deadline 100% achievable

      • Can deliver earlier for community/PR reasons

    • Kusama vs Polkadot inflation divergence

      • Recent Kusama vote on capped supply went negative

      • Kusama: 10% max with ~50% ideal stake (unchanged since genesis except removing unused auction parameters)

      • Polkadot: changed parameters ~1 year ago

      • Networks have diverged for some time

Rank 3

Oliver:

  • Asset Hub migration

    • Polkadot migration preparation

      • Runtimes must finish this week

      • Enactment on November 3rd (Monday)

      • Execute migration on November 4th (Tuesday) - similar to Kusama

    • Estimated duration: 4.5 hours for data movement

      • Kusama took ~90 minutes (vs 7.5 hour initial estimate)

      • Polkadot 3-5x longer than Kusama

      • Plus 1 hour warmup + 1 hour cooldown = ~6.5 hours total frozen period

      • Start time: 8:00 AM UTC (9 AM Berlin time)

    • Will run a few more times for better estimates

  • Migration monitor dashboard publicly available

  • Post-migration work

    • Capped inflation involvement

    • Exploring next topics, no concrete decisions yet

    • December typically slow period

  • Multi-asset bounties

    • Checking if merged; if not, will be in 2509 stable

    • Would still take ~1 month after SDK update to vote through

Andrei:

  • Elastic scaling - final tickets

    • Added runtime upgrade test (previously manual, now in CI). Test upgrades chain of async backing enabled chain to 3 cores. Should work the same for synced backing chain.

    • RFC 103: Removed feature gate after enabling on Polkadot relay. Simplifies enabling elastic scaling on chains. Available starting December stable

    • Found issue causing large parachain forks when running 12 cores. Fix was backported to 2509 stable

  • Reliability and block confidence

    • Canary parachain deployed on Kusama for data collection

    • Running single collator currently (will expand to multiple later)

    • Using latest tech: slot-based collator building on parent of best relay block

    • Avoids quirks bad for block confidence, especially with multiple cores

    • Current metrics and targets

      • Achieving 99% block confidence over 12 hours on single parachain

      • 99% of produced blocks are finalized; 1% dropped and rebuilt

      • Target: 100% block confidence (theoretically possible, practically challenging in decentralized system)

      • Created tickets for improvements next year

    • Near-term improvements

      • Need to increase lifespan of relay parents that parachains build their block on. Can happen this year, after Polkadot migration

      • Continued Alex Gorg’s PR: improved backing group connectivity for collators. Collators now connect one slot before collation time (previously they connected when they had collation)

        • Reduced latency from 5-6+ seconds to 16 milliseconds on Kusama

        • Significant block confidence improvement, especially for 3-core scenario

    • User experience impact

      • High block confidence means high transaction confidence once in-block

      • Useful for low-value transactions

      • Next year: much closer to 100% target

Adrian:

  • AHM support

    • Supporting Kusama and ongoing Polkadot efforts
  • Asset Hub asset management enhancements

    • allow: foreign assets to be teleportable

    • Two asset types on Asset Hub:

      1. Trust-backed assets (local): created on AH, admin can lock/unlock

      2. Foreign assets: registered by parachains/bridges, currently the owner can teleport assets to AH

    • Feedback has shown that teleporting foreign assets is problematic for developers

    • Teleport vs reserve-based transfers trade-offs

      • Teleport: multiple reserves, burn/mint on each side

      • Reserve-based: single reserve, local locking + remote derivative minting

      • Reserve-based easier for single management but complicates multi-hop transfers

  • New functionality

    • Allow foreign asset registration without teleportability requirement

    • Make non-teleportable the default (more natural)

    • Asset admin can configure teleportability

    • Migration for existing assets to maintain current teleportable behavior

    • Under review in SDK, then Fellowship, then runtime release

  • Use case: HOLLAR on Asset Hub

    • Hydration wants to register HOLLAR on Asset Hub

    • Don’t want to manage separate reserve on AH

    • Willing to accept routing costs for single reserve management

    • Goal: time release with Asset Hub smart contracts launch

  • Industry context

    • No established standard in Ethereum to follow

    • Polkadot/ecosystem pioneering multi-chain asset management

    • Most industry has single-chain mindset (Ethereum, Solana, etc.)

    • Entire class of problems don’t exist in single-chain environments

    • Uphill battle educating from multi-chain perspective

Sebastian:

  • Promoted to Rank 3 in August

  • Storage reclaim coming to KAH

    • storage estimation always has to overestimate. Sebastian wrote some measurements

    • new Mechanism: reclaim storage after transaction by comparing weight before/after

    • Worked on improving accuracy over time. Fellowship member Mikhail working on remaining edge case fixes

    • Edge cases: very niche scenarios, small overshoot amounts

    • PR open, expected to merge soon

  • NOMT node

    • First version of solo chain with NOMT running locally

    • NOMT: separate storage trie format using binary trie with efficient access patterns

    • External team working; Sebastian, Mikhail, and Basti providing guidance

  • Zombienet Genesis improvements

    • Longstanding pain point: tests must wait for first full session before onboarding chains

    • 10-minute wait (10 relay blocks) wastes CI time and developer sanity

  • Basti block reviews and other SDK work

Rank 2

Davide Galassi:

  • JAM conformance and fuzzing

    • Main work: improving JAM conformance across implementations

    • Pushing forward interoperability between team implementations

  • Team status

    • 40+ teams listed on Gray Paper website

    • ~20 teams actively being fuzzed

    • happy about progress: 2 months ago implementations were quite weak

    • Current: some doing well, but not production-ready yet

  • Fuzzing campaigns

    • Protocol 0.7.0: campaign completed

    • Protocol 0.7.1: starting very soon

    • Testing work is done informal by Davide and teammate

  • Web3 Foundation operational handoff

    • so far work is inofficial

    • WF taking over operational fuzzing (Milestone 1 prize related)

    • Will run fuzzer tool on their side

    • Davide’s team: triage disputes, design Milestone 2 fuzzer

  • Milestone 2 challenges

    • More ambiguous than Milestone 1

    • Milestone 1: purely on-chain logic (clear, unambiguous, Gray Paper defined)

    • Milestone 2: off-chain strategy

      • Block production (how/when)

      • Networking behavior

    • Need to define evaluation criteria

    • Will take more time

Q&A:

  • Oliver: fuzzing 0.7.1 or still 0.7.0?

    • Maintaining 0.7.0 branch (some teams still targeting it)

    • Want to start 0.7.1 ASAP (some teams already providing targets)

    • May not provide many new test vectors for 0.7.0

    • 0.7.1 vectors will be superset of 0.7.0

Clara:

  • Promoted to Rank 2

  • Debrief Snowbridge incident (first real issue since June 2024 launch)

    • Timeline: ~3 weeks ago with Asset Hub/Bridge Hub runtime upgrade to 1.7

    • Issue: transactions failings in Polkadot → Ethereum direction

    • Root cause: upgrade dependency between Asset Hub and Bridge Hub

      • Both upgrades permissionless (anyone can upload WASM after vote)

      • Assumed simultaneous upload - faulty assumption

      • AH upgraded first: sent unpaid messages

      • BH not yet upgraded: expected paid messages

      • Messages failed

  • Incident response

    • Team identified problem early

    • Uploaded Bridge Hub WASM

    • Notified partners: Hydration (heaviest Snowbridge user), Velocity

    • Partners immediately paused Snowbridge integrations

    • 6 transactions failed (~$100k value)

    • Service resumed after WASM upload

  • Recovery

    • Created referendum to replay failed transactions

    • Community voted in favor

    • Fellowship whitelisted

    • Transactions successfully replayed

  • Lessons learned

    • Need mindfulness of AH/BH integration dependencies

    • Good learning opportunity for team

    • Change strategy: staged upgrades (one parachain, release, then other parachain)

    • Can send paid tx if recipient expects unpaid, but not vice versa

    • Should dry-run transactions on both chains (not just AH)

    • Would have caught error before user submissions

  • Snowbridge V2 with XCM v5

    • XCM v5 upgrade on Bridge Hub and Asset Hub went live ~3 weeks ago

    • Snowbridge V2 upgraded last week via proposal

    • Tested transactions both directions

    • Everything working fine

  • Next steps

  • Polkadot Ambassador program

    • Attempting to help get on-chain

    • Work completed long ago, small administrative hurdles remain

    • Dom also helping

Technical Q&A on Snowbridge

  • Oliver: dependency between AH and BH runtimes?

    • Not hard dependency

    • XCM-level functionality change: paid → unpaid execution for Snowbridge messages

    • AH upgraded to send unpaid, BH still expected paid → failure

    • Didn’t dry-run on BH (assumed BH straightforward if AH passes)

    • Now introduced BH dry-run testing

  • Oliver: must test all three/four constellations

    • Both non-upgraded, one upgraded, other upgraded, both upgraded

    • Otherwise can’t guarantee simultaneous enactment

  • Solution: backwards compatibility essential

    • Or staged changes: one parachain change → release → other parachain change → release

    • Paid tx can be received as unpaid, but not vice versa

Ambassador Program Discussion:

  • Adrian:

    • Worried about work with no funding/use

    • Recommends sanity check: is ambassador program still funded/wanted?

  • Oliver:

    • could also be smart contracts
  • Clara:

    • Some developers working since beginning of year

    • Told they can go on-chain, get treasury, work autonomously

    • Not happening

  • Oliver:

    • it’s basically on-chain, but they are not happy with the details
  • Clara:

    • trying to help

    • Ambassadors see technical work as blocker

    • Not getting support from technical side

    • Lots of work done but need final commits on-chain

    • Controversial topic but wanted to raise it

Cisco:

  • AHM support (XCM side)

  • Migration coordination challenges

    • Forum posts on issues found

    • Problem: system parachains migrate successfully, but other parachains don’t update DOT reserve location

    • Apps can’t identify correct DOT reserve location (relay → Asset Hub)

    • Coordination with Polkadot.js

      • Nice SDK with fixes built in

      • If adopted, prevents broken cross-chain transfers during/after migration

  • Testing and troubleshooting

    • Lots of testing to ensure DOT cross-chain transfers work

    • Other assets should work fine

  • XCM and smart contracts

    • Waiting for Paseo Asset Hub to have contracts for testing

    • Plan: test contract doing cross-chain transfers

    • Goal: easy interface for sending DOT, USDT, any AH asset anywhere

    • Challenge: Paseo AH currently disconnected (not useful for XCM testing)

    • Need Paseo AH connections to chains like Hydration testnet

Pablo:

  • Pallet migrations: currency → fungible trait

    • Main work: migrating pallets from currency trait to newer fungible trait
  • Recent work

    • Identity pallet migration under review

    • After review changes this week: start Treasury pallet (”ambitious”)

    • Continue migrations over coming months

  • Future work

    • RFC write-up for new proposal (late December)

    • Multi-currency deposit management using consideration

    • Aware of need for PAH migration before full focus on 2509 migration

Rank 1

Daniel:

  • XCM Westend Asset Hub setup

    • Large PR for Westend AH

    • Not good time for review (reviewers busy with asset migration)

    • Switched focus to refactoring

  • XCM refactoring for version 6

    • Main goal: implement RFC on XCM asset metadata (depends on XCM v6)

    • Second attempt at issue

    • First attempt was to continue Brian’s work

    • New approach: completely new PR (easier)

    • Retain Brian’s general idea: separate implementations for each XCM instruction (not big match statement)

    • Different approach planned

  • Strategy

    • Objective: minimize changes

    • Two separate PRs: (1) refactor, (2) XCM v6

    • Won’t merge into one big thing - keep it small

Ludovic:

  • Same work as Pablo: pallet migrations currency → fungible traits

  • Specific pallets

    • Indices pallet (since last month)

    • Lottery pallet (current work)

    • Work in progress

  • Next: move to next pallets after current ones complete

Dom:

  • RFC 150: Voting while delegating

    • Main work: simultaneous delegation and voting

    • Allows voting without undelegating

    • RFC under review, one approval received

    • Waiting on Basti (requested changes completed)

    • Code nearly complete: benchmarking done, migration writing remains

    • Development smooth, no issues

  • Ambassador program (with Clara)

    • Understanding the frustrations and qualms. Unfortunate timing issue

    • Unclear best path forward with contracts coming

    • Ambassadors want runtime-level credibility vs contract-level

    • Two backports reviewed (two reviews necessary)

    • Can add to runtimes PR if moving forward

  • Hard cap supply pressure

    • Working on it with Kian and Oliver

    • Looking good for getting necessary changes in

  • Macro for storage boilerplate

    • Issue from ~1.5 years ago

    • New macro to eliminate derive boilerplate for runtime storage

    • May conflict with recent effort to remove macros

    • Not critical but could be good for:

      • Developers annoyed by boilerplate

      • Umbrella issue for new contributors, similar to block number provider switching

      • Good for getting familiar with PR process

Q&A:

  • When will hard cap land on-chain?

    • probably before Nov 4 or around then

    • Oliver: Polkadot 2.0 thing first, then afterwards

Seyed:

  • BLS host functions

    • Working on Basti’s PR

    • If merged: BLS on Westend for testing bridges using BLS

    • Can test while auditing encryption/crypto code

  • Grant reviews (ZK related)

    • ZK verifier grant went through

    • Parachain submitting ZK proof instead of normal proof

  • Test bridge grant

    • Working with another grant for test bridge using BLS and APK proof

    • Bridge between Polkadot and Kusama

  • RFC for host functions

    • Current host functions work but are BLS-specific

    • If ECDSA goes away, functions become useless

    • Will work on better solution

Q&A with Clara (Snowbridge incident):

  • Seyed: glitch on Polkadot side of bridge? Transactions submitted?

  • Clara: No tx submitted from Polkadot → Ethereum

    • AH execution passed, XCM to BH failed

    • Ethereum never saw anything

  • Seyed: confused - payment went through on Polkadot?

  • Clara: Went through on Asset Hub, not Bridge Hub

    • Not completely through Polkadot
  • Seyed: why referendum to replay? Anyone could replay on Ethereum?

  • Clara: Funds already burnt on AH, can’t submit same tx

    • If AH rolled back, could replay

    • but instead it was an inconsistent state: AH burnt funds, message incomplete to BH queue

  • Seyed: could custom relay submit based on AH burn?

  • Clara: Theoretically yes

    • Problem: messages submitted in BH digests

    • Never in digest → relayer couldn’t see/submit confidently

    • If in digest, normal relay works

  • Seyed: too late for another digest?

  • Clara: Not just anyone can submit to BH (Asset Hub privileged)

    • Had to come from Asset Hub
  • Seyed: you have privilege?

  • Clara: No. Had to open referendum from relay chain

    • Bridge completely permissionless

    • Team can’t burn/mint or send messages

  • Seyed: digest submission privileged?

  • Clara: Yes, security reason (prevent team enrichment)

Rank 0

Nikos:

  • Current work

    • Reinitializing frame pallet migrations to fungible traits

    • Left behind long ago, now picking back up

  • Return to Fellowship work

    • Background: busy with PBA Bali (Cisco and Ludovic also involved)

    • Now that PBA finished, good time to return

    • Heard more people needed on Polkadot SDK

7 Likes