Hello,
This topic is intended to be complementary to the Kusama set reduction discussion in Proposal discussion: Adapting Kusama to demand and its JAM future - #10 by Lederstrumpf.
My intent is that the discussion there remains focused on strategy, and this one on methodology. But since flaws in / potential improvements to methodology inform strategy, I welcome critical feedback on the findings of the following two reports:
- The decentralization report: hambro.ch/kusama/set-reductions/decentralization/
- The coretime report: hambro.ch/kusama/set-reductions/coretime/
I suggest reading the strategy post on the reduction thread first to grok the intent, before delving into the reports - they’re already fairly verbose just from data explainers, so I’ve not stitched them into a flowing bedtime essay.
Decentralization report
The goal of the decentralization report is to identify how decentralization metrics changed with the last/first reduction (section A), to gauge how further reductions would impact decentralization (section B).
Two key decisions this begs for:
- How do we define decentralization?
- How do we reliably identify validator clusters - a lot of these stashes lacking onchain identity - that share the same operator massaging them?
For the decentralization question, I broadly ascribe to a combination of
- “number of operators I have to whack with a wrench or bribe with cash$ to break BFT” (Nakamoto coefficient, see A2), and
- “power distribution from smallest to largest operators by seat count” (Gini coefficient, see B5, and distribution of operator size classes, see A4, B2, and B3)
To keep the operator size question scale-free, in the default view of the report, the bands are by relative share of available seats (<1%, 1-5%, and >5% of seats), but you can also toggle the hud to see how singleton validators (operators with only one active seat) fare, or to change to absolute size bands (1 / 2-5 / 6-25 / 26+ nodes) - just note that the latter gives a rosy view of the decentralization impact (since the larger classes all but disappear under this view for low set sizes).
For the operator identification question, there are a couple of heuristics one can use to link them with their validators, ranging from obvious ones like identity and shared payee accounts or proxy keys, up to more far reaching ones like closed nominator sets backing the same group of validators.
To give the reader a choice, the clustering heuristic degree can be selected in the HUD from L0 (conservative), L1 (pragmatic), and L2 (staking cabals), where the assumptions applied are subsets L0 ⊂ L1 ⊂ L2.
I could have gone further with more invasive methods, but the coverage is already at 90.4% for L1 and 98.1% for L2, and readily supported by onchain data.
As noted in Proposal discussion: Adapting Kusama to demand and its JAM future - #10 by Lederstrumpf, I was pleasantly surprised to see the relative composition of operator sizes not negatively impacted by the last set reduction & therefore also further ones.
I will note though that the Gini coefficient improving (B5), i.e. the system getting more equal should be read with a pinch of salt - the largest players (see B3) roughly retain their relative share of the seats. The Gini coefficient dropping (or equivalently Lorenz curve moving closer to equality) does indicate that equality is improving, but this is in large part an artifact of integer value seats: if we scaled all seats down the same and permitted fractional ones, Gini coefficient wouldn’t budge. But since we “compress” the range of operator sizes, the gap between the smallest and largest must shrink, and so must inequality. This would only change if larger operators managed to cling onto more of their seat share than the small ones, Gini would have worsened, and luckily this hasn’t happened.
Coretime report
To identify an upper bound the number of cores required to support current Kusama demands, I focused on the cores that are actually producing blocks, rather than the envelope of all cores assigned.
I define a producing core as one that had a block included within the 24-hour period under consideration.
This definition could of course be tightened / investigated in more detail by considering block weight usage and discounting empty or sparsely filled blocks, but it’s sufficient for identifying an upper bound on the number of cores used.
The massive surplus of cores that were assigned but not producing on Kusama from ~Nov’24 to ~Oct’25 (around 2-3 fold of producing cores) was almost exclusively due to the Spammening, placeholder paras, and the coretime negotiation purchases (see 3.1’s “Unused by holder” toggle for a breakdown into the paras ). Since then, the surplus has progressively tightened, and now the surplus of assigned+not-producing is around 10-20%.
Except for the Spammening in Nov/Dec’24 and its rerun in Mar’25, the highest number of cores active a day on Kusama was 47 in Mar’26 with comparable monthly mean (43.2). For comparison, Polkadot’s peaks since the Spammening were 57 in Mar’26 and Jun’25, again with comparable monthly means (46.9 & 49.8).
On-demand cores are sadly super-underutilized on Kusama, 98% of it coming from a Kreivo flurry in Mar/Apr’26.
The Aside sections of the report can safely be skipped. Section 3.2 also breaks down Polkadot’s utilisation by producing & idle cores - similar narrative as for Kusama.
Thanks to Dario’s & Sam’s microstartups for all of the data scraping & frontend lipstick, but especially thanks to @florentina57, @alfonso, @michalis, Kuba, and @burdges for fruitful discussions and suggestions on earlier versions of these reports!
Mistakes and methodology flaws are solely mine; if someone wants to reproduce the data, please ping and I’ll extract the applicable scripts - just note scraping might take a few days unless reducing sampling range & size from the full coverage used here.
Finally: please let me know if anything is unclear or you have criticism / improvement suggestions for methodology. I have more plots that might answer questions not covered by the reports; the reports are a selection of what I consider most illuminating.