Proposal discussion: Adapting Kusama to demand and its JAM future

olanod
Wed, 18 Feb 2026 17:12:17 +0000
Ecosystem

Last year when I asked the Kusama community about what should our take be on JAM, whether we should try to share home with Polkadot’s JAM deployment or be “lightweight and independent”, the community agreed on the later option, a great choice IMO! Kusama has been underutilized for many years as a glorified testnet, but there’s a strong desire to realize its full potential as an independent hub for innovation and the leading edge of Web3 and the cypherpunk movement, a spirit well aligned with W3F’s Kusama Vision.

The main highlight of the wish for change is that Kusama infrastructure would need to be reduced to 32 cores(along with the number of validators), an estimation of the size required for a JAM chain to produce faster 1 second block times and an opportunity to bring new use cases to the ecosystem like real-time applications.

JAM is still under development and the reduction wouldn’t be needed for some time, however I see an opportunity to propose this reduction earlier and in a phased way, not only to prepare for what’s next to come but as a response to the market conditions and to the reality that there is virtually zero coretime demand in the ecosystem, we need to scale down, validators can’t pay their bills and there is no point in sustaining a huge infrastructure that no one(but the Virto team?) is using.

A gradual reduction

Suddenly cropping the supply of cores and “firing” most validators can bring a lot of unnecessary friction. I propose a gradual reduction over the course of 6 months to go from our current setup of 1000 validator(700 para-validators) and 140 cores arriving to a final setup of 24 cores backed by 5 para-validators for a grand total of 120 validators. Later when we prove there is demand for more than 24 cores we can always scale back up to 32 cores and even more if the technology allows it.

The referendum would be a single root proposal with a batch that schedules the following adjustments:

First set validators on the staking system to match 700 para-validators.

1 month later: set cores to 120, validators to 600

2 months later: set cores to 100, validators to 500

3 months later: set cores to 80, validators to 400

4 months later: set cores to 60, validators to 300

5 months later: set cores to 40, validators to 200

6 months later: set cores to 24, validators to 120

Next steps and thoughts

I was initially planning to propose this reduction since last year without asking much questions but I believe taking time to get feedback from different affected parties was the better approach, now taking even longer than I should have as I was busy(and lazy) to do run the necessary tests, but the time has come! I would like to hear thoughts from the community before submitting this referendum, there might still be topics to consider but the necessary calls are pretty much figured out.

I’m also curious to hear ideas about what comes next for validators, this change will reduce decentralization and could concentrate operations in the hands of a few big players like centralized exchanges… On-chain decentralized nodes program anyone?.

7 posts - 5 participants