Reflection on Decentralized Voices (DV) Cohort 4 & Philosophy for DV Cohort 5
Hey Polkadot DAO members,
I’m posting this on behalf of the JAM Implementers DAO, which I have been a member of during Decentralized Voices Cohort 4.
We’re the JAM Implementers DAO, a working group comprising 30 members from 17 JAM implementation teams, with representatives from 11 to 15 core JAM implementer teams voting during Decentralized Voices (DV) Cohort 4: one JAM implementer team, one vote.
Our shared goal is simple: support the long-term direction of Polkadot and Kusama through thoughtful, on-chain participation rooted in technical insight.
We were honored to serve as delegates in DV Cohort 4. It was our first cohort as a DAO, and we have been learning a great deal about the demands and responsibilities of being a delegate. In this post, we want to briefly reflect on that experience, share a few lessons, outline our updated voting philosophy, and explain why we’re applying again for Cohort 5.
Who We Are
The JAM Implementers DAO includes teams building the JAM protocol. Our active contributors include:
JAM DUNA, Gossamer, Jamixir, JavaJAM, JamSiz, JamPy, Vinwolf, TSJam, Boka, New JAMneration, MORUM, Tessera, Fluffy Labs | typeberry, JamBrains, Clawbird, SpaceJam, and Eiger.
We vote together, discuss proposals, and aim to reflect a shared view across the Polkadot ecosystem.
What We Learned in DV Cohort 4
Serving as a Decentralized Voice (DV) has been a learning experience for us, and our first cohort surfaced valuable operational and coordination insights:
-
DAO Coordination: We underestimated the time, commitment, and shared responsibility required. We have now established stronger internal workflows and voting processes to respond more quickly and consistently.
-
Kusama Voting Delay: We did not begin voting on Kusama referendums until a month into DV Cohort 4 due to internal technical challenges. This issue has since been resolved with the introduction of clearer internal delegation and tooling.
-
Proposal Feedback Loops: Our process for communicating with proposers was ad hoc. For DV Cohort 5, we are introducing a DAO Assistant to facilitate proactive proposer engagement and follow-up.
-
Voting Threshold Calibration: We initially relied on a fixed quorum for internal approvals. We’re recalibrating our thresholds to better account for the proportion of AYE and NAY votes relative to total participation, aiming to make decisions more responsive without compromising DAO integrity.
Our Voting Activity (DV Cohort 4)
Across DV Cohort 4, we voted on 170+ proposals (162+ on Polkadot, 33+ on Kusama as of 2nd August 2025) while voting ABSTAIN on proposals where a conflict of interest or a lack of consensus occurred.
Figure 2: Comparison of DV Cohort 4 Delegates
Here are three examples of our voting impact and rationale:
AYE Vote - Merkle Mountain Belt (Polkadot Ref 1667):
Initially rejected over ROI concerns, we shifted to support after deeper engagement, viewing MMB as a strategic investment in future-proofing Polkadot’s infrastructure.
NAY Vote - The BD Hub: Enabling Business Development Across Polkadot (Polkadot Ref 1650):
While the proposal had strong testimonials, we flagged centralization risks, lack of KPIs, and unclear coordination. We favored more decentralized, metrics-driven BD approaches aligned with Polkadot’s ethos.
AYE Vote - ParaSpell✨ XCM Tools - 12 Months of Maintenance and Server cost coverage (Polkadot Ref 1641):
We supported this proposal because it directly improved developer access to XCM, with support for cross-chain swaps, DryRunAPI, and XCM v5. We saw clear traction from Multix and Turtle and believed the SDK meaningfully lowered the barrier to cross-chain building.
How We Vote (and Why)
Our updated philosophy centers around these core ideas:
-
Ecosystem Fit Over Individual Vision:
We will continue to prioritize funding that aligns with Polkadot’s technical roadmap, community needs, and long-term sustainability, not just strong ideas in isolation. -
Measured Accountability:
We ask hard questions around metrics, adoption, cost-effectiveness, and overlap. We believe treasury requests should have clear goals, milestones, and relevance. -
Empowering Builders:
We are biased toward supporting infrastructure that reduces friction for developers, especially around interoperability (XCM), governance, tooling, and network scalability. -
Curious but Critical:
We try to engage proposers with honest feedback. Even when we vote NAY, our goal is to support proposals that come back stronger and focused, having considered previous feedback.
These principles are implemented through our detailed Standardized Proposal Evaluation Framework section and guided by our section containing the Self-Evaluation and Alignment process, which ensures our decisions remain consistent with ecosystem values and technical priorities.
Figure 2: Standardized Proposal Evaluation Framework
Conflict of Interest Policy
We have adopted a clear and proactive conflict of interest policy: If any member identifies even the slightest conflict in a proposal - personal, financial, or organizational, they recuse themselves from the vote. This standard has been applied consistently throughout our participation in DV Cohort 4, ensuring our voice reflects the network’s best interest, not private agendas.
What’s Next in DV Cohort 5
We’re applying for DV Cohort 5 with better systems, more experience, and a clear plan:
-
A new DAO Assistant role to ensure better follow-up with proposers and smoother internal ops
-
Continued transparency in vote explanations and rationale
-
Stronger alignment with the JAM roadmap, while staying supportive of ecosystem-wide tooling and initiatives.
We’re here to contribute, grow, and help the ecosystem thrive, not just as implementers, but as stewards of Polkadot and Kusama’s future.
Here is a full report covering more details (governance participation analysis, Code of conduct adherence, process improvement for cohort 5, etc.)
— JAM Implementers DAO