Please Vote NAY. Replaced with https://polkadot.polkassembly.io/referenda/1699
2 months ago
Rejected
Comments (6)
Requested
815.36K USDC
Proposal Failed
Summary
0%
Aye
0%
Nay
Aye (11)0.0 DOT
Support0.0 DOT
Nay (49)0.0 DOT
Please Vote NAY. Replaced with https://polkadot.polkassembly.io/referenda/1699
Comments (6)
Requested
Proposal Failed
Summary
0%
Aye
0%
Nay
Aye (11)0.0 DOT
Support0.0 DOT
Nay (49)0.0 DOT
Hello, I have two questions:
What will happen with the Gosaamer client? Will they continue to provide maintenance or will that require additional funding?
I'd like to know if Parity already has staff assigned to cover the ongoing development of the existing Rust-based SDK implementation and what your specific relationship will be with that team?
Thanks
@SIM-DOT
Thanks for these important questions - you're right that they weren’t clearly addressed in our proposal, so I appreciate the opportunity to clarify.
Maintaining and developing a project as large and demanding as Gossamer requires a significant team and substantial resources. At this stage, the continued development of Gossamer doesn’t seem to be a pressing need from the network’s perspective, as reflected in the outcomes of previous referenda.
That said, Gossamer is more than just code - it represents a team with deep experience and knowledge built over time. To preserve that value and ensure our efforts continue contributing meaningfully, we’ve decided to shift our focus to the Polkadot SDK, the dominant Rust implementation of Polkadot.
While we can’t make any formal commitments, we still care deeply about the Gossamer project and will do our best to maintain it and contribute to related work when time allows.
Regarding the second question - as mentioned earlier, building and maintaining a blockchain is an enormous undertaking, and the scope of work required within the Polkadot SDK continues to grow. Currently, the workload exceeds what Parity alone can cover with their available resources.
The work outlined in our proposal focuses on critical aspects of protocol stability, security, and scalability. The scope of work has been agreed upon with Parity to allow them to reallocate their internal resources to other priorities while we take on these tasks.
To clarify, there isn’t a dedicated team at Parity currently assigned to this specific work. It will be carried out solely by our team, with support as needed from both the Parity and Web3 Foundation research teams.
A few questions:
$94.37/hour, reflecting the team’s expertise and responsibilities.
. I assume that these 9 engineers have worked on Gossamer in the past and therefore should have some expertise in Polkadot. However, according to the Gossamer github statistics in the past 12 months only 7 people contributed more than 100 lines of code to Gossamer. So, do you really have 9 engineers with the necessaryexpertise
to be working on the scope of proposal or you just increased engineering count to make a higher request to the treasury?@14fXNAPHnfymHRN3s47VWFBwSnnqTC594uuVVnsB9TqpUihV
Hello, thanks for all the questions.
1 As outlined in the financial section of our proposal, the 9 team members include a mix of roles: one engineering manager, one recently hired junior engineer, and one engineer focused primarily on infrastructure, CI, and local testnets.
2.1 Specifically, to address the budget concern, we would like to address the previous proposal budget part
2.2 As discussed in our previous referendum response to Bill’s comment and detailed in the previous proposal, protocol development in Polkadot is complex and constantly evolving. Some deliverables were replaced or reprioritized in response to higher-impact or time-sensitive needs. This shift wasn’t a failure to deliver- it was a strategic decision to focus efforts where they would provide the most long-term value.
2.3 Although Gossamer is written in Go, our team's expertise lies in deep protocol understanding - consensus, architecture, and runtime - not just language-specific implementation. Moreover, programming language is just a tool. The polkadot-sdk code effectively defines the Polkadot protocol, and is written in Rust so we've developed strong familiarity with the language over the time. Given that most of the Polkadot protocol isn’t fully spec’d out, we have spent an enormous amount of time reading and debugging the rust code, so the transition to authoring rust code isn’t going to be a large learning curve.