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
-