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 - 
Issue: some validators not having self-stake counted for reward calculations 
- 
https://forum.polkadot.network/t/psa-disruption-to-kusama-validators-self-stake-and-rewards/15599 
- 
Discovered through Kusama validator reports after migration 
- 
Fix in pipeline; expected deployment later this week or early next week 
- 
Planning treasury tip referendum to refund affected validators 
- 
Demonstrates value of Kusama as incentivized canary network, because validators reported the issue 
 
- 
- 
Asset Hub migration status - 
KAHM went pretty well overall  
- 
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: - 
Trust-backed assets (local): created on AH, admin can lock/unlock 
- 
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 - 
Working on documentation 
- 
Partner integrations for V2 
 
- 
- 
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 
 
-