Summary

1. About this Report
2. Referendum-Info
3. ANALYSIS
1. ■Impact on the Ecosystem
2. ■Governance Compliance
3. ■Cost-Benefit Ratio
4. ■Transparency and Traceability
5. ■Track Record and Credibility
4. Sources
5. Evaluation
6. Voting

About this Report

vonFlandern has developed a methodology to analyze OpenGov proposals as objectively and transparently as possible, and to evaluate them based on the central question:

Does the proposal contribute to Polkadot’s long-term success?

The expert personas shown here are completely fictional and AI-generated. The portraits, names, backgrounds, and credentials are created using artificial intelligence. These personas do not represent real people or actual institutional affiliations. This tool serves as a framework for structured Polkadot governance proposal analysis. For research and the creation of SWOT and stakeholder analyses, we use: Perplexity Enterprise | Mode: Research | Web, Academic, Social, Finance, Wiley. For the creation of the final analysis, we use: Claude Pro | Opus 4.1 | Mode: Advanced Reasoning | Research | Web Search

Referendum-Info

Title: [Whitelisted Caller] Upgrade all system chains to v2.0 and schedule Asset Hub Migration

Track: 1 | Origin: WhitelistedCaller | Amount:

Status: Executed

Summary of the proposal

Here's a summary of the system upgrade:

* Upgrading all system chains to version 2.0.0
* Preparing for Asset Hub Migration (AHM) which starts later
* Adding 4 more trusted collators to improve security
* Changing a special account on Hydration to keep control after migration
* Fixing a bug that prevented some accounts from adding new locks
* The upgrade happens on November 3rd
* The Asset Hub Migration begins on November 4th

ANALYSIS

■Question 1 of 19

1. Does the proposal demonstrably contribute to the long-term security, scalability, or decentralization of the network?

This proposal represents a critical architectural milestone in Polkadot's evolution toward the RFC-32 Minimal Relay vision, which maximizes the network's primary value proposition of secure blockspace by freeing validator resources to offer additional cores. By moving governance, staking, and balances from the Relay Chain (where all validators must execute state transitions) to Asset Hub as a system parachain (where only a backing group processes transactions), the complement of validator resources can be reallocated to provide more coretime to the ecosystem, directly enhancing long-term scalability and relevance. The successful Kusama Asset Hub Migration completed on October 7, 2025 in just 3 hours and 13 minutes demonstrates technical feasibility, while the addition of 4 invulnerables selected in collaboration with W3F researchers specifically addresses censorship resistance concerns now that critical functionality resides on Asset Hub.

Score: 8/10

■Question 2 of 19

2. Does the proposal specifically address existing vulnerabilities or bottlenecks in the Polkadot ecosystem?

The migration delivers sustained ecosystem value through fundamentally lower user costs that persist beyond the migration event, including reducing the existential deposit from 1 DOT to 0.01 DOT (100x reduction), significantly lower transaction fees and deposits, and the ability to pay fees in any supported asset rather than only DOT. These economic improvements create a more accessible environment for user retention and new user acquisition while the architectural shift toward minimal relay enables future innovations such as dynamic core allocation and elastic scaling that cannot be achieved with bloated relay chain logic. According to Parity's roadmap documentation, consolidating core functions into Asset Hub rather than disparate system chains provides a single point of entry that supports the vast majority of user stories, reducing integration complexity for developers and wallets while establishing a foundation for Polkadot 2.0's vision of blockchain-as-a-service infrastructure.

Score: 8/10

■Question 3 of 19

3. Does the proposal align with Polkadot’s strategic direction and roadmap to promote the network’s sustainable development?

This proposal directly addresses the structural inefficiency identified in RFC-32 where state transitions on the Relay Chain consume all validator resources, creating opportunity costs that limit the network's ability to offer additional coretime to parachains and thereby constraining ecosystem growth. The migration resolves this bottleneck by moving user-facing functionality to system parachains where only backing groups (subsets of validators) process transactions, freeing the complement of validators to secure additional cores and maximize Polkadot's core offering of secure blockspace. The proposal also fixes a technical bug preventing accounts with multiple locks from adding new locks, addressing a concrete usability issue that affects governance participants and stakers.

Score: 9/10

■Question 4 of 19

4. Does the proposal bring broad value to key actors and areas of the ecosystem (e.g., validators, parachains, end users) rather than just a small interest group?

The proposal enhances interoperability infrastructure by establishing Asset Hub as the primary balance and governance hub with direct access to trustless Ethereum bridges and expanded asset support including stablecoins USDT and USDC, positioning it as the interoperability nexus for cross-chain value transfer. For parachain development, the architectural optimization reduces barriers to entry by freeing resources for additional cores while the improved user economics on Asset Hub (lower fees, lower existential deposits) create better conditions for parachain applications to attract and retain users who no longer face prohibitive relay chain costs. According to Messari analysis of Polkadot 2.0, the shift toward flexible resource allocation through minimal relay architecture directly addresses historical high entry barriers for smaller projects by enabling more efficient coretime distribution, while research indicates that parachains historically faced challenges with parachain development costs that made Polkadot not offer a compelling entry point, issues this architectural evolution helps resolve.

Score: 8/10

■Result category 1

Total score: 33/40 | Average: 8.25/10 (83%)

■Question 5 of 19

5. Is the proposal clearly within the scope of responsibility of the chosen origin (e.g., Root for system-wide changes), or does it overstep governance competencies?

Referendum 1777 falls squarely within the scope of the WhitelistedCaller track, which is explicitly designed for neutral, technical proposals like runtime upgrades or changing the system's parachain validation configuration as documented in Polkadot's governance framework. The proposal constitutes a Fellowship-whitelisted system-wide runtime upgrade with comprehensive testing documentation, precisely the type of time-critical technical operation for which this track was architected, allowing expedited approval while maintaining democratic oversight through the full referendum lifecycle. The WhitelistedCaller track and Root track are confirmed as the only two origins authorized to enact runtime upgrades in Polkadot's governance system, establishing clear jurisdictional authority for this proposal type.

Score: 10/10

■Question 6 of 19

6. Are there precedents or previous similar proposals that demonstrate this proposal is being processed correctly through this governance path?

Extensive precedent exists for comparable runtime upgrade referenda using the WhitelistedCaller track with consistent approval outcomes, including Referendum 1756 (system chains upgrade to v1.7.1, whitelisted by Fellowship referendum 402, passed with near-unanimous approval in September 2025), Referendum 1736 (urgent v1.6.2 upgrade addressing Kusama stall bug, whitelisted by Fellowship referendum 394, approved), and Referendum 1645 (v1.6.1 upgrade for elastic scaling, whitelisted by Fellowship referendum 368, approved). These precedents demonstrate a well-established governance pattern where Fellowship-vetted technical upgrades proceed through the WhitelistedCaller track with strong community support, validating both the procedural approach and the likelihood of successful passage for technically sound proposals like 1777.

Score: 9/10

■Question 7 of 19

7. Is the governance process being used meaningfully with this proposal, without bypassing or unnecessarily burdening established procedures?

The governance system is being used meaningfully and appropriately without undue burden, following the standard two-step validation process where Fellowship technical review precedes community referendum voting, ensuring both expert technical assessment and democratic legitimacy. The WhitelistedCaller track provides an optimal balance between efficiency and oversight for time-critical technical upgrades, with its shortened timeline (compared to Root's 28-day decision period) justified by prior Fellowship vetting, while still requiring full community participation and stake-weighted approval. This represents proper institutional design rather than governance circumvention, as the Fellowship explicitly lacks hard power to change network parameters independently and can only reduce referendum timelines for proposals deemed safe and time-critical through transparent on-chain processes.

Score: 10/10

■Result category 2

Total score: 29/30 | Average: 9.67/10 (97%)

■Question 8 of 19

8. Are the potential risks or negative side effects of the proposed change proportionate to the expected benefits for the network?

The operational migration costs of approximately 6-10 hours network downtime are highly proportionate to the demonstrated benefits from Kusama's successful October 7, 2025 migration, which achieved 5x transaction fee reduction (0.00053 to 0.00009 KSM), 10x lower existential deposits, and 100x reduced storage requirements. The migration delivers immediate network-wide benefits including freed relay chain cores that can be allocated as coretime to parachains, maximizing Polkadot's primary offering of secure blockspace while fixing a critical account locks bug and adding four collators for censorship resistance. With no direct treasury expenditure required and Kusama proving the migration completes in 3 hours 13 minutes with 348,210 accounts and 17.13M KSM successfully migrated, the operational cost-benefit ratio is exceptionally favorable.

Score: 9/10

■Question 9 of 19

9. Is the required technical effort or additional complexity introduced by the proposal justified by the achievable impact?

As a technical runtime upgrade with zero direct treasury spending, this proposal's budget framework is incomparable to typical treasury funding requests that involve DOT expenditure. The migration represents execution of RFC-0032 (Minimal Relay Chain), an approved architectural evolution that had already undergone Fellowship review and Kusama testing, making it a strategic infrastructure investment rather than a discretionary spend. Comparing operational costs to similar system upgrades, the 6-10 hour downtime window aligns with other major protocol migrations while delivering permanent structural improvements to network economics and resource allocation.

Score: 9/10

■Question 10 of 19

10. Have alternative solutions with lower resource requirements been considered to achieve the same goal, and why was this change chosen?

The network gains substantial added value through freed relay chain computational resources that can be reallocated as coretime (measured blockspace) to parachains, directly enhancing Polkadot's core value proposition as DOT is burned when purchasing coretime. Users receive 10x lower barriers to entry via reduced existential deposits (1 DOT to 0.01 DOT) and 5-10x cheaper transaction fees on Asset Hub, improving accessibility and user experience. The treasury itself benefits from maintained control over DCA operations via the Hydration proxy switch while the entire ecosystem gains from the minimal relay chain architecture that maximizes scalability, aligns with Polkadot 2.0's coretime model, and enables efficient resource allocation across 50+ available cores.

Score: 10/10

■Question 11 of 19

11. Does the proposal create long-term obligations or maintenance efforts, and are these sufficiently justified by the sustainable benefits?

No cheaper alternatives exist because maintaining functionality on the relay chain would perpetually consume validator resources that must process every state transition, limiting available cores for parachain allocation and contradicting Polkadot's fundamental architectural direction toward minimal relay chain design. The only alternative identified in Fellowship discussions (RFC-0032) was determining which subsystems to migrate first, with balances and governance prioritized due to their high transaction volumes and clear benefits from specialized chain optimization. JAM (Join-Accumulate Machine), while a future evolution, complements rather than replaces this migration, and delaying would forfeit demonstrated cost reductions while maintaining inefficient resource allocation where the relay chain bottleneck prevents optimal coretime utilization.

Score: 9/10

■Result category 3

Total score: 37/40 | Average: 9.25/10 (93%)

■Question 12 of 19

12. Is it clearly communicated what specific systemic changes are to be made and what goal is being pursued?

The referendum provides exceptional communication of implementation purposes and technical details through multiple comprehensive documentation sources. The proposal explicitly references a testing and reproduction document at HackMD detailing exact call construction, Fellowship release notes v2.0.0 with detailed changelogs, an extensive FAQ document addressing balances, staking, and XCM specifics, and RFC-32 documenting the strategic roadmap toward a minimal relay chain architecture. Technical milestones are clearly defined including the scheduled execution at block 28,490,502 (circa November 4, 2025, 8 AM UTC), phased balance migration across three stages through 2026, addition of four invulnerables for censorship resistance, proxy switching from Relay Chain to Asset Hub sovereign accounts on Hydration, and bug fixes for account locking issues.

Score: 9/10

■Question 13 of 19

13. Is there sufficient information, technical details, or testing available to technically validate the proposed change and verify its necessity?

Technical specifications and timelines are transparently documented with exceptional precision across multiple authoritative sources. The Fellowship release v2.0.0 provides complete technical specifications including runtime sizes, Blake2-256 hashes, IPFS identifiers for all system chains (Polkadot, Asset Hub, Bridge Hub, Collectives, People Chain, Coretime), core version identifiers, and metadata version V14 for reproducible verification. Implementation timelines specify block-level precision (28,490,502), estimated 8-10 hour migration duration, phased approach with Phase 1 (November 2025), Phase 2 (EOY 2025 or early 2026 for 10 DOT ED increase), and Phase 3 (final balances pallet removal). The referendum includes detailed XCM call specifications for invulnerable set updates and Hydration proxy changes, with testing methodologies documented through Chopsticks ecosystem tests and Zombie-bite validation frameworks.

Score: 10/10

■Question 14 of 19

14. Are there clear success criteria or metrics to evaluate the impact of the change later?

Success criteria are explicitly defined through multiple evaluation mechanisms. The Asset Hub Migration Monitor dashboard at migration.paritytech.io provides real-time tracking of migration progress and XCM message status, enabling quantitative assessment of completion. Technical success criteria include successful state migration of staking, governance, and balances pallets from Relay Chain to Asset Hub, maintenance of 51% total issuance in staking functionality post-migration, zero user intervention required for end users, and successful Kusama precedent execution on October 7, 2024 providing comparative benchmarks. Additional metrics encompass bags list recalculation completion, election pallet state recreation, validator election communication integrity between Asset Hub and Relay Chain, and nomination pool fund migration enabling governance participation, with comprehensive testing documented through dedicated Google Docs for functionality and state migration validation.

Score: 9/10

■Question 15 of 19

15. Are the decision-making reasons and the change process transparently documented (e.g., through public discussions, minutes, or reports)?

Documentation and reporting mechanisms are comprehensively planned with multiple layers of transparency infrastructure. Pre-implementation documentation includes the testing document on HackMD, AHM Primer with migration overview, multiple FAQ documents for balances, staking, and XCM, RFC-32 architectural documentation, Fellowship release notes, high-level planning documents, protocol migration overview, and project board tracking at GitHub. Real-time and post-implementation reporting includes the Asset Hub Migration Monitor providing live migration status, public GitHub project board tracking progress, Forum updates with monthly reporting cadence, Fellowship referendum records for whitelisting process, Subsquare referendum page with community voting records, and integration guides for infrastructure providers via Substrate API Sidecar documentation. The Kusama AHM execution on October 7 established precedent with documented outcomes available for evaluation, and the referendum explicitly references critical user journeys documentation for external testing by developers and dApp maintainers.

Score: 10/10

■Result category 4

Total score: 38/40 | Average: 9.50/10 (95%)

■Question 16 of 19

16. Have the proposers or their team already made successful contributions or similarly complex changes in the Polkadot ecosystem?

The Polkadot Fellowship established in 2022 maintains multiple active GitHub repositories including polkadot-fellows/runtimes with comprehensive commit history and polkadot-fellows/RFCs managing protocol standards through a formal RFC process. Parity Technologies, celebrating its 10th anniversary in 2025, created and maintains the Polkadot SDK (969+ GitHub stars) after merging Cumulus, Substrate, and Polkadot repositories, and employs recognized experts including Bastian Köcher (Grand Architect, Rank 6), Shawn Tabrizi and Bryan Chen (both Rank 4). The Fellowship uses a structured evaluation system documented in their Evaluations repository where members submit evidence of contributions across runtime development, cryptographic implementations, consensus algorithms, and cross-chain protocols verified by peers.

Score: 10/10

■Question 17 of 19

17. What comparable projects or network improvements have the proposers implemented in the past, and what does this say about their ability to execute this proposal?

The most recent successful implementation was the Kusama Asset Hub Migration completed October 7, 2025, which migrated 348,210 accounts, 841,219 storage entries, and 17.1 million KSM in just 3 hours 13 minutes with zero failures. The Fellowship has successfully deployed runtime upgrades 1.9.1, 1.9.0, 1.7.1, 1.6.2, 1.6.1, 1.5.1, and 1.5.0 during 2025, each following the whitelisted caller governance process and including comprehensive testing documented in their releases repository. Parity Technologies delivered the three core technical pillars now live on Polkadot: Asynchronous Backing (8-10x throughput increase), Agile Coretime (flexible blockspace acquisition), and Elastic Scaling (completed October 2025 with SDK 2509), all tested first on Kusama before Polkadot deployment.

Score: 10/10

■Question 18 of 19

18. Are there publicly documented references, community feedback, or other evidence supporting the proposers’ expertise and credibility in this area?

The polkadot-fellows/runtimes repository contains detailed release notes, changelogs following Keep a Changelog format, and reproducible build instructions using srtool with full runtime metadata and IPFS hashes for verification. Previous whitelisted runtime upgrades including referenda 1736 (v1.6.2), 1581 (v1.5.1), 1546 (v1.5.0), 1528 (Bridge Hub v1.4.3), and 1486 (Asset Hub/Collectives v1.4.2) demonstrate consistent community approval through OpenGov voting. Community feedback is positive with collaborative development evident in GitHub pull requests, Matrix channels for Fellowship communication, and transparent processes including RFC approvals, peer reviews, and the first Polkadot Deployment Portal beta achieving zero failed deployments with exceptionally positive feedback.

Score: 9/10

■Question 19 of 19

19. Does the team have the necessary technical expertise and organizational strength to effectively implement this far-reaching change in line with community expectations?

The successful Kusama Asset Hub Migration serves as direct precedent proving the team's capability to deliver the identical Polkadot migration scheduled in Referendum 1777, with W3F researchers collaborating on collator selection criteria. The Fellowship's track record of 15+ successful runtime upgrades during 2025 alone, combined with Parity's decade of infrastructure development powering projects with millions of active users like Mythical Games (6.5M monthly active users), demonstrates consistent delivery capacity. The multi-layered verification process includes Fellowship whitelisting (level 3+ members voting), comprehensive integration testing, try-runtime checks, migration simulations, and full community referendum voting ensuring technical competence is validated before execution.

Score: 10/10

■Result category 5

Total score: 39/40 | Average: 9.75/10 (98%)