Clarifying Kusama's Governance Direction: Independence or Integration?

Governance
1

I’d like to raise a question about Kusama’s long-term governance structure. Recent signals point in different directions, and clarity would help the community make informed decisions about where to invest effort.

The Apparent Contradiction

Signal 1: Kusama as Independent Chain

https://kusama.subsquare.io/referenda/573, passed in August 2025, committed Kusama to an independent JAM upgrade path—32 cores, 1-second block time, a configuration tailored to Kusama’s smaller economy rather than simply mirroring Polkadot. The proposal explicitly framed Kusama as having its own trajectory.

Signal 2: Kusama Governance via Bridge

[P<>K bridge] Kusama Fellowship replaced by the Polkadot Fellowship acting over the bridge · Issue #484 · polkadot-fellows/runtimes · GitHub , opened in October 2024, proposes retiring the Kusama Technical Fellowship entirely. Under this model, the Polkadot Fellowship would govern Kusama remotely via a bridge. The most recent update (January 2025) indicates this was postponed to H2 2025, pending Kusama’s governance migration to Asset Hub.

These two directions seem to be in tension. One positions Kusama as an independent experimental network with its own technical path. The other positions it as a subsidiary governed remotely from Polkadot.

Why This Matters

Community members are actively building Kusama-specific proposals:

  • Economic differentiation (burn mechanisms vs. Polkadot’s hard cap)
  • Validator set optimization for Kusama’s scale
  • Kusama-specific runtime configurations

If Kusama’s governance is being consolidated under Polkadot, these efforts may be misallocated. Proposals that assume Kusama can chart an independent course would face a different reality—one where Kusama-specific decisions compete for attention with Polkadot priorities, reviewed by a Fellowship whose primary focus is elsewhere.

Conversely, if Kusama is meant to remain independent, the community should know that too. It affects how we engage with governance, which proposals we prioritize, and how we think about Kusama’s identity relative to Polkadot.

Questions

I’d appreciate clarity from those with visibility into the strategic direction:

  1. Is the plan in issue #484 still being pursued? The H2 2025 timeline has passed. Is this delayed, abandoned, or in progress?
  2. How does remote governance via bridge reconcile with WFC 573’s vision of Kusama-specific technical decisions? Who makes Kusama-focused tradeoffs if the Fellowship is Polkadot-centric?
  3. What is Kusama’s intended long-term identity? Is it a permanent experimental network with its own governance, or a testing ground that will eventually be governed as a Polkadot appendage?

I’m not advocating for a particular answer—I’m asking for transparency so the community can plan accordingly. Building on Kusama requires understanding what Kusama is meant to become.

Tagging those who may have context: @acatangiu (issue #484 author), @olanod (WFC 573 author), and any Parity or W3F representatives who can speak to the strategic intent.

5 Likes
2

Nine days ago, I asked three specific questions about Kusama’s governance direction and tagged those with direct visibility into the strategic intent. No one has responded.

I want to update the community on why this matters more today than when I posted.

A live example

Referendum 1836 — the PAPI team’s funding proposal on Polkadot — sat at approximately 100% approval with 14.7M DOT in support and near-zero opposition. Every comment on Subsquare is supportive. Teams across the ecosystem — Talisman, XCM tooling developers, wallet builders — endorsed it publicly.

Today, six wallets voted Nay with a combined conviction-weighted total of approximately 131M DOT, dropping approval from ~100% to ~10%.

Wallets Balance Conviction Weighted Nay
6 addresses ~43.7M DOT total All 3x ~131M DOT

For context, the entire Aye side represents ~14.7M DOT of conviction-weighted support. One entity, voting across multiple addresses, now controls nine times the voting power of the entire supporting community combined.

What this illustrates

This is not a comment on the merits of the PAPI proposal. Josep’s detailed account speaks for itself. What I want to highlight is the structural implication.

OpenGov was designed so that any token holder can submit proposals and the community decides through weighted voting. In practice, when a single entity holds enough tokens to outweigh the rest of the voting community by an order of magnitude, the system functions as a veto mechanism — regardless of when or how transparently that vote is cast.

This is the same dynamic that shaped Referendum 627 on Kusama. The specific objections differ, the timing differs, but the structural outcome is identical: community consensus overridden by concentrated voting power.

Why this connects to my original questions

If Kusama’s governance direction is being determined by an entity with this degree of influence over OpenGov outcomes — on both chains — then the questions I raised are not abstract:

  1. Is Kusama governance independent? If the same entity can override community consensus on Polkadot and Kusama simultaneously, the distinction between “independent” and “subsidiary” becomes functional rather than formal.

  2. Who makes Kusama-specific decisions? WFC 573 envisioned a Kusama that charts its own technical path. But if proposals that differentiate Kusama from Polkadot can be vetoed by an entity whose primary focus is Polkadot, the experimental mandate is constrained by that entity’s preferences.

  3. What is the point of community engagement? Teams invest months iterating proposals, gathering feedback, and building support — only to have the outcome determined by a single vote that outweighs all other participants combined. The rational response is to seek that entity’s approval in advance, which is precisely what Josep describes being required to do.

The governance question

I want to be clear: large token holders voting is not illegitimate. It is how the system was designed. The question is whether a system where one entity can routinely override broad community consensus is producing the governance outcomes the ecosystem needs.

That is a design question, not a complaint. And it deserves an answer — from the Foundation, from the Fellowship, and from the community.

The silence on my original post suggests the answer may be uncomfortable. I am still asking.

2 Likes
3

W3F just published a Kusama Vision page and an accompanying article announcing three bounties funded through Referendum 498 — W3F’s fulfillment of a genesis-era commitment to allocate 10M DOT for Kusama’s benefit. The language is unambiguous: Kusama is “evolving from a testbed into a peer network,” committed to “radical experimentation,” with “resistance built in code and freedom engineered, not requested.”

This is welcome. It answers the most important of the three questions I raised in my original post: Kusama is meant to be a permanent, independent network with its own identity. Not a subsidiary. Not a testing ground to be eventually absorbed. A peer.

That clarity matters. It validates the work already happening — validator set optimization, economic differentiation, Kusama-specific runtime decisions. Builders now have a public commitment from W3F that Kusama has a future worth building toward.

Two questions remain open.

Governance. Issue #484 — the proposal to retire the Kusama Technical Fellowship and govern Kusama remotely from Polkadot via a bridge — is still open. It was postponed to H2 2025, which has passed. If Kusama is a peer network, does it retain its own governance body? The vision says independence. The issue says integration. One of them needs updating.

Economics. The vision is funded by 10M DOT that W3F committed at genesis — a promise now being fulfilled. The bounties support ZK, Proof of Personhood, and Art — all valuable. But none of them address how Kusama sustains itself economically. Kusama currently inflates at 10% annually with zero burn mechanisms. The treasury holds ~714K KSM while relay chain fees amount to ~0.032 KSM per day. A network whose largest investment comes from an external entity’s DOT holdings isn’t economically self-sustaining — regardless of how bold the vision statement is.

This is where the vision and the economics need to meet. WFC 573 committed Kusama to an independent JAM path. The burn-based tokenomics proposal in this forum proposes reducing net inflation from 10% to ~3.1% through governance-adjustable mechanisms — giving Kusama’s monetary policy a foundation that doesn’t depend on external funding. @olanod’s validator reduction work addresses the cost side. Together, they give the “second age” an economic foundation.

The bounties fund what gets built on Kusama. The economic reforms determine whether Kusama can stand on its own. Both matter. The vision page covers the first. The second is still waiting for engagement.

4

Last week, W3F published the Kusama Vision page and a Medium article announcing three bounties. The article reads like a launch: “these three bounties are launching today and the curators are ready to accept proposals.” The website has submission forms. The language is bold — “the future of Kusama is being written by those brave enough to experiment.”

I wanted to see what was behind it, so I checked the on-chain status.

Bounty #35 (Zero-Knowledge), #36 (Proof-of-Personhood), and #37 (Art) were proposed on May 19, 2025. All three are still in Proposed status — no approval referendum, no curators, no funding capability. For reference, Bounty #32 (Shielded Kusama Hub Transfers) went from proposal to active curator in about four weeks. That’s what the process looks like when someone is driving it.

But the real issue is deeper than pace. On January 26, a W3F representative (Karam-W3F) submitted Referendum 632 — titled “Please Vote Nay” — explaining that the existing bounties pallet cannot support the multi-asset / DOT-based flow the Kusama Vision requires. The referendum states that bounties #35, #36, and #37 “are not going to be the correct on-chain mechanism for Kusama Vision going forward.” The plan is to recreate them under a new multi-asset bounties pallet that’s currently being tested on Westend.

Ref 632 was rejected on February 10 — the same week the Medium article announced the bounties were “launching today.”

To be fair, Karam was transparent about the technical limitation and posted the correction publicly. That’s how governance should work. But the sequence raises a question about the announcement itself. The Vision page and Medium article went live promoting bounties that W3F already knew couldn’t function under the current pallet. The submission forms are collecting proposals, but the on-chain mechanism that would actually fund them doesn’t exist yet. The replacement pallet is still on testnet.

None of this is fatal. The multi-asset pallet will presumably ship, new bounties will be created, and the process can start properly. But it does illustrate the pattern I’ve been pointing at throughout this thread: the announcements run ahead of the infrastructure. The vision page describes a “second age of radical experimentation.” The on-chain reality is three dead bounties, a pallet migration still in testing, and a timeline that keeps shifting.

Even once the bounties work — what’s the pitch to a builder considering Kusama? Come build privacy infrastructure, or proof-of-personhood systems, or experimental governance — on a network running 10% annual inflation with no plan to change it, whose entire relay chain fee revenue amounts to ~0.032 KSM per day, and where governance questions go unanswered for weeks. Meanwhile Polkadot just published a concrete timeline for March with dates, pallet names, and parameter changes.

I’m not saying Kusama can’t get there. The vision page articulates something worth building toward. But a vision attracts builders when it’s backed by fundamentals — working funding mechanisms, sustainable economics, responsive governance. Without those, the people with options will build elsewhere. That’s not a criticism. It’s just how it works.

This thread has been a monologue for three weeks. I don’t think I’m the only one noticing these gaps. If others see what I’m seeing, now would be a good time to say so.

2 Likes
5

Seven weeks since I opened this thread. Four posts, zero responses from anyone tagged. Meanwhile, the answer to my first question arrived — not here, but in a runtime upgrade.

PR #1100, merged on March 12, makes Kusama system chains recognize the authority of the Polkadot Technical Fellowship. It’s included in runtime v2.1.1, which hasn’t been submitted as a Kusama referendum yet. The PR description is explicit about what comes next: “Once the fellowship tooling is also upgraded and we see we can easily and reliably use the Polkadot Technical Fellowship on Kusama, we will follow-up with another change to completely remove the deprecated Kusama Technical Fellowship.”

The author is @acatangiu — the same person I tagged in my original post seven weeks ago asking whether issue #484 was still being pursued. Rather than answering, the work just moved forward.

Issue #484 has a four-step checklist: RFC, bridge governance changes, implementation on both chains, Kusama Fellowship removal. Step 1 — the RFC — was never written. They skipped straight to step 2. There was no forum discussion, no dedicated referendum on this decision. The change went through Fellowship review on GitHub and merged. That’s it. The first concrete step toward removing Kusama’s own technical governance body happened without any of the community-facing process that #484’s own checklist called for.

The PR itself is technically competent — XCM origin aliasing routes Fellowship decisions from the Polkadot Collectives parachain to Kusama over the bridge. For now, both fellowships coexist: Kusama’s own Fellowship still functions alongside the newly recognized Polkadot one. But the PR explicitly frames the Kusama Fellowship as “deprecated,” and removal is the stated next step.

One reviewer, @bkchr, raised the question of what happens when the bridge goes down — once the Kusama Fellowship is gone, there’s no fallback. He proposed syncing a Merkle root of fellowship members to Kusama daily so voting could continue via cryptographic proofs without bridge connectivity. @bkontur apparently has a working proof-of-concept. That escape hatch doesn’t exist yet, and nothing in the PR or in #484 indicates it’s a prerequisite for the next step.

W3F published a vision page calling Kusama a “peer network” committed to independence and radical experimentation. Weeks later, a PR shipped that begins consolidating Kusama’s technical governance under Polkadot — with no community discussion and no RFC. The announcements said independence. The code says integration.

I’m not questioning the Fellowship’s technical judgment on how to structure cross-chain governance. If a single Fellowship governing both networks is the right architecture, make the case publicly and let the community weigh in. What I’m questioning is the process: a governance change of this magnitude, for a network whose vision page promises independence, implemented without any of the community-facing steps that its own issue tracker said would happen first.

When v2.1.1 hits a Kusama referendum, it will be bundled with other changes. If Kusama stakeholders care about who governs their network, this is the upgrade to pay attention to.

6

What do you expect? Absolutely nothing is happening with Kusama. There’s not a single improvement to the tokenomics in sight. What happened to your improved proposal? And where the hell is @olanod proposal? We’re tired of “radical experiments.”

7

Many projects are actively adjusting their tokenomics and introducing hard caps to create long-term sustainability. Meanwhile, Kusama feels increasingly directionless, and we all know what tends to happen to token prices with unlimited supply. At times, it almost feels like the plan is simply to let it slowly fade away.

8

Personal view on Fellowship Evolution and Procedural Context

I missed the original posts, but caught the notification of the latest one I am tagged in. Sorry for the late response.

I acknowledge the Procedural Oversight

I want to address the procedural side directly: Skipping the Technical RFC and moving straight to a PR was my mistake. I own that. While the intent was to move toward a long-planned technical milestone, I recognize that I skipped the RFC phase that I myself proposed in the original plan.

Context on the “Two Fellowships”

While the procedural miss is on me, I don’t believe an RFC would have changed the “power dynamic” concerns expressed here. Here is the historical and technical context as I see it:

  • A Unified Vision: To my knowledge, the Polkadot and Kusama Technical Fellowships were never intended to be separate philosophical entities. They exist as separate on-chain collectives primarily because, at the time of their inception, we lacked a trustless P<>K bridge to allow a single on-chain fellowship to manage both networks.

  • Existing Integration: If you look at the polkadot-fellows GitHub organization, the runtimes for both Polkadot and Kusama system chains are already maintained there. They are managed by the same group of people under the same Manifesto.

  • The Bridge as a Tool: Utilizing the now-functional bridge to consolidate governance isn’t a pivot or a “takeover”; it’s the completion of the original architectural plan. Because this was always the intended “end state,” I don’t view this as a change in scope that requires a new OpenGov decision process.

Path Forward: Sovereignty via OpenGov

My view is that the current trajectory follows the established technical roadmap. However, governance is ultimately in your hands.

If the community feels that Kusama should diverge and establish a truly independent Technical Fellowship (distinct from the Polkadot Fellowship) that is a conversation for OpenGov.

  • I encourage anyone who feels strongly about this to start a Kusama WFC or a formal proposal.

  • I personally have no strong feelings on the outcome; if the community votes for a hard separation of technical governance, we can certainly work toward making that happen.

Disclaimer: The views expressed above are my personal opinions and do not necessarily reflect the voice of the Polkadot Technical Fellowship or any other organization.

1 Like
9

@acatangiu, thank you for engaging. Acknowledging the RFC skip directly is more than most would do, and I respect that.

I want to push back on one thing. You frame consolidation as the original plan and suggest that those who want independence should submit a WFC. But WFC 573 passed in August 2025. The Kusama community already voted for an independent technical path — Kusama-specific configuration, its own JAM trajectory, not a mirror of Polkadot. That’s not ancient history. It’s the most recent on-chain expression of community will on this question.

If there’s an “original plan” from the fellowship’s inception that predates that vote, the vote takes precedence. That’s what governance is. Communities evolve, and on-chain decisions supersede design-era assumptions. Integration is the deviation from the community’s expressed direction. The deviation needs the mandate — not the other way around.

You also argue that the same people already manage both chains, so nothing really changes. That’s true in practice today, and I’m not questioning the competence of the people involved. But right now, those people choose to govern both chains. Removing the Kusama Fellowship eliminates the structural ability to choose differently in the future. The daily work might look identical. The difference is whether Kusama retains the option to diverge or gives it up.

You said you have no strong feelings on the outcome and would support whatever the community decides. Then the RFC costs nothing. Write it before proceeding to removal. Let the community weigh in with full context — the bridge dependency, the fallback question @bkchr raised, the relationship to WFC 573. If the outcome is consolidation, you’ll have a mandate. If it’s independence, you’ve said you’re fine with that too. Either way, the process your own issue tracker called for actually happens this time.

@Criptoe4u, @Megadot — the burns proposal is coming back once @olanod’s validator reduction clears. But what we can propose depends on the governance structure being discussed here. If Kusama’s technical governance moves to a Polkadot-centric Fellowship, Kusama-specific economic reforms compete for attention with Polkadot priorities. The governance question comes first.

10

The technical path taken by the Kusama runtime(s) and the technical fellowship maintaining Kusama are orthogonal. Do not equate one with the other. The same unified Polkadot Technical Fellowship can serve the potentially diverging interests and potentially diverging technical paths of the two ecosystems.

Like I said, the PR you reference is not a convergence, the reality is that they were/are already converged.

The OpenGov argument onus is on diverging the two, not on simply formalizing on-chain what is already the reality off-chain.

Removing the Kusama Fellowship eliminates the structural ability to choose differently in the future.

I’ll try to make sure we go through all procedural steps, including RFC, before we do that.

The difference is whether Kusama retains the option to diverge or gives it up.

Your AI helper got this part blatantly incorrect: the control of Kusama has been and continues to remain in the hands of the Kusama OpenGov. The fellowship can only “whitelist” (accelerate) some technical proposals but cannot otherwise control the network.

Kusama OpenGov can choose to diverge/disband/restructure/etc its Technical fellowship at any time, now or in the future, with or without the help or support of the current Kusama Technical Fellowship or the current or future Polkadot Technical Fellowship.

There is by no means any one-way door here.

If Kusama’s technical governance moves to a Polkadot-centric Fellowship, Kusama-specific economic reforms compete for attention with Polkadot priorities. The governance question comes first.

Maybe, but the status-quo is no different. The Polkadot Technical Fellowship is funded by the Polkadot treasury, the Kusama Technical Fellowship has no funding. The “competing for attention” argument is no different between the reality today. To fix that, the two fellowships have to diverge and be separately funded so there is no “competing for attention”. As said before, this is a serious consideration that can only be evaluated in Kusama OpenGov.

Then the RFC costs nothing. Write it before proceeding to removal.

The AI is again missing subtle context. The RFC costs time and money. The Polkadot Technical Fellowship would vote on the RFC so the RFC brings nothing in practice.

I can ask you to do the same:

A Kusama OpenGov WFC costs you nothing. Write it if you are concerned about the on-chain acknowledgement of the Kusama and Polkadot Fellowships acting as one.

1 Like
11

I’ve submitted Referendum 640 on the Wish For Change track. It establishes one requirement: any change that removes, merges, or eliminates the Kusama Technical Fellowship as an independent on-chain collective needs a dedicated Kusama vote before implementation.

It does not oppose consolidation, does not seek to reverse PR #1100, and does not claim the change is irreversible. @acatangiu, your corrections were useful — you’re right that OpenGov is sovereign and this isn’t a one-way door. The WFC just makes the consent explicit rather than assumed.

On the AI point from earlier: yes, I use AI tools. The arguments are mine, the mistakes are mine. If there’s an error in reasoning, point to the reasoning — not the tooling.

1 Like
12

Thanks for raising this and keeping the accountability bar high! :+1:t2:

1 Like