Polkassembly Logo

Create Pencil IconCreate
OpenGov

Notice: Polkadot has migrated to AssetHub. Balances, data, referenda, and other on-chain activity has moved to AssetHub.Learn more

View All Wish For Change

Kusama JAM Upgrade: Option A - Lightweight and independent

inWish For Change
5 months ago
Executed

Supporting this proposal means you agree that, Kusama implements an independent JAM upgrade with a lightweight, non-standard configuration designed for its economic constraints.

Like Polkadot did with ref#682, it's time for Kusama to take a stance towards JAM. The problem is, the costs of running a full JAM instance are too high for Kusama's small economy, so we either run a smaller instance(optimized for new use cases with 1sec finality) or hope for Polkadot to agree to share the same instance to split the cost between the 2 economies(Opt.B)

Configuration

  • 32 cores (vs. Polkadot's 341)
  • 1-second block time for very low latency
  • KSM as native token for all economic functions (storage, staking, coretime)

Economics

With a greatly reduced core count and validator set the network can lower its security costs dramatically(~2.4% KSM inflation worst case), other mechanisms like Proof of Personhood can be consider to reduce further costs and make it manageable for Kusama's low cap economy.

Trade-offs

Benefits:

  • Fast finality is great for real-time applications
  • Cost-effective and economically sustainable
  • Maintains full independence

Limitations:

  • Lower throughput than full JAM
  • Reduced internal data transfer capacity

Strategic Value

  • Preserves Kusama's experimental nature in JAM era
  • Creates unique positioning on latency/throughput spectrum
  • Establishes Kusama as the platform for latency-sensitive applications

Comments (4)

5 months ago

Having a low latency JAM with a small number of fully utilized cores to develop CoreChains, CoreVM and Coreplay fully for a year, with JAM validators built by JAM Implementers makes a lot of sense!

5 months ago

Having a low latency JAM with a small number of fully utilized cores to develop CoreChains, CoreVM and Coreplay fully for a year, with JAM validators built by JAM Implementers makes a lot of sense! Having JAM experimentalists work on Kusama embodies the "Expect Chaos" spirit Kusama was famous for, and I would love it JAM community had a new home instead of Kusama being "just" a canary. This plan gives the canary-ists and the JAM community a nice compromise - without it feeling like a pointless competition between Polkadot and Kusama. I would advocate renaming the chain to seal the deal for actually being a JAM-first home, but we should nail down the Toaster => Kusama path down to protocol specs.

Load more comments
PleaseLogin to comment

Proposal Passed

Help Center

Report an Issue
Feedback
Terms and Conditions
Github

Our Services

Docs
Terms of Website
Privacy Policy

A House of Commons Initiative.

Polka Labs Private Limited 2026

All rights reserved.

Terms and ConditionsTerms of Website
Privacy Policy