Kusama's new governance coordinator asks what the network is actually for
Victoria Shinder2 min readLuuu, newly appointed Kusama Governance Coordinator with responsibility for the Kusama Vision Programme, has opened a direction-setting thread on the Polkadot Forum. The starting point is that referendum #498 already settled the constitutional question - Kusama is an experiment-focused peer of Polkadot - and left the practical ones open: where Kusama should run, how many resources it needs, and who should provide its security.
A possible migration to JAM sits behind all of it. The post is candid that the Vision bounties, delayed by technical problems, only became fully operational recently and have just funded their first projects - which is offered as a reason to set the programme's focus now rather than later.
The proposed identity is explicit: an experimental network for digital freedom, privacy and creative work - cypherpunk values. Testing new JAM applications in real conditions is included, but with a caveat worth quoting in spirit: that should support the wider purpose rather than become the only purpose. And the programme itself would be time-boxed to two years, a starting point for early experiments and pilots, with anything that proves useful going on to the treasury or other funding through separate processes.
What it means
The two-year cap is the most interesting governance choice here, because ecosystem programmes almost never propose their own expiry. A funding vehicle with no end date acquires constituents, and constituents make it very hard to conclude that the experiment finished. Writing the sunset into the design at the start is the cheapest moment to do it - and it changes what applicants build, because a pilot that must graduate to the treasury on its own merits is a different proposal from one that expects renewal.
The security question is the one with real consequences. "Who provides Kusama's security" is not a housekeeping matter for a network defined as the place where you run things that might break; a canary chain that is cheap to attack is not a useful test environment, and one secured exactly like Polkadot is not cheaper to experiment on. That trade-off has no obvious answer, which is presumably why it is in a forum post rather than a proposal.
Worth reading the caveat about JAM applications as the signal it is. The temptation for a canary network is to become the staging environment for its parent's roadmap, which is useful to the parent and gradually erases the canary's own reason to exist. Naming that risk before the JAM migration, rather than after, is the substantive part of this post.