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

Assigning Coretime to Xcavate and Mythical

Track: 1 | Origin: WhitelistedCaller | Amount:

Summary of the proposal

Core Issue

The proposer aims to assign Coretime to Xcavate and Mythical, which missed their core renewal due to a buyer acquiring all available cores.

Ecosystem Impact

This is critical to ensure parachains can produce blocks, maintaining ecosystem stability and trust.

Proposed Action

The proposal sends two XCM messages to increase core count by four, assigning ~64 days of free Coretime to Xcavate and Mythical without funding requests.

Expected Outcomes

Xcavate and Mythical continue block production, while protocol improvements are pursued to prevent future Coretime market manipulations.

■Question 1 of 19

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

The proposal contributes to long-term scalability and decentralization by ensuring Xcavate and Mythical, key parachains with significant user bases, remain operational, thereby maintaining ecosystem diversity and transaction throughput. Xcavate’s tokenized real estate platform and Mythical’s gaming ecosystem, which processed 3.3 million transactions in a day, enhance network activity. However, it does not directly improve security, as it focuses on resource allocation rather than consensus or cryptographic enhancements. The proposal’s one-time nature limits its direct long-term impact, but it catalyzes discussions for Coretime protocol improvements, which could strengthen decentralization and scalability over time.

Justification

The continued operation of Xcavate and Mythical supports scalability by maintaining high transaction volumes and decentralization through diverse applications, aligning with Polkadot’s multi-chain vision. The absence of direct security enhancements and the short-term focus temper its contribution, but the push for protocol changes adds potential long-term value.

Score: 7/10

■Question 2 of 19

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

The proposal directly addresses a vulnerability in the Coretime allocation system, where a single entity purchased all available cores, preventing Xcavate and Mythical from renewing theirs. By assigning four new cores to these parachains for approximately 64 days, it mitigates the immediate bottleneck, ensuring block production continuity. The proposer’s engagement in discussions for protocol enhancements, such as adjusting core availability, targets the underlying flaw, reducing the risk of future monopolistic disruptions in the Coretime market.

Justification

The proposal tackles a clear bottleneck by restoring Coretime access and highlights a systemic issue, prompting governance-driven solutions. Its focus on a specific, evidenced vulnerability, coupled with proactive steps for improvement, demonstrates strong alignment with ecosystem needs.

Score: 9/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 aligns with Polkadot’s strategic direction, particularly the Agile Coretime framework, which emphasizes flexible resource allocation for sustainable network growth. By ensuring Xcavate and Mythical remain active, it supports ecosystem stability, a key aspect of Polkadot 2.0’s focus on scalability and interoperability. The proposer’s advocacy for Coretime protocol improvements aligns with the roadmap’s aim to refine resource management, fostering a resilient network that attracts developers and users while addressing immediate operational needs.

Justification

The proposal’s alignment with Agile Coretime and its role in maintaining ecosystem health fit Polkadot’s roadmap. Its contribution to sustainable development is evident through stability and protocol reform, though its one-time nature slightly limits its strategic depth.

Score: 8/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 broad value by ensuring Xcavate and Mythical continue operations, benefiting validators through sustained network activity, other parachains via ecosystem stability, and end users accessing real estate and gaming services. It also prompts Coretime protocol enhancements, potentially improving resource access for all parachains. While directly aiding two parachains, the precedent and proposed reforms support the wider ecosystem, though some may perceive it as prioritizing specific projects over others.

Justification

The proposal’s benefits extend to multiple stakeholders by maintaining network vitality and pushing for systemic improvements. Its focus on two parachains raises minor concerns about favoritism, but the broader implications for governance and resource allocation ensure significant ecosystem-wide value.

Score: 7/10

■Result category 1

Total score: 31/40 | Average: 7.75/10 (78%)

■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 aligns with the WhitelistedCaller origin’s scope, which permits the Polkadot Technical Fellowship to propose urgent, system-level changes requiring Root privileges, such as increasing the Coretime chain’s core count from 62 to 66 and assigning leases to Xcavate and Mythical. This addresses a critical operational disruption caused by a Coretime market failure, fitting the origin’s purpose for expedited, Fellowship-approved actions. The Fellowship’s oversight ensures the proposal remains within governance competencies, though direct Coretime allocation may raise concerns about overreach among some governance participants.

Justification

The WhitelistedCaller origin is designed for time-sensitive interventions with Fellowship approval, as per the Polkadot Wiki, and the proposal’s system-wide impact justifies its use. The Fellowship’s involvement mitigates overstepping risks, but the exceptional nature of direct allocation warrants scrutiny, slightly tempering the score.

Score: 8/10

■Question 6 of 19

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

No identical precedents exist for assigning Coretime to specific parachains via the WhitelistedCaller origin, but Polkadot’s governance has addressed Coretime market issues, such as RFC #1 on Agile Coretime and market design revisions proposed in 2023. These interventions show governance tackling resource allocation challenges, supporting the proposal’s use of this path. The Fellowship’s approval and community voting align with the WhitelistedCaller’s process, though the lack of direct precedents reflects the issue’s novelty.

Justification

Related governance actions, like those on Coretime market dynamics, provide a contextual basis for this path, as seen in GitHub and forum discussions. The absence of exact precedents limits full confidence, but the process adheres to the origin’s requirements, justifying a moderate score.

Score: 6/10

■Question 7 of 19

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

The proposal meaningfully utilizes the governance process by leveraging the WhitelistedCaller origin for urgent action while requiring community voting, ensuring transparency and accountability. It addresses a time-sensitive issue without bypassing essential checks, and its one-time nature, coupled with plans for protocol enhancements like auto-renew guides, avoids burdening governance with repetitive proposals. However, some may view the direct intervention as an exceptional use, potentially straining standard procedures.

Justification

The proposal respects the WhitelistedCaller origin’s purpose for expedited, vetted actions and adheres to voting requirements, as outlined in the Polkadot Wiki. Its focus on a single fix with long-term solutions minimizes burden, but the exceptional precedent slightly lowers the score.

Score: 7/10

■Result category 2

Total score: 21/30 | Average: 7.00/10 (70%)

■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 potential risks of setting a governance precedent and slightly diluting the Coretime market are proportionate to the benefits of ensuring Xcavate and Mythical, key parachains with significant user engagement, continue operations, thereby maintaining ecosystem stability. The proposal’s one-time intervention mitigates concerns about repeated bailouts, and its push for Coretime protocol improvements addresses systemic issues, enhancing network resilience. The benefits of preserving transaction throughput and prompting market reforms outweigh the risks, which are manageable given the temporary nature of the fix.

Justification

The preservation of critical parachains and the catalysis of protocol enhancements provide substantial network value, outweighing the risks of precedent-setting and minor market impact, which are mitigated by the proposal’s limited scope and planned reforms.

Score: 8/10

■Question 9 of 19

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

The technical effort, involving two XCM messages to increase the core count and assign leases with set_storage calls, is minimal and leverages existing governance mechanisms, justifying the significant impact of maintaining Xcavate and Mythical’s operations. This straightforward approach avoids introducing complexity, ensuring immediate operational continuity for parachains critical to ecosystem diversity and user activity, with no need for new infrastructure or extensive development.

Justification

The low technical effort, using established XCM and governance functionalities, is highly justified by the impact of sustaining key ecosystem contributors, making the proposal efficient and effective for investors and curators.

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?

Alternatives like negotiating with the Coretime buyer, who demanded $150,000 per core, or using on-demand Coretime were considered but rejected due to prohibitive costs and unsuitability for continuous block production needs. The chosen approach of increasing cores and assigning free Coretime was selected for its immediate effectiveness, ensuring Xcavate and Mythical’s continuity, though limited documentation on alternative evaluations may concern some stakeholders.

Justification

The urgency and infeasibility of alternatives justify the chosen method, which efficiently addresses the crisis, but the lack of detailed exploration of options like on-demand Coretime slightly tempers confidence in the decision process.

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?

The proposal creates no long-term obligations or maintenance efforts, as it is a one-time intervention assigning Coretime for ~64 days, with the core count increase being a manageable, permanent adjustment within Polkadot’s scalable design. The sustainable benefits of maintaining ecosystem stability and prompting Coretime market reforms, such as auto-renew features, justify this minimal footprint, aligning with economic interests in a resilient network.

Justification

The absence of ongoing costs or efforts, combined with significant benefits from ecosystem health and planned protocol improvements, makes the proposal highly efficient, with no burdens to offset its value.

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 outlines the systemic changes, specifying that two XCM messages will increase the Coretime chain’s core count from 62 to 66 and assign ~64 days of free Coretime to Xcavate (task 3413) and Mythical (task 3369) via set_storage calls. The goal is to ensure these parachains continue block production after missing their core renewal due to a third party’s acquisition of all cores, while addressing Coretime protocol flaws. This clarity allows the actions and goals to be understood, although additional context to integrate with Agile Coretime could improve understanding.

Justification

The proposal explicitly details the changes and purpose, meeting transparency needs for information platforms, but slightly lacks broader context on Coretime mechanics, justifying a strong but not perfect score.

Score: 8/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 provides a comprehensive overview of XCM messages, core count increases, and set_storage calls, but does not provide detailed technical specifications such as XCM payloads or storage keys. The need is substantiated by the Coretime buyer's claim of $150,000 per core versus an offer of 200 DOT (~$840), although no verifiable supporting documentation, such as communication records, is included. Community approval requires some validation, but no test data is provided, limiting technical review.

Justification

While the proposal justifies the need and outlines actions, the absence of granular technical details and verifiable evidence hampers validation, warranting a moderate score for transparency.

Score: 5/10

■Question 14 of 19

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

The proposal implies success through the continued block production of Xcavate and Mythical and the introduction of improvements to the Coretime protocol, but lacks explicit metrics such as block production rates or timelines for protocol changes. References to auto-renewal features and wiki guides hint at future evaluation points, but without defined criteria, it is difficult for reviewers to objectively assess impact.

Justification

Implied outcomes are reasonable but insufficient for rigorous evaluation, as the lack of specific metrics or timelines limits evidence-based tracking, justifying a partial fulfillment score.

Score: 6/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 proposal documents the decision-making reasons, citing the Coretime buyer’s actions and protocol flaws, and follows a transparent change process via a WhitelistedCaller referendum open to community voting. Public GitHub discussions on protocol improvements enhance transparency, but the Fellowship’s internal approval process lacks detailed documentation, and no records of negotiations with the buyer are shared, limiting full traceabilitys.

Justification

The referendum and GitHub discussions provide good transparency, but incomplete documentation of Fellowship decisions and negotiations slightly weakens the ability to fully trace the process, supporting a strong score.

Score: 8/10

■Result category 4

Total score: 27/40 | Average: 6.75/10 (68%)

■Question 16 of 19

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

The proposer, bkchr, a Senior Developer at Parity Technologies and Polkadot Technical Fellowship member, has made numerous successful contributions to the Polkadot ecosystem, including runtime updates, parachain management features, and governance pallet enhancements. Notable examples include a WASM code substitute to address a compiler bug and adding the propose parachain pallet, both merged into the polkadot-sdk repository. These changes, requiring deep technical expertise, demonstrate his ability to handle complex system-level tasks comparable to the Coretime allocation proposed in Referendum #1536.

Justification

Bkchr’s contributions, such as runtime and governance improvements, are well-documented and align with the proposal’s technical demands, earning high credibility among community members and whales for executing complex changes.

Score: 9/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?

Bkchr has implemented projects like updating Polkadot’s runtime to Substrate 1.0 and fixing vested claims to ensure proper token locking, both requiring intricate knowledge of Polkadot’s architecture. His work on the propose parachain pallet involved governance-related features, directly relevant to crafting XCM messages for Coretime allocation. These projects indicate strong technical skills in runtime, governance, and parachain mechanics, suggesting he can effectively execute the proposal’s straightforward governance action to assign Coretime.

Justification

The comparable projects showcase bkchr’s expertise in areas critical to the proposal, reinforcing his capability to implement the required changes, though the governance precedent may raise minor concerns among voters.

Score: 8/10

■Question 18 of 19

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

Bkchr’s expertise is supported by his GitHub contributions to polkadot-sdk and Substrate, with merged pull requests like #3093 and #2243 reviewed by Parity developers. His Polkadot Technical Fellowship membership, a peer-reviewed recognition of core contributors, further validates his credibility. While direct community feedback on X or forums is limited, the acceptance of his code changes and Fellowship status provide objective evidence of trust and expertise, meeting the scrutiny of community members.

Justification

Publicly available GitHub records and Fellowship membership offer strong evidence of bkchr’s credibility, though additional community feedback could enhance confidence, justifying a high score.

Score: 8/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?

Bkchr, supported by the Polkadot Technical Fellowship, possesses the technical expertise to implement the proposal’s XCM-based Coretime allocation, as evidenced by his runtime and governance contributions. The Fellowship’s oversight ensures organizational strength, aligning the one-time intervention with community expectations for ecosystem stability. The straightforward nature of the proposal reduces organizational demands, making bkchr’s individual capabilities sufficient for execution.

Justification

Bkchr’s technical skills and Fellowship backing provide robust expertise and support, meeting expectations for a critical fix, though some whales may question the governance implications, supporting a strong score.

Score: 8/10

■Result category 5

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