Proposed by:
Requested amount:
0 DOT

#1549 · KAGOME – the C++ implementation of Polkadot Host milestone 4

KAGOME treasury proposal 4: Enhancing Polkadot clients diversity

Context of proposal

KAGOME is a C++ implementation of the Polkadot Host that brings clients diversity to Polkadot and Kusama networks mitigating risks associated with fatal bugs, fostering innovation, and expanding the development community. 

During Milestone 3, the final features for complete Polkadot-SDK node compatibility were implemented. Consequently, KAGOME became the first alternative Polkadot Host implementation to participate in Polkadot's validating set. This accomplishment positions Polkadot among a select group of networks, including Ethereum and Filecoin, that support multiple client implementations.

https://x.com/Polkadot/status/1910660705256190293 

Future cohorts of the Decentralized Nodes program aim to have more node operators running KAGOME (link) which will increase the portion of validators running alternative clients in the network leading to higher network resilience and stability.

The scope of this proposal is targeting implementation of new RFCs in KAGOME as well as necessary features to keep KAGOME compatible with Polkadot-SDK. 

This is a joint proposal with our long term partners SRLabs, who are helping us with the security assessment of KAGOME to give confidence to node operators. Previous work by SRLabs with our team helped us to identify several critical issues, which were addressed by our team (link, link). Given the increasing adoption of KAGOME by node operators, a thorough security assessment is more crucial than ever.

The Web3 Foundation will partner on this proposal as technical advisor and deliverables auditor to ensure the completed milestones are technically sound.

Alignment with JAM

Quadrivium is also developing a JAM client alongside KAGOME. 

However, multiple Polkadot Host implementations are important today, particularly because KAGOME already works with the Polkadot SDK. Additionally, alternative clients such as KAGOME offer a valuable opportunity for Polkadot to prepare for supporting multiple clients following the JAM upgrade, which we expect to happen no sooner than in a year or two.

The scope of proposal

  • Security assessment of new features by SRLabs
  • Libp2p coroutines revamp
  • Claim queue
  •      Grid in approvals (retroactive)
  • Remove async backing params
  • Trie caching
  • Traces
  • Faster erasure coding (RFC-139)
  • Pending code storage key (RFC-123)
  • Standardize compressed blob prefixes (RFC-135)
  • Reputation system for disputes and statement distribution
  • PVF improvements (retroactive):
    • PVF execution parameters
    • PVF priority
    • PVF unix socket
    • PVF clone
  • Constrain parachain block validity on a specific core (RFC-103, retroactive)
  • Networking improvements (retroactive)
    • QUIC support
    • Audi-v3 (RFC-91)
    • Parallel sync
  • Tests & post-security audit improvements (retroactive)

Link to full proposal

Requested funding

  • Quadrivium: 636,000 USDC
  • SRLabs: 345,800 USDC
  • Total: 981,800 USDC

About Quadrivium

Quadrivium (https://www.qdrvm.io ) is a blockchain infrastructure development company founded in 2023.

The company specializes in the development of blockchain clients, peer-to-peer networking tools, and zk-cryptography. Quadrivium develops KAGOME Polkadot Host implementation, in partnership with the Web3 Foundation. The company also maintains the C++ libp2p library.

About SRLabs

SRLabs (https://www.srlabs.de/) is home to knowledge leaders securing critical infrastructures in finance, blockchain, energy, and telecommunications.

The company focuses on hands-on hacking resilience, not compliance. Their approach is shaped by combining their hacking research with impactful consulting work for innovation leaders who naturally thrive on cutting-edge technologies.

SRLabs is one of the leading blockchain audit companies with experience in many Substrate-based blockchains, including the Polkadot layer-0 relay chain and parachains built on top.

Read more
StatusDeciding · 20d
84%Nay
Aye (42)
2.28M DOT
Nay (125)
12.47M DOT
Decision7 / 28d
0.0%8.01%
6.41%Support Threshold
0Support Threshold
Support(0.04%)
642.094K DOT
Issuance
1.56B DOT
Vote
OG_Tracker

OG Tracker Rating 3/3

Clear display of deliverables✅

  • Security assessment of new features by SRLabs
  • Libp2p coroutines revamp
  • Claim queue
  • Grid in approvals (retroactive)
  • Remove async backing params
  • Trie caching
  • Traces
  • Faster erasure coding (RFC-139)
  • Pending code storage key (RFC-123)
  • Standardize compressed blob prefixes (RFC-135)
  • Reputation system for disputes and statement distribution
  • PVF improvements (retroactive):
  • Constrain parachain block validity on a specific core (RFC-103, retroactive)
  • Networking improvements (retroactive)
  • Tests & post-security audit improvements (retroactive)

Clear display of a valid direct point of contact ✅

Clear display of proposal’s duration✅

  • The duration of this proposal is 10 months (01.11.2024 - 01.09.2025)

OGT Rating aims to help voters make better informed decisions and direct proposers towards certain common-good practices. We are providing feedback based on 3 simple yet crucial criteria which we believe should be included in every OpenGov referenda.

Thank you for the clarification @kml

Our Rating has been updated!

kmlMay 5
OG_Tracker

OG Tracker Rating 3/3

Clear display of deliverables✅

  • Security assessment of new features by SRLabs
  • Libp2p coroutines revamp
  • Claim queue
  • Grid in approvals (retroactive)
  • Remove async backing params
  • Trie caching
  • Traces
  • Faster erasure coding (RFC-139)
  • Pending code storage key (RFC-123)
  • Standardize compressed blob prefixes (RFC-135)
  • Reputation system for disputes and statement distribution
  • PVF improvements (retroactive):
  • Constrain parachain block validity on a specific core (RFC-103, retroactive)
  • Networking improvements (retroactive)
  • Tests & post-security audit improvements (retroactive)

Clear display of a valid direct point of contact ✅

Clear display of proposal’s duration✅

  • The duration of this proposal is 10 months (01.11.2024 - 01.09.2025)

OGT Rating aims to help voters make better informed decisions and direct proposers towards certain common-good practices. We are providing feedback based on 3 simple yet crucial criteria which we believe should be included in every OpenGov referenda.

@OG_Tracker sure, as linked to my identity you may contact me via element @kamilsa:matrix.org , or you can send an email to [email protected]

SoulMay 4

KAGOME’s strategic value with a clear request for transparency have offer my vote of confidence

OG Tracker Rating 3/3

Clear display of deliverables✅

  • Security assessment of new features by SRLabs
  • Libp2p coroutines revamp
  • Claim queue
  • Grid in approvals (retroactive)
  • Remove async backing params
  • Trie caching
  • Traces
  • Faster erasure coding (RFC-139)
  • Pending code storage key (RFC-123)
  • Standardize compressed blob prefixes (RFC-135)
  • Reputation system for disputes and statement distribution
  • PVF improvements (retroactive):
  • Constrain parachain block validity on a specific core (RFC-103, retroactive)
  • Networking improvements (retroactive)
  • Tests & post-security audit improvements (retroactive)

Clear display of a valid direct point of contact ✅

Clear display of proposal’s duration✅

  • The duration of this proposal is 10 months (01.11.2024 - 01.09.2025)

OGT Rating aims to help voters make better informed decisions and direct proposers towards certain common-good practices. We are providing feedback based on 3 simple yet crucial criteria which we believe should be included in every OpenGov referenda.

Many thanks for your proposal, kml!

We have carefully reviewed your application and are pleased to share our assessment below, prepared using our standardized evaluation methodology.

Summary of our analysis

Impact on the Ecosystem

The KAGOME Milestone 4 proposal significantly enhances Polkadot’s resilience and relevance by advancing a C++ Polkadot Host, mitigating single-client risks and fostering developer diversity. It promotes parachain development through features like the Fair Claim Queue and PVF improvements, ensuring long-term scalability. Sustainable value depends on continued maintenance, but the proposal aligns with Polkadot’s strategic goals.
Score: 8.50/10

Governance Compatibility

The proposal aligns well with the BigSpender track, requesting 981,800 USDC for critical infrastructure, fitting the track’s high-impact focus. It builds on the successful KAGOME Milestone 3 (Referendum #925), demonstrating governance compatibility. The governance system is used meaningfully without overburdening, supported by a detailed scope and Web3 Foundation oversight.
Score: 8.33/10

Cost-Benefit Ratio

The 981,800 USDC request is largely proportionate to benefits like enhanced resilience, security, and JAM readiness, though its scale requires scrutiny. The budget is reasonable compared to prior milestones, but the lack of cheaper alternative considerations limits transparency. The Treasury gains a robust client, improved parachain functionality, and developer diversification.
Score: 7.50/10

Transparency and Traceability

The proposal provides detailed budgets, timelines, and work packages, enabling robust tracking, but lacks quantitative KPIs and a formal documentation plan. Success criteria focus on feature completion and audits, supported by Web3 Foundation reviews. Transparency is constrained by missing metrics and reporting commitments, reducing evidence-based evaluation.
Score: 7.00/10

Record and Credibility

Quadrivium and SRLabs have verifiable contributions through KAGOME and security audits, with successful projects like prior milestones and KILT Protocol audits. Public repositories and presentations support credibility, though Filecoin claims and audit report access are limited. The team’s expertise ensures delivery capability, but maintenance and transparency gaps pose minor risks.
Score: 7.50/10

Conclusion

The overall score is 7.77/10
🔹🔷🔹 vonFlandern 🔹🔷🔹 has therefore voted with: ** AYE **


Our methodology aims to analyze and evaluate OpenGov proposals objectively, effectively, and transparently, establishing clear decision-making foundations for our votes while making our process visible to the community.

For a deeper dive into our evaluation, please see the detailed report here.
xcRom1May 1
xcRom1

Hello and thank you for the proposal. I am unable to access the link to the full proposal — I get the message “Sorry, the file you requested does not exist.”

Given the amount requested and the strategic importance of KAGOME for customer diversity (and therefore network resilience), it would be really helpful to have access to all the details: deliverables, schedule, cost breakdown, etc.

Thanks

@kml thanks a lot for the link update

kmlMay 1
xcRom1

Hello and thank you for the proposal. I am unable to access the link to the full proposal — I get the message “Sorry, the file you requested does not exist.”

Given the amount requested and the strategic importance of KAGOME for customer diversity (and therefore network resilience), it would be really helpful to have access to all the details: deliverables, schedule, cost breakdown, etc.

Thanks

@xcRom1  Sorry, there are some issues with copy pasting google drive links. I just fixed it by adding hyperlink in the text

xcRom1May 1

Hello and thank you for the proposal. I am unable to access the link to the full proposal — I get the message “Sorry, the file you requested does not exist.”

Given the amount requested and the strategic importance of KAGOME for customer diversity (and therefore network resilience), it would be really helpful to have access to all the details: deliverables, schedule, cost breakdown, etc.

Thanks

Powered by Subsocial