Decentralized Voices Cohort 5: JAM Implementers DAO

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:

  1. 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.

  2. Measured Accountability:
    We ask hard questions around metrics, adoption, cost-effectiveness, and overlap. We believe treasury requests should have clear goals, milestones, and relevance.

  3. Empowering Builders:
    We are biased toward supporting infrastructure that reduces friction for developers, especially around interoperability (XCM), governance, tooling, and network scalability.

  4. 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

4 Likes

Good that they’ve shared their learnings from the previous cohort. I’d like to share my personal views and experience with JAM Implementers DAO.

Firstly, there’s a noticeable gap in how their decision-making is handled transparently. They state: 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. but even this shows there isn’t a definitive number and it’s only a range of 11–15

They’ve also mentioned: “We vote together, discuss proposals, and aim to reflect a shared view across the Polkadot ecosystem.” but I’m not sure how, where, or when this happens. The feedback we received from them often felt vague, with statements like “some of the members felt this and that” without clear reasoning even after we fixed and agreed upon their obligations.

I couldn’t see a proper structure in place. There is a public discussion thread on their Discord, but I’ve only seen a few threads (for certain proposals). I’m not sure if other threads are private or just not created. If they’re not created, then I’m curious how evaluation is happening and how the team communicates with proposers. I’ve also noticed some calls arranged with certain proposers but I don’t know what the process is for arranging those(lmk if I have missed reading this info).

In practice, it’s mostly one representative, Luke, posting questions and responses. I feel he’s doing his best to respond to every thread at the earliest. But in some threads I’ve seen questions go unanswered by proposers, and yet JAM still votes Aye. It leaves me wondering where those explanations were provided and why that’s not happening publicly.

This is purely based on what we went through. In our case, they initially asked us 13 questions, which we happily answered. We also made every change they requested. Yet, JAM gave a negative feedback on us, including a very wrong allegation posted publicly, which turned out to be due to a misunderstanding and misinterpretation of details on their side, something their representative later agreed they hadn’t looked at properly. I think that’s a huge lapse in responsibility for a DV, given the importance of their role and the weight their decisions carry. You can see this in their Discord chat Public discussions under #1637. Discord

We also heard from them that they ‘must abstain from voting when many people didn’t have time to vote because they were busy.’ This again left me disappointed why take on the responsibility if you’re not ready to commit or follow through?

Personally, I believe that irrespective of whether a DV votes positive or negative, what matters is their reasoning, commitment, transparency, and responsibility. And in our experience, JAM DAO fell short on these fronts.

1 Like

Hey Megha. Let me try to clarify:

Regrading JAM implementer team participant not being definitive: That’s because it started out with 15 or so members but some dropped off because of little or no engagement. The team reps who have little or no participation either request to be removed from participation or are removed instantly on notice. At the time of this post, 11 representative were active in the voting process. Other JAM Implementer teams can always participate in the future.

No clear reasoning on your Ref? You would agree that’s arguable.

Regarding public discussion thread: Obviously public. Proposers or the DAO members can create a public discussion for any ref - Both happen. You would notice proposers make request for call or a public discussion in the public room. Communication between proposers and JAM DAO happen in both the public room or discussion threads.

Representative: Yes, Luke responds to the Discussion threads with questions raised in our internal discussion, on behalf of the DAO. But in the public room, there are other few members who communicate with the proposers too. Sometimes, question that aren’t answered on the discussion thread were probably answered somewhere else such as proposer’s response to comments on their ref page, public room or maybe they aren’t questions that the JAM DAO’s vote was absolutely stringent on. This is most likely the cases. Also, kindly note that members read the discussion in the public threads and room, and considers them during their evaluation.

On checking the Ref 1637 convo: Probably the longest discussion thread we have had with a proposer and I believe members appreciated the adjustment that the proposer made based on concerns presented. However, it appears the initial feedback shared from JAM Implementers DAO wasn’t exhaustive, other concerns were raised later in the discussion thread. Luke shared why the members maintained their vote in the public discussion even after you guys tried clarifying the later concerns too. The collective decision remained.

I hope this cleared, at least, most of your concerns.

Is there anyway I can Talk to this Jam implementers DAO? I have a proposal I would like to discuss with you.

thanks in advanced

Jose Rabasso

Ref 1752