Gossamer's Contributions to Polkadot-SDK v2 [Q3/Q4 2025]
Gossamer's Contributions to Polkadot-SDK v2 [Q3/Q4 2025]
NOTE ON REFERENDA UPDATE:
This is a new proposal intended to replace Ref 1688
Following extensive consultations with Parity and the Polkadot community, we have introduced several key improvements.
- Payouts were split to bi-monthly retroactive milestones
- New sections were added:
- Payout structure.
- Detailed milestone delivery description
- FAQ with addressed and frequently asked questions from previous referenda
Total Requested amount for 3 milestones: 815 358 USDC
Milestone 1: 271 786 USDC. Payout on: 10/09/2025
Milestone 2: 271 786 USDC. Payout on: 10/11/2025
Milestone 3: 271 786 USDC. Payout on: 10/01/2026
Beneficiary address: 149mJjdQjEBMHHbWDjbLJ7X4e95ps6L35DZVaBzn1raR1EVQ
Short description: Gossamer was originally envisioned as a Go-based implementation of the Polkadot Relay Chain Validator, contributing to the decentralization and resilience of the network through client diversity and broader technological accessibility. Our team, deeply committed to the Polkadot ecosystem, built Gossamer as an alternative full node and validator client to help ensure the robustness of the protocol.
However, as the ecosystem's needs have changed, it's become clear that alternative client development is not currently a top priority. In light of this, we’ve made a strategic decision to shift our focus from developing an alternative client to contributing directly to the existing Rust-based SDK implementation. This change aligns with both the direction of the ecosystem and our desire to maximize our impact on Polkadot’s core infrastructure.
Following consultations with Parity, we have defined a set of objectives that our team will focus on over the next six months. These efforts, in close collaboration with Parity, will leverage our experience to contribute to the Polkadot-SDK's most critical areas, helping to strengthen, optimize, and scale the protocol at its foundation.
Project Category/Type: Software development
Website: ChainSafe
Context of the Proposal
The Gossamer team at ChainSafe is a group of technical experts engaging in protocol-level implementations for the Polkadot ecosystem. The team has formerly received funding from the Web3 Foundation and the Polkadot Treasury and has also been temporarily self-funded through ChainSafe.
This proposal is a request for six months of funding (equally split to bi-monthly milestones) from the Polkadot Treasury for the collaboration of the Gossamer team and Parity to work on the Polkadot protocol's (polkadot-sdk) pressing needs. The ecosystem is rapidly evolving, and a lot of change is to be expected. We are therefore adopting a six-month proposal cycle to maintain agility and responsiveness to best serve the ecosystem.
In this funding period, as detailed in Section 2 (Scope of Current Proposal), we will dedicate resources to the needs of the polkadot-sdk by addressing key technical priorities identified in collaboration with Parity. Our focus will be on areas where our team’s expertise can deliver the greatest impact - enhancing scalability, performance, and protocol robustness. This marks a natural evolution of our role within the ecosystem, transitioning from client diversity through Gossamer to strengthening the core infrastructure that supports the Polkadot network. Our focus will be on areas where our team’s expertise can deliver the greatest impact - protocol development.
Proposal navigation:
- Context of the proposal
1.1 About ChainSafe and the Gossamer Team - Scope of Work
2.1 Approval-checking rewards
2.2 Parachain runtime upgrades off-chain R&D
2.3 Optimizing the dependency footprint
2.4 WebRTC transport for browser-based LightClients
2.5 Speculative Availability
2.6 Polkadot network chaos testing and DDoS protection
2.7 Smart Contracts Infrastructure Integration (Foundry-Polkadot) - Budget and payout structure
- Progress, Updates, and Milestones Delivery
- Contacts
- FAQ including the community questions and our answers from the previous referenda
Contact:
Kyrylo Pisariev, Senior Engineering Manager, kirill@chainsafe.io, @p1sar:matrix.org
Peter Kalambet, Head of Protocol, peter@chainsafe.io, @peter:dod.ngo
Belma Gutlic, VP of Engineering, belma@chainsafe.io, @morrigan.iv:matrix.org
Progress and Updates:
- Monthly progress reports (GitHub discussions, X, polkadot forum)
- GitHub code progress (Github Project)
- Presentations at Polkadot events
- Documentation updates
Comments (11)
Requested
Proposal Passed
Summary
0%
Aye
0%
Nay
Aye (31)0.0 DOT
Support0.0 DOT
Nay (28)0.0 DOT
Priorities have shifted and alternative clients are no longer seen as the most crucial at present. Instead we want to focus on the already existing client written in Rust.
It makes sense to reuse the existing rare skills by the Chainsafe team and put them to good use where it is needed the most.
Together we carefully identified critical missing pieces, which are currently not covered by Parity and are looking forward to the contributions by Chainsafe, helping improve the quality of the client and getting important features and fixes much earlier than it would have been possible otherwise.
We are delighted of the possibility of having a great team start contributing to the Rust client, improving diversity in a slightly different way.
Robert K. and Pierre A.
I appreciate the intent behind this proposal, but I see several red flags that make it hard to support as written:
1) Staffing claims vs. public evidence
ChainSafe is requesting funds for 8 full‑time protocol developers, yet there’s little public evidence to substantiate that capacity or seniority. With the first 271,786 USDC payment due in less than a month, we should already have verifiable evidence: names, years of relevant protocol experience, and contribution histories (PolkadotSDK and related repos).
After reviewing the work ChainSafe has presented, it’s difficult to reconcile the output with eight full‑time, competent protocol engineers:
Given this, it’s hard to believe we’re seeing the work product of eight full‑time protocol developers.
2) Delivery, accountability, and a pause mechanism
How will DOT holders know if ChainSafe is delivering? Will Parity provide bi‑monthly performance reports? In my view, given the size of prior Treasury engagements, stronger safeguards are warranted. How do DOT holders “pull the plug” if progress lags?
3) Who should own and manage this engagement?
This work targets the PolkadotSDK, which is Parity’s repository. Parity engineers will need to coordinate, review, and ultimately merge any PRs. If Parity wants to delegate part of this work, the sensible path is a Service Level Agreement funded from the existing Web3 Foundation allocation that Parity receives. If they lack the funds, Parity should itself request Treasury funds and contract ChainSafe directly. Parity has already done this recently with other teams after delegating work they previously handled. If Parity’s developers must review ChainSafe’s output regardless, then Parity -not DOT holders- should negotiate fair rates and enforce their own standards.
EDIT
With regards to the WebRTC work, I just found 2 PRs (1, 2) by Timothy Wu, which were not included in the work report that ChainSafe presented. So, there is, thankfully, a bit more work than that initial analysis.
I still have a hard time finding evidence of 8 full-time engineers, though.
Hey @Josep
Since our conversation was mostly held on the KusDAO Discord server, I would like to take this opportunity to post the same responses here for a wider audience to be fully transparent. Since it is a pretty big chunk of text, here is the link for the HackMD document
>>>> https://hackmd.io/@P1sarb/rJNBACeFlg <<<<
Thank you for sharing your concerns and allowing us to cover them in a constructive dialogue.