Threshold
Dear Proposer,
Thank you for your proposal. Our first vote on this proposal is NAY.
The Big Spender track requires 60% quorum according to our voting policy v0.2, and any referendum in which the majority of members vote abstain receives an abstain vote. This proposal has received one aye and two nay votes from ten available members, with three members abstaining. Below is a summary of our members' comments:
The discussion featured a mix of cautious support and pointed criticism. One voter appreciated the division of payments and saw continuity with previous proposals, while several others abstained, citing insufficient technical expertise to fully assess the contributions. Two critics, despite acknowledging the team’s proven competence, deemed the strategic shift toward treasury funding for Polkadot-SDK development premature. They argued that additional preparation, wider community debate, and broader consensus were needed before pursuing such a change. In conclusion, although the team’s professional background and prior work were recognized, concerns about adequate groundwork led to an overall negative outcome on the proposal.
The full discussion can be found in our internal voting.
Please feel free to contact us through the links below for further discussion.
Kind regards,
Permanence DAO
Decentralized Voices Cohort IV Delegate
📅 Book Office Hours
💬 Public Telegram
🌐️ Web
🐦 Twitter
🗳️ Delegate
Per Pierre's comments, there is no longer a functional / up to date golang api implementation. I was unable to build out my project because centrifuge dropped it, metadata became out of date, and I don't have the skills / knowledge necessary to fix it. If you guys could take that over, clean it up, and maybe make it a bit easier on use -- I can't speak for anyone else but I'd certainly vote aye to it.
Edited
To answer some more questions that came up:
How will Parity monitor the work and ensure deliverables are met?
Parity engineers are working closely with Chainsafe engineers. Every pull request from Chainsafe gets reviewed by Parity engineers, code designs are discussed between the teams, architectural decisions agreed upon and there is a regular sync call.
Will Parity be ready to cancel the referendum or stop funding if deliverables are not fulfilled?
Yes. Parity is investing resources into this relationship, if this does not turn out to be productive, Parity will definitely cancel remaining milestones. Parity’s whole mission is to make Polkadot successful, so we do have a vested interest to make this partnership effective and to be mind- and careful with treasury funds. Going with a milestone based proposal is part of this approach, as it greatly reduces risk for token holders.
That being said, in the end what matters is that money is well spent and this implies some flexibility, as things rarely go exactly as planned. Deviations from promised deliverables should be acceptable, if they are communicated in a timely manner and have proper justification. Here again, Parity is acting as a curator, and is well-positioned to offer an informed opinion on the validity of the reasons given.
Some items (e.g., Approval Rewards, WebRTC) are clearly important, but others appear less critical.
The collaboration was essentially started by looking into Parity’s roadmap/backlog and seeing what Chainsafe can collaborate with. All of them are important and would have been taken care of by Parity itself at some point: With Chainsafe we can go there faster!
Since the scope was not proposed in collaboration with the community, there are concerns about prioritization and relevance.
Happy to answer and discuss any specific questions related to this topic!
If Parity is suggesting and driving these items, should Parity also define an SLA and consider funding from its own budget, rather than treasury funds?
Maybe, but these things would take time and it would be a shame to lose talent for Polkadot, because we stop funding good teams. Instead we decided to step in with a collaboration proposal, using the structures already in place to play our part in ensuring Chainsafe has the means and mission to continue contributing to the success of Polkadot.
Many community members find the Statement of Work difficult to understand and thus cannot judge whether it is reasonable.
It would be very valuable if someone from the Fellowship could review and confirm its soundness.
For what it is worth we had a couple of Parity engineers have a look at the proposal and they all agreed it is reasonable. If any other independent fellowship member wants to have a look, that would be very welcome.
In any case, thank you for these valuable questions! I hope I was able to bring some clarity.
All the best,
Robert
TruthDAO votes NAY
The proposal is fragmented, and we suggest splitting the budget—separating the core functions (approval rewards, WebRTC) into their own proposal, while leaving other candidate projects to be voted on by the community separately.
From the team’s responses to community questions, it seems they view ChainSafe as essentially operating like a Parity team. In that case, these costs should be covered by Parity or the Web3 Foundation, not by the DAO. After all, the Foundation originally received 25% of DOT at genesis, while the Treasury currently holds only around 28M DOT—less than 2% of total supply.
See the full feedback here.
📖Truth DAO Governance Statement
💭 Email: open@truthdao.cn, Telegram
🗳️ Delegate
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.
Edited