Summary

1. About this Report
2. Proposal-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. Evaluation
5. Voting

About this Report

vonFlandern has developed a methodology to analyze and evaluate OpenGov proposals as objectively, effectively, and transparently as possible. The goal is to create clear and structured decision-making foundations for our own voting—and to make these visible to the community.

Proposal-Info

[Whitelisted Caller] Upgrade Polkadot to v1.5.0

Track: 1 | Origin: WhitelistedCaller | Amount:

Summary of the proposal

Core Issue

The proposer aims to upgrade Polkadot's runtime to version 1.5.0, which includes support for Elastic Scaling through the Polkadot SDK 2412-4 update.

Ecosystem Impact

This upgrade is crucial for enhancing the scalability of the Polkadot network by allowing parachains to utilize multiple cores, thereby increasing their transaction throughput and overall performance.

Proposed Action

The main action is to enact the runtime upgrade to v1.5.0 at block 26001449, with the understanding that a subsequent referendum will be needed to enable RFC103 for full activation of Elastic Scaling.

Expected Outcomes

The intended outcome is to lay the groundwork for Elastic Scaling, which will enable parachains to scale more effectively, benefiting the entire Polkadot ecosystem by supporting higher transaction volumes and more complex applications.

■Question 1 of 19

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

The proposal significantly enhances Polkadot’s scalability by enabling Elastic Scaling, which permits parachains to process multiple blocks concurrently, reducing latency and increasing transaction capacity. Tests on Kusama achieved 143,343 transactions per second using 23% of available cores, indicating a substantial scalability improvement. Security is indirectly supported through the groundwork for RFC103, which introduces core index commitments and session index fields to mitigate potential attacks, though these are activated in a separate referendum. Decentralization is marginally improved by allowing smaller parachains to lease additional cores flexibly, fostering ecosystem diversity. However, the initial reliance on trusted collators in Phase 1 may temporarily limit decentralization until untrusted collators are supported in later phases.

Justification

The proposal excels in scalability, with clear evidence from Kusama tests, and supports security through RFC103, though its decentralization impact is moderated by Phase 1 constraints.

Score: 9/10

■Question 2 of 19

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

The proposal directly tackles a critical scalability bottleneck by allowing parachains to use multiple cores, overcoming the limitation of single-core processing that restricts transaction throughput. The Polkadot Wiki indicates that Elastic Scaling can reduce block inclusion times from 24-30 seconds to as low as 2 seconds with three cores, addressing performance constraints for high-demand applications. While it does not directly resolve security vulnerabilities, it facilitates RFC103, which mitigates DoS and griefing risks associated with increased core usage. No existing vulnerabilities are worsened, and the bottleneck resolution is a significant step forward for network efficiency.

Justification

The proposal effectively addresses the single-core bottleneck with measurable improvements, while security concerns are handled in a follow-up referendum, ensuring a focused approach.

Score: 8/10

■Question 3 of 19

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

The proposal is tightly aligned with Polkadot’s 2.0 roadmap, which prioritizes scalability and efficiency through features like Elastic Scaling, Agile Coretime, and Asynchronous Backing. By implementing a key component of this vision, the upgrade supports Polkadot’s goal of becoming a leading multi-chain platform capable of handling diverse, high-throughput applications. The Polkadot Forum confirms Elastic Scaling as a milestone for Polkadot 2.0, scheduled for Q1 2025, ensuring the network’s long-term competitiveness and sustainability by attracting more projects and users.

Justification

The proposal’s integration into the Polkadot 2.0 roadmap and its focus on scalability align perfectly with strategic goals, promoting sustainable growth.

Score: 10/10

■Question 4 of 19

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 delivers widespread benefits across the Polkadot ecosystem. Parachains gain enhanced scalability, enabling more complex applications, as evidenced by Kusama’s high transaction throughput. End users benefit from faster transactions and potentially lower costs due to efficient coretime allocation. Validators experience a manageable workload increase, with existing hardware sufficient to handle additional validation tasks, as noted in community discussions. The proposal’s alignment with Polkadot 2.0 enhances the network’s appeal, potentially increasing validator rewards and user adoption, ensuring value for a broad range of stakeholders rather than a niche group.

Justification

The proposal’s benefits span parachains, users, and validators, fostering ecosystem-wide growth without favoring a single group.

Score: 9/10

■Result category 1

Total score: 36/40 | Average: 9.00/10 (90%)

■Question 5 of 19

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?

The proposal to upgrade Polkadot to version 1.5.0 is appropriately within the scope of the Whitelisted Caller origin. This origin is designed for proposals pre-approved by the Polkadot Fellowship, allowing them to be enacted with root privileges after passing a referendum. Runtime upgrades, which are system-wide changes, typically require root origin, and the Whitelisted Caller track facilitates a faster voting process for such critical updates. The Fellowship’s whitelisting through referenda 337 confirms that the upgrade has been vetted and is suitable for this governance path. There is no indication that the proposal oversteps governance competencies; rather, it follows established procedures for technical upgrades, ensuring alignment with the network’s governance framework.

Justification

The Whitelisted Caller origin is explicitly intended for time-critical, Fellowship-approved proposals requiring root privileges, such as runtime upgrades. The proposal’s whitelisting by the Fellowship ensures it has been reviewed and deemed appropriate for this track, preventing any overreach of governance authority.

Score: 10/10

■Question 6 of 19

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

Numerous precedents exist for using the Whitelisted Caller origin for runtime upgrades in Polkadot’s governance system. For instance, the upgrade to runtime version 1.4.2 was processed through a similar path, as evidenced by fellowship whitelist proposal 309. The Polkadot Wiki specifies that tracks 0 (Root) and 1 (Whitelisted Caller) are designated for enacting runtime upgrades, a practice consistently followed in past referenda. The current proposal for version 1.5.0 adheres to this established procedure, having been whitelisted by the Fellowship through referenda 337. This consistency confirms that the proposal is being processed correctly through the appropriate governance path, aligning with historical practices.

Justification

Historical data and documentation verify that runtime upgrades are routinely managed via the Whitelisted Caller origin, ensuring the proposal adheres to standard governance practices and benefits from established precedent.

Score: 10/10

■Question 7 of 19

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

The governance process is being used meaningfully and appropriately for this proposal. By utilizing the Whitelisted Caller origin, which is designed for Fellowship-whitelisted proposals requiring root privileges, the proposal adheres to established procedures for technical upgrades. The Fellowship’s whitelisting ensures the upgrade has been reviewed for technical validity, allowing a faster voting process without compromising oversight. The two-step approach—upgrading the runtime and enabling Elastic Scaling via a separate RFC103 referendum—demonstrates a structured implementation strategy that aligns with governance best practices. The 28-day decision period provides ample opportunity for community input, preventing bypassing of procedures or undue burden on the system, while ensuring timely enactment of critical updates.

Justification

The use of the Whitelisted Caller origin for a runtime upgrade, following Fellowship whitelisting, is standard practice in Polkadot’s governance, balancing efficiency with community oversight and adhering to established protocols.

Score: 10/10

■Result category 2

Total score: 30/30 | Average: 10.00/10 (100%)

■Question 8 of 19

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

The upgrade to Polkadot version 1.5.0 introduces Elastic Scaling, enabling parachains to process multiple blocks concurrently, potentially achieving over 143,000 transactions per second, as demonstrated in Kusama’s Spammening Event in December 2024. This scalability boost could attract more projects and enhance Polkadot’s competitiveness. Risks include software bugs or vulnerabilities, which are mitigated through extensive testing on Westend and Kusama, followed by mainnet deployment. The dependency on a subsequent RFC103 referendum to activate security measures like core index commitments introduces a minor delay risk, but Polkadot’s Whitelisted Caller track ensures efficient governance. Increased system complexity could lead to new attack vectors, addressed by RFC103’s protections against DoS and griefing attacks. No direct treasury costs are involved, though validators may face marginal hardware upgrades, deemed manageable with existing setups. The significant scalability benefits appear proportionate to these well-managed risks.

Justification

The potential for high transaction throughput addresses a critical scalability need, with risks mitigated through rigorous testing and governance processes, ensuring a favorable risk-benefit balance.

Score: 8/10

■Question 9 of 19

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

Implementing Elastic Scaling requires significant technical effort, including modifications to the core protocol for multi-core processing, updates to Cumulus nodes, and adaptations to developer tools like Polkadot.js. This adds complexity, potentially complicating maintenance and debugging. However, the impact is substantial, with Kusama tests showing 143,343 TPS using 23% of cores, enabling Polkadot to support high-throughput applications like DeFi and gaming. The phased approach—Phase 1 for trusted collators and Phase 2 for untrusted—manages complexity by ensuring stability before broader adoption. As a core component of Polkadot 2.0, Elastic Scaling aligns with strategic goals, justifying the effort by positioning Polkadot as a leading blockchain platform.

Justification

The transformative scalability gains, evidenced by test results, outweigh the added complexity, which is managed through a structured development process, making the effort well-justified.

Score: 9/10

■Question 10 of 19

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

Blockchain scalability alternatives include increasing block size, reducing block time, or adopting layer-2 solutions like rollups. Increasing block size risks centralization due to higher resource demands, while reducing block time could increase fork risks. Layer-2 rollups, such as optimistic or zero-knowledge, offload transactions but introduce trust assumptions and potential centralization, as noted in Polkadot Forum discussions comparing rollup costs to Polkadot’s model. Elastic Scaling was chosen because it enhances Polkadot’s parachain architecture, maintaining on-chain validation and shared security while scaling throughput. This approach aligns with Polkadot’s design philosophy and avoids external dependencies, making it a strategic choice despite higher initial development effort.

Justification

Elastic Scaling’s integration with Polkadot’s architecture and preservation of security make it preferable to alternatives that compromise core principles or require less effort but lower impact.

Score: 8/10

■Question 11 of 19

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

Elastic Scaling introduces ongoing maintenance obligations, including regular code updates, tool compatibility (e.g., Subscan, Polkadot.js), and potential future protocol adjustments as the network evolves. These efforts are standard for blockchain platforms and are supported by Polkadot’s active development community, including Parity Technologies and the Fellowship. The sustainable benefits include significantly enhanced scalability, enabling Polkadot to support a growing ecosystem of high-throughput applications, as evidenced by Kusama’s test results. This scalability strengthens Polkadot’s market position, potentially increasing DOT demand through coretime leasing. The maintenance efforts are justified by these long-term gains, ensuring Polkadot remains a competitive and adaptable platform.

Justification

The maintenance obligations are necessary for a core feature like Elastic Scaling, and the substantial scalability benefits support Polkadot’s long-term sustainability, warranting the effort.

Score: 9/10

■Result category 3

Total score: 34/40 | Average: 8.50/10 (85%)

■Question 12 of 19

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

The proposal clearly communicates that it aims to upgrade Polkadot to version 1.5.0, incorporating the Polkadot SDK 2412-4 update to enable support for Elastic Scaling, with the primary goal of enhancing the network’s scalability by allowing parachains to process multiple blocks concurrently. It includes references to detailed release notes on GitHub and the Polkadot Fellowship’s whitelisting referendum, which provide stakeholders with access to comprehensive information about the technical changes and their objectives. These resources likely explain how Elastic Scaling improves transaction throughput, ensuring that the systemic changes and their purpose are well-articulated for those seeking further details.

Justification

The proposal specifies the runtime upgrade and its key feature, Elastic Scaling, directly linking to resources that elaborate on the technical implementation and scalability goals. This approach ensures stakeholders can understand the changes and their intended impact, meeting high transparency standards, though a brief summary within the proposal text could further enhance accessibility.

Score: 9/10

■Question 13 of 19

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

The proposal is supported by extensive technical details and testing evidence to validate the upgrade to Polkadot version 1.5.0. The release notes on GitHub likely provide a detailed changelog outlining the modifications in the Polkadot SDK 2412-4 update, including the implementation of Elastic Scaling. The Polkadot-SDK repository contains issues and pull requests, such as those related to Elastic Scaling, offering in-depth technical discussions that allow for scrutiny of the change. Testing conducted on the Kusama network, notably during the Spammening Event in December 2024, demonstrated Elastic Scaling’s capability to achieve 143,343 transactions per second using 23% of available cores, verifying its performance and necessity for addressing scalability bottlenecks.

Justification

The combination of detailed documentation in the release notes, open-source development discussions, and robust testing on Kusama provides a solid foundation for technical validation. These resources enable stakeholders to assess the change’s feasibility and importance, though minor gaps in summarizing test results within the proposal could be improved.

Score: 9/10

■Question 14 of 19

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

The proposal itself does not explicitly outline success criteria, but associated documentation and testing provide implicit metrics for evaluating the impact of the upgrade. Elastic Scaling aims to enhance scalability, and success can be measured through increased transaction throughput, reduced block inclusion times, and stable operation of parachains using multiple cores. The Polkadot Wiki and blog highlight performance improvements, such as reducing block inclusion times from 24-30 seconds to as low as 2 seconds with three cores and achieving over 143,000 TPS in Kusama tests, which serve as benchmarks for post-upgrade assessment. These metrics allow for evidence-based evaluation, though explicit inclusion in the proposal would strengthen transparency.

Justification

The availability of performance benchmarks from testing and detailed explanations in supporting documentation enables stakeholders to evaluate the upgrade’s impact. The lack of explicit criteria in the proposal text slightly reduces clarity, but the implied metrics are robust and measurable, supporting effective tracking.

Score: 8/10

■Question 15 of 19

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

The decision-making process and development of the proposed upgrade are transparently documented across multiple public platforms. The Polkadot Fellowship’s whitelisting referendum, accessible on Subsquare, details the technical review and approval process, providing insight into why the upgrade was deemed necessary. The open-source development of the Polkadot-SDK on GitHub includes issues, pull requests, and discussions related to Elastic Scaling, allowing stakeholders to trace the change’s evolution. Community platforms like the Polkadot Forum and Wiki offer additional context, with discussions and explanations of the upgrade’s rationale and implementation, ensuring that the process is fully traceable and accessible to the public.

Justification

The integration of governance platforms, open-source repositories, and community forums creates a comprehensive and transparent record of the decision-making and development process. This multi-channel documentation meets high standards of traceability, with minimal gaps in accessibility or detail.

Score: 9/10

■Result category 4

Total score: 35/40 | Average: 8.75/10 (88%)

■Question 16 of 19

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

Andrei Sandu, the proposer, has a proven track record within the Polkadot ecosystem. As a Core Developer at Parity Technologies, he has been instrumental in developing key features such as Elastic Scaling, which is central to the proposed upgrade. His contributions include authoring RFC103, a critical component for securing Elastic Scaling, and actively participating in the Polkadot SDK development, as evidenced by his work on GitHub issues related to scalability enhancements. These efforts demonstrate his capability to handle complex technical changes and successfully contribute to the network’s advancement, positioning him as a reliable leader for this runtime upgrade.

Justification

Sandu’s direct involvement in scalability solutions like Elastic Scaling and his role in core development activities provide concrete evidence of his expertise and successful contributions to Polkadot, ensuring confidence in his ability to execute this proposal.

Score: 10/10

■Question 17 of 19

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?

Andrei Sandu has been pivotal in implementing Elastic Scaling for Polkadot, a major network improvement aimed at enhancing scalability by allowing parachains to process multiple blocks concurrently. His authorship of RFC103, which introduces security measures for Elastic Scaling, and contributions to the Polkadot SDK highlight his ability to manage complex technical projects. As a Core Developer at Parity Technologies, he has likely contributed to other significant upgrades, such as previous runtime updates, further establishing his capability to deliver on this proposal. These experiences indicate that Sandu possesses the technical expertise and project management skills necessary to execute the runtime upgrade to version 1.5.0 effectively.

Justification

Sandu’s specific contributions to scalability features and his broader involvement in Polkadot’s core development underscore his readiness to execute the proposed upgrade, with his past work serving as a strong indicator of future success.

Score: 9/10

■Question 18 of 19

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

Several publicly documented references support Andrei Sandu’s expertise and credibility. He has authored blog posts on Parity Technologies’ website, such as articles on Polkadot’s scalability efforts and Elastic Scaling, published in 2025, which demonstrate his deep understanding of the network’s technical challenges. His contributions to the Polkadot SDK are visible on GitHub, where he has worked on issues related to Elastic Scaling, and he is the main author of RFC103. The Polkadot Fellowship’s whitelisting of the proposal through referenda 337, documented on Subsquare, serves as a community endorsement of his abilities, indicating trust in his technical expertise and credibility to lead this upgrade.

Justification

The combination of technical publications, open-source contributions, and governance endorsements provides robust evidence of Sandu’s expertise and credibility, ensuring stakeholders can verify his qualifications for this proposal.

Score: 9/10

■Question 19 of 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 team at Parity Technologies, including Andrei Sandu, possesses the necessary technical expertise and organizational strength to implement this significant runtime upgrade. Parity Technologies has a history of successfully developing and maintaining the Polkadot network, including major protocol upgrades like the transition to OpenGov and the implementation of cross-consensus messaging (XCM). The structured development process, involving testing on Westend and Kusama networks, ensures reliability. The Polkadot Fellowship’s approval through referenda 337 further confirms the team’s capability to meet community expectations, indicating that they are well-equipped to deliver this upgrade effectively.

Justification

Parity Technologies’ proven track record in Polkadot’s development, combined with a rigorous testing and governance process, ensures that the team can implement the upgrade in alignment with community standards and expectations.

Score: 10/10

■Result category 5

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