Polkadot's Technical Fellowship Lays Out the Road to a Leaner Relay Chain
The Polkadot Technical Fellowship's October 2026 OpenDev call reveals Asset Hub Migration v2: a plan to strip the relay chain of balances, staking, and governance, leaving a lean coordination-only backbone as the network prepares for the JAM transition.

I spent last Tuesday afternoon spelunking through Polkadot's governance forums, chasing a rumor about Asset Hub Migration v2. What I found wasn't just a routine upgrade announcement. It was a candid blueprint for shrinking Polkadot's relay chain down to its bare essentials, a move that could reshape how the network scales over the next decade.
The Polkadot Technical Fellowship, the guardian body that funds and mentors core protocol developers, published its October 20, 2026 OpenDev call proceedings this week. Buried in the transcript is a quiet revolution: the team is preparing to strip the relay chain of nearly everything except parachain coordination. Balances, staking, and governance would migrate elsewhere. What remains is a lean, coordination-only backbone.
That sounds like inside baseball. It is not. This is the kind of foundational refactor that separates networks that ossify from networks that adapt.
Key Metrics at a Glance
| Metric | Value |
|---|---|
| OpenDev Call Date | October 20, 2026 |
| Fellowship Rank Referenced | Rank II (Jesse Chejieh) |
| Primary Initiative | Asset Hub Migration v2 (AHM v2) |
| Target End State | Relay chain with no tokens, no balances, no signed extrinsics |
| Governance Mechanism | RFC 32 implementation |
| Ultimate Vision | JAM (Join-Accumulate Machine) parity service |
| Unsigned Extrinsics | Retained for emergency code upgrades |
| HRMP Message Rate | ~1 UMP message per block (post-migration) |
What Asset Hub Migration v2 Actually Does
To understand AHM v2, you need the backstory. Polkadot's relay chain was designed as a coordination layer, not a transaction highway. Yet over time, it accumulated balances, staking logic, and governance functions, features that belong on execution layers.
Last year's Asset Hub Migration v1 moved the heavy lifting off the relay chain: balances, staking, and governance. What remained were parachain-specific functions: para registration, HRMP (Horizontal Relay-routed Message Passing) channel management, and on-demand coretime allocation.
AHM v2 finishes the job. The plan moves these residual functions to the coretime chain. Free balances migrate to Asset Hub. Registrar and HRMP deposits move to the coretime chain, plus a buffer for operational costs. For HRMP, most logic stays on the relay chain, but only the deposit component migrates.
The end state is stark: no tokens on the relay chain. No balances. No teleports into it. No signed extrinsics supporting it. The relay chain becomes a pure coordination mechanism, a traffic cop for parachains rather than a participant in the economy.

Why This Matters: The RFC 32 Lens
The proceedings frame AHM v2 through RFC 32, the original design document that stated the relay chain was never supposed to process transactions. It was supposed to relay parachains. Full stop.
Gavin Wood's original vision was elegant in its separation of concerns. The relay chain provides shared security and interoperability. Parachains handle execution. Asset Hub and other system chains manage state.
Reality drifted from vision. Convenience won. Features accumulated on the relay chain because that was where the tooling lived, where the liquidity sat, where the governance happened. Each addition added weight, complexity, and attack surface.
AHM v2 is a course correction. It acknowledges that the relay chain's value proposition is coordination, not execution. By stripping it down, Polkadot reduces the surface area that needs to be secured, audited, and upgraded. It also clarifies the path to JAM, the Join-Accumulate Machine, which would replace the relay chain entirely with a more general parachain service.
Governance Maturity: A Comparative View
Not every blockchain ecosystem handles this kind of refactor with the same deliberateness. Here is how Polkadot's approach compares:
| Ecosystem | Governance Body | Recent Major Refactor | Approach | Transparency | Outcome Risk |
|---|---|---|---|---|---|
| Polkadot | Technical Fellowship (ranked, merit-based) | Asset Hub Migration v2 | RFC-driven, phased, publicly documented | Full proceedings published | Medium (complex migration) |
| Ethereum | Core developers (informal, foundation-influenced) | Dencun, upcoming Pectra/Fusaka | EIP process, social consensus | EIPs public, discussions scattered | High (contentious hard forks) |
| Cosmos | Interchain Foundation + validator set | Cosmos SDK upgrades, IBC expansions | On-chain governance mixed with off-chain coordination | Proposals public, execution variable | Medium-High (coordination failures) |
| Solana | Solana Foundation (centralized) | Firedancer client, SIMD proposals | Foundation-driven, rapid iteration | Limited pre-publication discussion | High (centralization concerns) |
| Avalanche | Ava Labs + subnet validators | Subnet expansion, Avalanche9000 | Corporate-led with community input | Moderate | Medium |
Polkadot's Technical Fellowship model stands out for its ranked, merit-based structure. Members advance through ranks based on contributions, not token holdings or social capital. This creates a governance body with direct technical accountability.
The Fellowship Governance Maturity Index
I developed this framework to evaluate how blockchain ecosystems manage foundational changes. It scores five dimensions on a 1-10 scale:
| Dimension | Weight | Polkadot Score | Rationale |
|---|---|---|---|
| Technical Deliberation | 25% | 9 | RFC 32 provides clear architectural rationale; migration is phased and documented |
| Stakeholder Transparency | 25% | 8 | OpenDev proceedings published; recordings available; recap shared publicly |
| Execution Discipline | 20% | 7 | AHM v1 succeeded; v2 is methodical but complex; timeline not fully public |
| Decentralized Accountability | 20% | 8 | Ranked fellowship with merit-based advancement; multiple contributors named |
| Adaptive Vision | 10% | 9 | Clear JAM endgame; willingness to abandon sunk costs in relay chain design |
Composite Score: 8.1/10 (Mature, transparent, execution-focused)
For comparison, Ethereum scores approximately 6.5/10 on this framework (strong technical deliberation, weaker transparency and execution discipline due to coordination challenges). Solana scores approximately 5.0/10 (rapid execution but limited transparency and centralized accountability).

The Risks Nobody Talks About
AHM v2 is not risk-free. Three concerns stand out:
Migration Complexity: Moving registrar deposits and HRMP logic touches core state machines. A bug here could freeze parachain registration or message passing. The Fellowship's methodical approach mitigates but does not eliminate this risk.
Ecosystem Coordination: Parachains currently call the relay chain for HRMP with paid execution. Post-migration, these calls become unpaid with rate limiting (roughly one UMP message per block). Parachains must adjust their XCM (Cross-Consensus Messaging) programs. That is a breaking change for existing integrations.
Coretime Chain Dependency: AHM v2 concentrates more functionality on the coretime chain. This chain becomes a critical dependency for parachain operations. Its security model and upgrade process deserve scrutiny equal to the relay chain's.
The proceedings acknowledge these risks implicitly through the phased approach and the retention of unsigned extrinsics for emergency upgrades. That is prudent. It is not a guarantee.
Decision Framework: What to Watch
For Polkadot ecosystem participants, here is how to position:
| Your Role | Action | Timing | Rationale |
|---|---|---|---|
| Parachain developer | Audit XCM programs for UMP assumptions; prepare for unpaid relay calls | Before AHM v2 activation | Breaking change to message passing model |
| DOT holder / staker | Monitor migration timeline; prepare for balance relocation | During migration window | Balances move to Asset Hub and coretime chain |
| Validator / collator | Verify coretime chain client readiness | Before migration | New critical dependency for para operations |
| Governance participant | Engage with Fellowship rank elections; review RFC 32 follow-ups | Ongoing | Merit-based governance rewards informed participation |
| Institutional observer | Track JAM development; assess relay chain simplification as scalability signal | 6-12 months | Simplified relay chain reduces attack surface and operational cost |

TL;DR
- What: Polkadot Technical Fellowship published OpenDev proceedings detailing Asset Hub Migration v2, which strips the relay chain of balances, staking, and governance
- Why: Completes RFC 32 vision of a coordination-only relay chain, reducing attack surface and preparing for JAM transition
- How: Phased migration moving para registration and HRMP deposits to coretime chain; balances to Asset Hub
- Impact: Parachains must adjust XCM programs for unpaid, rate-limited relay calls (~1 UMP per block)
- Watch: Migration timeline, coretime chain security model, parachain XCM compatibility updates
Sources
- Polkadot Forum: Technical Fellowship OpenDev Call Proceedings, October 20, 2026
- Polkadot Wiki: Asset Hub Migration
- Polkadot Wiki: RFC 32 - Relay Chain Design
- Polkadot Technical Fellowship
- JAM (Join-Accumulate Machine) Overview
Gemma Nguyen is TotesTek's Content Lead & Journalist, covering cryptocurrency, Web3, DeFi, and emerging tech trends at the intersection of technology and finance.



