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

KAGOME – the C++ implementation of Polkadot Host milestone 4

Track: 34 | Origin: BigSpender | Amount: 981.800 USDC

Summary of the proposal

Core Issue

The proposer aims to enhance Polkadot’s network resilience by advancing KAGOME, a C++ Polkadot Host implementation, to increase client diversity.

Ecosystem Impact

Client diversity reduces reliance on a single client, enhances security, and fosters innovation, strengthening the Polkadot ecosystem.

Proposed Action

Quadrivium and SRLabs request 981,800 USDC to implement new RFCs, ensure Polkadot-SDK compatibility, and conduct security assessments over 10 months.

Expected Outcomes

The proposal will improve network stability, security, and readiness for future upgrades like JAM, benefiting the entire Polkadot ecosystem.

■Question 1 of 19

Does the proposal measurably contribute to the long-term development, adoption, resilience, or relevance of Polkadot?

The KAGOME Milestone 4 proposal significantly enhances Polkadot’s long-term resilience and relevance by developing a C++ implementation of the Polkadot Host, reducing the risk of network failures from single-client vulnerabilities. Client diversity ensures operational continuity if one client fails, strengthening network stability. Security assessments by SRLabs build trust among node operators, encouraging KAGOME adoption. Implementing new RFCs and maintaining Polkadot-SDK compatibility keep the network technologically current, supporting ongoing development. By attracting C++ developers, the proposal diversifies the developer base, fostering innovation and adoption. These efforts position Polkadot as a competitive, secure blockchain, maintaining its relevance in a dynamic ecosystem.

Justification

Client diversity is a proven strategy for blockchain resilience, as evidenced by Ethereum’s multi-client approach preventing consensus failures. KAGOME’s validator participation demonstrates tangible progress. Security and compatibility efforts ensure sustained development, while developer diversification drives adoption. Measurable outcomes include increased node operators using KAGOME, aligning with the Decentralized Nodes program’s goals.

Score: 9/10

■Question 2 of 19

What sustainable added value does the proposal bring to the Polkadot ecosystem in the long term, beyond the immediate project duration?

Beyond its 10-month duration, the proposal establishes KAGOME as a robust alternative client, providing lasting client diversity to mitigate network disruptions from single-client issues. This fosters ongoing competition among client developers, driving software quality and innovation. Security enhancements from SRLabs’ audits offer enduring protection against vulnerabilities, enhancing network reliability. The C++ codebase attracts specialized developers, sustaining a diverse talent pool. Preparation for future upgrades like JAM ensures Polkadot’s adaptability to multi-client architectures. With continued maintenance, KAGOME’s contributions to stability and developer engagement will persist, making the network more reliable and appealing for long-term growth.

Justification

Alternative clients are integral to blockchain ecosystems, as seen in Ethereum’s sustained benefits from client diversity. KAGOME’s security and JAM alignment provide persistent value. Developer engagement ensures ongoing innovation, but sustainability depends on post-project support, which the proposal implies through Quadrivium’s commitment.

Score: 8/10

■Question 3 of 19

Is an existing structural weakness addressed?

The proposal directly addresses the critical structural weakness of single-client dependency by advancing KAGOME as a reliable alternative to the Polkadot-SDK client. This reduces the risk of network-wide failures from bugs or vulnerabilities in a single implementation, a significant concern in blockchain systems. SRLabs’ security audits ensure KAGOME’s robustness, mitigating potential client-specific weaknesses. By diversifying client options, the proposal enhances Polkadot’s operational reliability and aligns with best practices for decentralized networks, strengthening the network’s foundational architecture.

Justification

Single-client reliance is a recognized risk, as demonstrated by Ethereum’s past network partitions due to client bugs. KAGOME’s development, validated by rigorous audits, mitigates this weakness, enhancing Polkadot’s stability and trustworthiness.

Score: 9/10

■Question 4 of 19

Does the proposal promote interoperability, user retention, or parachain development?

The proposal significantly advances parachain development through features like the Fair Claim Queue, which ensures equitable core time allocation, and PVF improvements, enhancing validation efficiency and security. RFC-103 strengthens parachain scalability by constraining block validity, while RFC-135 standardizes blob handling, supporting diverse runtimes. These enhancements improve parachain functionality and interoperability with the relay chain, facilitating seamless interactions. While primarily infrastructure-focused, a stable and secure network indirectly supports user retention by ensuring reliability. The proposal’s technical improvements create a robust environment, fostering parachain growth and ecosystem scalability.

Justification

The Fair Claim Queue and PVF enhancements directly address parachain operational needs, critical for Polkadot’s ecosystem. RFC-103 and RFC-135 improve scalability and standardization, aiding interoperability. Network stability indirectly bolsters user trust, though direct retention strategies are limited.

Score: 8/10

■Result category 1

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

■Question 5 of 19

Does the proposal clearly fall within the scope of the chosen origin (Treasury, Tipper, Spender)?

The proposal clearly aligns with the BigSpender track, requesting 981,800 USDC (approximately 981,800 DOT at current prices) for significant infrastructure development. The BigSpender track, designed for large-scale treasury expenditures up to 1,000,000 DOT, supports projects requiring substantial funding, such as KAGOME’s development of a C++ Polkadot Host implementation. The proposal’s scope, including new RFC implementations, security audits by SRLabs, and DevOps maintenance, fits the track’s purpose of funding impactful ecosystem projects. The detailed budget and 10-month timeline further justify the high funding request, adhering to the track’s parameters for significant, well-planned initiatives.

Justification

The BigSpender track is intended for high-value projects enhancing the Polkadot ecosystem, as outlined in the Polkadot OpenGov documentation. The proposal’s funding request and scope match the track’s maximum limit and purpose. No discrepancies in track selection are evident, and the proposal’s technical complexity supports its classification.

Score: 9/10

■Question 6 of 19

Are there previous proposals with comparable content, and if so, what were their outcomes?

The proposal follows KAGOME Milestone 3 (Referendum #925), which funded similar client diversity efforts and was successfully approved, with funds allocated for features like grid topologies and validation protocols. Other infrastructure proposals, such as node infrastructure by OnFinality and DatDot’s P2P hosting, have also been funded via the treasury, indicating a pattern of supporting critical network components. While specific outcomes for these projects vary, Referendum #925’s approval and KAGOME’s subsequent validator participation suggest positive results. No direct conflicts or redundant proposals were identified, and the current proposal builds logically on prior work, focusing on new RFCs and security enhancements.

Justification

Referendum #925’s success and KAGOME’s validator integration demonstrate the viability of similar proposals. The treasury’s history of funding infrastructure projects supports the proposal’s relevance. The absence of conflicting proposals and the proposal’s continuation of Milestone 3 align with governance expectations for iterative development.

Score: 8/10

■Question 7 of 19

Is the governance system being used meaningfully or burdened?

The proposal meaningfully utilizes the governance system by addressing a critical need for client diversity, a strategic priority for Polkadot’s resilience. Submitted under the BigSpender track, it leverages OpenGov’s ability to handle high-impact referenda efficiently. The detailed budget, clear scope, and involvement of Web3 Foundation as a technical auditor demonstrate responsible use of the system. While the high funding request places scrutiny on treasury resources, it does not overburden the system, as OpenGov’s parallel tracks allow concurrent proposal processing. The proposal’s alignment with ecosystem goals and prior milestones ensures it contributes constructively to governance without undue strain.

Justification

OpenGov’s design supports multiple referenda across tracks, preventing bottlenecks. The proposal’s strategic focus on client diversity and robust planning avoids frivolous use of governance resources. The treasury’s capacity to fund large projects, as seen in past referenda, indicates the system can handle such requests without being burdened.

Score: 8/10

■Result category 2

Total score: 25/30 | Average: 8.33/10 (83%)

■Question 8 of 19

Is the requested amount proportionate to the potential or demonstrated benefit?

The 981,800 USDC request is largely proportionate to the potential benefits, which include enhanced network resilience through client diversity, robust security via SRLabs’ audits, and readiness for future upgrades like JAM. Developing an alternative client mitigates risks of network failures, a critical factor for Polkadot’s stability, as evidenced by KAGOME’s validator participation. Features like the Fair Claim Queue and PVF improvements support parachain scalability. However, the high funding amount, close to the BigSpender track’s 1,000,000 DOT limit, demands rigorous justification given treasury constraints. The demonstrated impact of prior milestones supports the cost, but the scale warrants careful scrutiny to ensure optimal resource allocation.

Justification

Client diversity is vital for blockchain resilience, reducing single-client failure risks, as seen in Ethereum’s multi-client ecosystem. The proposal’s scope, covering 7,200 hours of development and auditing, aligns with the complexity of client implementation. Milestone 3’s success (Referendum #925) validates KAGOME’s impact. Industry-standard costs for blockchain development (100–200 USD/hour) support the budget, but the treasury’s finite resources necessitate a conservative evaluation.

Score: 8/10

■Question 9 of 19

Is the budget framework reasonable compared to similar proposals?

The budget framework is reasonable compared to prior KAGOME milestones and other Polkadot treasury proposals. Milestone 3 (Referendum #925) was funded with 141,395 DOT, equating to 858,338 USD at a June 2024 DOT price of 6.07 USD (Yahoo Finance). Milestone 4’s 981,800 USDC, a 14% increase, reflects expanded scope, including new RFCs and JAM preparation. Other proposals, like a 97,000 DOT (588,790 USD) security audit, are less costly but narrower. Quadrivium’s 120 USD/hour rate is slightly above the 104 USD/hour average for senior C++ blockchain developers, and SRLabs’ 182 USD/hour fits within the 150–300 USD/hour auditing range. Transparency on cost escalation could be improved.

Justification

The 14% increase from Milestone 3 is justified by additional tasks (e.g., RFC-139, RFC-135) and potential inflation. Industry benchmarks validate the rates, with Quadrivium’s expertise warranting a premium and SRLabs’ rate aligning with auditing norms. The detailed breakdown (5,300 development hours, 1,900 audit hours) supports reasonableness, though minor clarity gaps on cost drivers persist.

Score: 7/10

■Question 10 of 19

What specific added value does the Treasury or network gain in return for this expenditure?

The Treasury and network gain a robust alternative client, reducing single-client vulnerabilities and enhancing resilience. KAGOME’s implementation of RFCs (e.g., RFC-139 for erasure coding, RFC-135 for blob prefixes) improves parachain efficiency and scalability. SRLabs’ audits ensure validator trust, critical for adoption. JAM readiness prepares Polkadot for future multi-client architectures. The proposal attracts C++ developers, diversifying the talent pool and fostering innovation. These outcomes strengthen Polkadot’s security, scalability, and long-term competitiveness, delivering substantial ecosystem value.

Justification

Client diversity mitigates network failure risks, as demonstrated by Ethereum’s multi-client model. Features like Fair Claim Queue and PVF improvements directly support parachain operations, a core Polkadot component. Security audits and JAM preparation enhance trust and future relevance. Developer diversification drives innovation, aligning with Polkadot’s strategic goals.

Score: 9/10

■Question 11 of 19

Were cheaper alternatives considered?

The proposal does not address cheaper alternatives, a transparency gap that weakens its cost-efficiency case. Quadrivium’s expertise from prior milestones ensures continuity, and SRLabs’ Substrate knowledge justifies their auditing role. Alternative teams or languages (e.g., Go for Gossamer) could lower costs but risk delays or reduced quality due to unfamiliarity with Polkadot’s protocol. Open-source contributions might reduce expenses but require significant coordination. While the chosen approach is defensible, documenting alternative considerations would strengthen confidence in the budget’s necessity.

Justification

Quadrivium’s proven track record and SRLabs’ expertise minimize implementation risks, critical for a high-stakes client project. Industry rates (104 USD/hour for C++ developers, 150–300 USD/hour for auditors) suggest the budget is competitive. However, exploring alternatives could optimize treasury use, and the absence of such discussion limits transparency.

Score: 6/10

■Result category 3

Total score: 30/40 | Average: 7.50/10 (75%)

■Question 12 of 19

Is it clearly communicated how and for what purposes funds will be used—including KPIs, milestones, metrics?

The proposal clearly allocates 981,800 USDC, with 636,000 USDC for Quadrivium’s 5,300 development hours and 345,800 USDC for SRLabs’ 1,900 audit hours. Specific tasks, such as 400 hours for the Fair Claim Queue at 120 USD/hour, are detailed with costs and purposes. Milestones are marked with statuses like "Not started" or "Done," providing a tracking framework. However, it lacks quantitative Key Performance Indicators (KPIs), such as performance improvements (e.g., block processing time reduction) or node adoption rates, critical for evidence-based evaluation. The Web3 Foundation’s oversight ensures some accountability, but the absence of defined metrics limits transparency, as highlighted by the user’s concern about missing KPIs.

Justification

The budget and task allocations are transparent, with clear cost breakdowns and milestone statuses. However, the lack of KPIs, such as specific performance gains or validator uptake, is a significant gap. Industry standards for blockchain proposals often include metrics like throughput or adoption, which are not provided, reducing the ability to assess success objectively.

Score: 6/10

■Question 13 of 19

Are budgets, timelines, and work packages clearly specified?

The proposal specifies a 981,800 USDC budget, with 636,000 USDC for Quadrivium’s 5,300 hours at 120 USD/hour and 345,800 USDC for SRLabs’ 1,900 hours at 182 USD/hour. The timeline spans November 1, 2024, to September 1, 2025, aligned with release cycles (v1.0.0, v1.1.0, v1.2.0). Work packages, including Libp2p Coroutines Revamp (350 hours) and Faster Erasure Coding (100 hours), are detailed with hours and statuses. Dependencies, such as Polkadot-SDK compatibility, are implied but not explicitly mapped, a minor gap noted in the critical questions. This granularity enables robust monitoring and evaluation.

Justification

The detailed budget, precise timeline, and well-defined work packages meet high transparency standards. The release cycle structure addresses the user’s concern about milestone details, but the lack of explicit dependency mapping slightly reduces clarity on task interrelations, though this does not significantly impair traceability.

Score: 9/10

■Question 14 of 19

Are there success criteria for later evaluation?

Success is defined by completing features like RFC-123 and RFC-135, passing SRLabs’ security audits, and meeting Web3 Foundation’s technical standards. Measurable outcomes include feature integration into KAGOME’s validator and audit-verified code security. The Web3 Foundation’s auditing role ensures external validation. However, the absence of quantitative benchmarks, such as performance gains or adoption rates, as raised in the critical questions, limits evaluation depth. While task completion and audits are concrete, additional criteria like stress test results would enhance objectivity.

Justification

The criteria are clear and aligned with project goals, supported by external audits. However, the lack of quantitative metrics, particularly for performance or adoption, reduces the robustness of evaluation, warranting a conservative assessment.

Score: 7/10

■Question 15 of 19

Is documentation or reporting planned?

The proposal does not explicitly outline a formal documentation or reporting plan, a significant gap highlighted by the user. SRLabs’ audits and Web3 Foundation’s reviews imply audit reports and technical evaluations, while QA processes will generate bug and compatibility reports. GitHub pull requests provide task documentation. However, the absence of a committed plan for delivery reports or lessons learned, as per industry best practices, reduces transparency. Stakeholders expect explicit reporting schedules to ensure traceability, and this omission limits confidence in evidence-based evaluation.

Justification

Implied documentation through audits and QA aligns with project norms, but the lack of a formal plan, as raised by the user, is a notable omission. Best practices recommend explicit commitments to reporting, such as progress updates or lessons learned, to enhance accountability.

Score: 6/10

■Result category 4

Total score: 28/40 | Average: 7.00/10 (70%)

■Question 16 of 19

Have the proposers or involved organizations made verifiable, traceable contributions to the ecosystem?

Quadrivium has made significant contributions to Polkadot by developing KAGOME, a C++ Polkadot Host implementation that achieved validator integration in Polkadot, Kusama, and Westend networks, enhancing client diversity. They maintain the C++ libp2p library, a key networking component. SRLabs has conducted security audits for KAGOME and other Substrate-based blockchains, identifying critical vulnerabilities. These contributions are traceable through open-source repositories and network participation. However, Quadrivium’s claimed Filecoin contributions lack specific evidence, as no commits or pull requests are documented, slightly reducing transparency.

Justification

KAGOME’s validator role and libp2p maintenance are verifiable via GitHub repositories and Polkadot network data. SRLabs’ audits are documented in project reports, such as for KILT Protocol. The Filecoin claim, raised in critical questions, lacks proof, warranting a conservative evaluation despite strong Polkadot contributions.

Score: 7/10

■Question 17 of 19

What projects have been successfully implemented so far?

Quadrivium successfully delivered KAGOME’s prior milestones, integrating it as a validator in Polkadot, Kusama, and Westend. They maintain the C++ libp2p library, integral to Polkadot’s networking. Their team contributed to Hyperledger Iroha under Soramitsu, used in Cambodia’s CBDC system, though Quadrivium as an entity did not develop it. SRLabs completed audits for KAGOME (e.g., version 0.9.3, Milestone 3) and KILT Protocol, resolving critical issues. No failed projects are reported, but the Iroha attribution requires clarity, as noted in critical questions.

Justification

KAGOME’s milestones (Referendum #925) and libp2p’s active maintenance demonstrate Quadrivium’s delivery. Iroha’s success is tied to team experience, not Quadrivium directly, slightly limiting attribution. SRLabs’ audit reports confirm their expertise. No controversies undermine their record.

Score: 9/10

■Question 18 of 19

Are there publicly accessible references (e.g., code repositories, publications) or community feedback supporting the proposers’ credibility?

Quadrivium’s open-source repositories for KAGOME and C++ libp2p show active development. Presentations at Polkadot Decoded 2023 and Sub0 Asia 2024 are partially accessible via Polkadot’s YouTube channel, but slides and code examples are not fully public, limiting transparency. SRLabs’ blog posts and KILT Protocol audit summaries are available, though full KAGOME audit reports are confidential. Community feedback on X praises KAGOME’s validator launch, but Polkassembly discussions are sparse, reducing representativeness. These gaps in audit details, presentation metadata, and broad feedback, as raised in critical questions, constrain full transparency.

Justification

Repositories and presentations provide verifiable evidence, but incomplete slide access and limited audit reports reduce transparency. X feedback is positive but not comprehensive, and Polkassembly’s low engagement limits representativeness. The proposers’ reputation remains strong, but transparency gaps warrant a conservative evaluation.

Score: 7/10

■Question 19 of 19

Is the team capable of delivering the promised outcomes?

Quadrivium and SRLabs are likely capable of delivering the promised outcomes, leveraging their success with KAGOME’s prior milestones, Quadrivium’s blockchain expertise, and SRLabs’ audit proficiency. The team’s composition (4.5 senior C++ developers, 3 senior auditors) and Web3 Foundation oversight ensure technical and security rigor. However, critical questions highlight risks: no long-term maintenance guarantees, potential team fluctuation since the Soramitsu spin-off, and no budget buffers for scope creep (e.g., SDK changes). These uncertainties slightly temper confidence in sustained delivery, despite a strong track record.

Justification

Quadrivium’s validator integration and SRLabs’ audit success demonstrate capability. Web3 Foundation’s role mitigates risks. However, the lack of maintenance commitments, team stability details, and budget buffers, as raised, introduces risks, justifying a conservative evaluation.

Score: 7/10

■Result category 5

Total score: 30/40 | Average: 7.50/10 (75%)