# Proposal discussion: Adapting Kusama to demand and its JAM future

**URL:** <https://forum.polkadot.network/t/proposal-discussion-adapting-kusama-to-demand-and-its-jam-future/17141>\
**Category:** Ecosystem\
**Tags:** kusama\
**Created:** [February 18, 2026, 5:12pm UTC](https://forum.polkadot.network/t/proposal-discussion-adapting-kusama-to-demand-and-its-jam-future/17141 "2026-02-18T17:12:17Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![Lederstrumpf](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/lederstrumpf/32/1530_2.png) [@Lederstrumpf](https://forum.polkadot.network/u/Lederstrumpf)\
**Post date:** [November 2, 2026, 9:56am UTC](https://forum.polkadot.network/t/proposal-discussion-adapting-kusama-to-demand-and-its-jam-future/17141/10 "2026-11-02T09:56:06Z")

</div>

Hi all,

The 1000⇒700 reduction worked without a hitch, as was likely since it didn’t touch number of cores at all.  
Further reductions require more careful planning.  
Others may have stricter or looser requirements for this, but in my mind, the two key aspects to consider are:

1. _Can we reduce further without materially affecting decentralization of the network?_
2. _Can we reduce further without constraining actual current coretime usage, and ideally also leave some margin for growth?_

To proceed with further reductions, I’ve analyzed the impact of the reduction on decentralization metrics, as well as assessing core utilization with historic data going back to 2021 (pre-coretime).

- Decentralization report: [hambro.ch/kusama/set-reductions/decentralization/](https://www.hambro.ch/kusama/set-reductions/decentralization/)
- Coretime report: [hambro.ch/kusama/set-reductions/coretime/](https://www.hambro.ch/kusama/set-reductions/coretime/)

_(Disclaimer: given the scale of this data analysis, most of the grunt work was facilitated by vigorous massages of the American LLM duopoly, and it still ate weeks)_

I’ll create a separate forum thread for these reports [LINK TO FOLLOW SHORTLY]:  
My intent here is to keep said thread focused on methodology discussion (“what it is?”, “where is it correct/wrong?”), whereas this thread here is in my mind the better place for discussing how to proceed with further reductions (“what to do about it?”)

A TLDR of my key findings:

## A. decentralization

To even begin investing this question, I applied some clustering heuristics to identify validators that don’t share onchain identity, but with high likelihood are controlled by the same operator. See the bottom HUD of the report for an explanation of the three clustering levels used - I suggest using the highest clustering level L2 (with the caveat that some of these additionally identified operators vs L1 are clustered by strictly shared nominator sets, and therefore not necessarily pointing towards operator centralization, strictly only nominator concentration).

_If we measure decentralization by “how many operators back this system”, then of course decentralization will increase at a certain point, unless the only nodes evicted are from the largest operators._

_The more appropriate question though is how the relative composition of the network changes as the number of validators decrease._

So rather than bucketing by the number of nodes held per operator, the operators were bucketed by their relative share of the network in three categories:

1. `<1%` share of network held by a given operator (if desired the bottom HUD also allows segregating out the singleton seat operators),
2. `1-5%` share of network held by a given operator, and
3. `>5%` share of network held by a given operator

**My main finding here is that the relative composition of the network doesn’t change materially for any chosen clustering level (L0-L2):**  
Modulo crossovers in the singleton/\<1% categories (if singletons are shown), it stays almost flat as the validator set decreases, across all steps from 700 down to hypothetical 250 (see [figure B3 (bottom)](https://www.hambro.ch/kusama/set-reductions/decentralization/#fig-B3)).

Some other pleasant findings, if the validator set is reduced further:

1. The top 3, top 10, and top 30 operators by seats stay flat in relative share of the seats (see [figure B3 (top)](https://www.hambro.ch/kusama/set-reductions/decentralization/#fig-B3))
2. The gini coefficient drops as the range of operator sizes compresses (see [figure B5](https://www.hambro.ch/kusama/set-reductions/decentralization/#fig-B5)).
3. The “cheapest third” of the network (by backing stake) shifts materially higher (from aggregate 2.13M KSM to 2.62M KSM), since the minimum backing stake shifts much closer to the mean backing stake.

## B. coretime

The data here was gathered for pre-coretime activation (November ’21) and post-coretime activation (May ’24). Polkadot data can be toggled on too as reference data.

Accounting for the cores allocated / bought up only, we might reasonably expect requiring 100 cores or more on Kusama within the next year.  
Looking at the cores actually producing though paints a different picture:

By producing, I mean a core that was actually producing a block within the sampling window on a given day.  
Producing peaked at 60 cores on 04.12.2024, during the Spammening.

So while cuts below 100 cores might affect dormant tenants that don’t actually produce any blocks, the active tenants should not feel a reduction down to 60 cores, perhaps even 50 cores.

## C. what to do about it?

At least my personal decentralization concerns have been assuaged (I feared worse), and there is also ample room to reduce: the highest tally of producing cores Kusama has seen to date was 60 cores during the Spammening, and highest observed peak at 48 cores thereafter. And within the last year, even the assigned cores stayed below 60.

**Based on the above findings, I suggest the following schedule for further reductions:**

1. A reduction to 500 validators (100 cores) first
2. A reduction to 300 validators (60 cores) scheduled 4 weeks later

While there’s potential room to reduce the validator set further, the data whispers to me that 300 is a good conservative compromise (it might whisper other things in your ears).

My goal is to wrap up this discussion within the next two weeks (~17 November), and to then submit a ref if this path finds support here.

Happy to receive input & critical fresh eyes on my analysis!

---

_[View the full topic](https://forum.polkadot.network/t/proposal-discussion-adapting-kusama-to-demand-and-its-jam-future/17141)._