Kusama in the JAM Era: A Response to the Proposal for a Future on JAM Prime
A first-principles response on Kusama’s long-term role
Introduction
There are already several serious discussions about the future of Kusama in the JAM era, including the proposal for a future on JAM Prime.
That proposal raises important questions about whether Kusama should operate on a shared JAM-based infrastructure, how resources and security might be allocated, and what relationship should exist between Kusama, Polkadot and JAM Prime.
I do not see this as a separate proposal that should be considered in isolation.
Rather, I see it as part of a broader conversation about what Kusama is meant to become in the JAM era.
Before deciding whether Kusama should run on JAM Prime, operate an independent JAM instance, or adopt some hybrid architecture, I think we should first clarify the underlying question:
What is Kusama actually for in a JAM-based ecosystem?
If we answer that question first, the infrastructure question becomes much easier to reason about.
My hypothesis is that Kusama could evolve from a “Canary Network” into something more fundamental:
an independent economic, governance and Agency domain operating on top of a common JAM computational substrate.
In other words:
JAM could become the common computational substrate.
Polkadot could become a production-oriented institutional domain.
Kusama could become a digital frontier where new forms of organization, governance, economics and autonomous Agency can emerge under real economic conditions.
I am not proposing this as a predetermined outcome, nor am I asking the community to immediately adopt a specific implementation of JAM Prime or any other architecture.
I am proposing it as a framework for evaluating the different options currently being discussed.
The question is not simply whether Kusama can technically run on JAM Prime.
The deeper question is whether a shared JAM substrate can preserve the economic, political and experimental independence that would give Kusama a meaningful long-term role.
There is also a philosophical question underneath this discussion.
What kind of order should a complex digital society seek?
Should it aim for one universal system that imposes the same rules, timing and institutional assumptions everywhere?
Or should it allow multiple forms of order to emerge, provided that they can still communicate and coordinate when necessary?
My intuition is that the second model is more promising.
A healthy digital ecosystem may need both stability and experimentation, both institutional memory and the freedom to explore, both shared foundations and independent forms of life.
This is not an argument for disorder.
It is an argument for a different understanding of order: not uniformity, but the ability of distinct entities to remain coherent while participating in a larger system.
Start from first principles: autonomy and coherence
A complex system that is expected to grow indefinitely faces a fundamental tension.
It needs both autonomy and coherence.
Too much global coherence creates coordination costs, rigidity and dependence on a single global ordering mechanism.
Too little coherence produces fragmentation and makes higher-order composition difficult.
This is not specific to blockchains.
It is a general problem of complex systems.
A useful principle is therefore:
Local autonomy + sufficient coherence = scalable organization.
The important question is not:
“How do we make everything globally synchronized?”
The more fundamental question is:
“Where is strong coherence actually necessary?”
If two entities have a strong causal relationship, strong coherence may be necessary.
If two entities are weakly related, asynchronous interaction may be sufficient.
If two entities have no meaningful causal relationship, forcing them into the same synchronization domain may simply create unnecessary coordination costs.
This leads to what I would call:
Selective Coherence, or Nested Coherence.
Instead of one enormous coherence domain, we can have multiple coherence domains that maintain their own internal consistency while interacting through defined interfaces.
This is important because future digital systems may not consist of millions of passive accounts.
They may consist of increasingly autonomous entities.
There is a philosophical implication here.
Coherence does not necessarily mean that everything must be identical or centrally ordered.
A living system is coherent not because every part is the same, but because different parts maintain relationships that preserve the integrity of the whole.
In that sense, autonomy is not the opposite of order.
Autonomy can be one of the conditions that makes higher-order order possible.
From accounts to Agency
The future computational economy may contain:
Individuals.
Companies.
AI agents.
Machines.
DAOs.
Communities.
Services.
Markets.
Organizations.
Higher-order organizations.
I use the word “Agency” here deliberately.
As a conceptual model:
Agency = Identity + Authority + Capability + Responsibility + State
This is not intended to be a formal protocol definition.
It is a way to describe the type of entities that future computational infrastructure may need to support.
An autonomous AI agent, for example, may require:
Persistent state.
An identity.
Authority over resources.
Delegated authority.
Economic balances.
Capabilities.
Relationships with other entities.
Responsibilities.
Reputation.
The ability to create or participate in higher-order organizations.
Once this becomes possible, the fundamental problem is no longer simply transaction processing.
It becomes:
How can autonomous entities form increasingly complex relationships while maintaining enough coherence for those relationships to remain meaningful?
This is what I mean by Nested Agency.
A person can participate in an organization.
An organization can participate in a DAO.
A DAO can participate in a market.
An AI agent can act on behalf of a person.
An organization can delegate authority to another organization.
Multiple organizations can form a higher-order organization.
The system becomes recursive.
Agency creates relationships.
Relationships create organizations.
Organizations create higher-order Agency.
Higher-order Agency creates new relationships.
And the process continues.
What kind of substrate does Nested Agency require?
If this reasoning is correct, the underlying computational substrate needs more than transaction ordering.
At minimum, it needs:
Persistent state
General computation
Permissionless creation of computational entities
Programmable authority and resource control
Native communication between entities
Asynchronous interaction
Parallel execution where causal dependencies do not exist
Verifiable state transitions
Resource allocation
Economic settlement and feedback
Sufficient coherence for causally related state
The ability to compose these primitives recursively
An important distinction follows.
The underlying substrate does not need to understand every social relationship.
It does not need to know what “employment”, “friendship”, “membership”, “ownership”, “delegation” or “responsibility” means.
Those are higher-level semantics.
The substrate needs to provide primitives that allow such relationships to be represented and enforced.
This gives us two different layers:
Relationship substrate.
Relationship semantics.
The substrate provides the capabilities.
The higher layer gives those capabilities meaning.
This is why JAM should not itself be expected to define the complete concept of Agency.
Why JAM and JAM Prime are interesting
This is where JAM, and potentially JAM Prime, become particularly interesting.
The reasoning should not be:
“JAM Prime is being proposed for Kusama, therefore JAM Prime must be the architecture implied by these principles.”
It should be the opposite:
First derive the required substrate.
Then examine the available architectures, including JAM Prime.
Then ask which architecture best satisfies the requirements while preserving the intended autonomy of each domain.
From this perspective, JAM has an unusual combination of properties.
JAM provides a general computational environment with persistent services, resource-based execution, asynchronous interaction, parallel computation and mechanisms for verifying state transitions.
Services can be permissionlessly deployed.
Computation can be separated into different execution phases, with stateful accumulation where necessary.
Core-time provides a native resource-allocation mechanism for computation.
The architecture does not require every computation to be forced into one monolithic synchronous execution path.
This is highly relevant to Selective Coherence.
The interesting property is therefore not simply performance.
It is the architectural combination:
shared state and coherence + distributed computation + parallel execution + asynchronous interaction + resource allocation + verifiable transitions.
The JAM Gray Paper describes the system as a “mostly-coherent trustless supercomputer.”
That concept is particularly interesting from the first-principles perspective.
The objective is not necessarily maximal global synchronization.
It is sufficient coherence combined with scalable distributed computation.
That is much closer to the underlying problem we are trying to solve.
The proposal for a future on JAM Prime is therefore interesting not merely because it may offer a technically efficient path for Kusama.
It is interesting because it raises the possibility that Kusama could share a computational substrate while retaining a distinct economic and governance identity.
But that possibility should not be assumed.
It needs to be demonstrated through explicit guarantees around authority, resource allocation, security, failure isolation and exit.
JAM is a substrate, not an Agency system
However, an important distinction should be maintained.
JAM is not itself a complete Agency architecture.
Its native computational abstraction is the service.
It does not need to define:
What an individual is.
What an organization is.
What responsibility means.
How reputation works.
How delegation should work.
What constitutes an AI agent.
How identities should relate to one another.
What a higher-order organization means.
Those are higher-layer semantics.
This may actually be a strength.
A sufficiently general substrate should be strongly opinionated about the things that must be coherent at the infrastructure level, while remaining relatively unopinionated about higher-level social and economic structures.
This suggests a layered architecture:
Layer 0: JAM
State.
Computation.
Resource allocation.
Communication.
Verification.
Coherence.
Layer 1: Agency semantics
Identity.
Authority.
Relationships.
Delegation.
Responsibility.
Reputation.
Organization.
Layer 2: Higher-order Agency
DAOs.
AI-agent organizations.
Autonomous markets.
Machine organizations.
Human/AI organizations.
Cross-domain organizations.
What does this imply for Kusama?
This is where I think the JAM transition, and the discussion around JAM Prime, create a fundamental opportunity.
If JAM becomes a sufficiently general computational substrate, then the long-term distinction between Polkadot and Kusama does not necessarily need to be based primarily on different underlying infrastructure.
Instead, they could become different coherence and economic domains built on a common substrate.
Polkadot could be a production-oriented domain.
Kusama could be an experimentation-oriented domain.
The distinction would therefore not simply be:
Polkadot = stable.
Kusama = unstable.
It would be deeper:
Polkadot = institutional core.
Kusama = digital frontier.
The proposal for a future on JAM Prime could be one possible infrastructure expression of this distinction.
But the infrastructure choice should serve the domain distinction, not replace it.
The frontier analogy
There is a historical analogy that I find useful here.
After the formation of the United States, the established states and the expanding frontier played very different roles.
The frontier was not merely a “testnet” for the established states.
It was a place where new communities, businesses, institutions, economic arrangements and forms of governance emerged under real conditions.
The frontier was valuable precisely because its institutional structure was not yet fully settled.
I think this provides a useful analogy for Kusama.
Kusama should not necessarily be thought of as:
“Polkadot, but experimental.”
A more interesting model is:
Polkadot = institutional core.
Kusama = digital frontier.
This does not mean Kusama should become chaotic or ungoverned.
It means that Kusama could provide an environment where new forms of digital organization are allowed to emerge before their long-term institutional form is known.
The important difference is:
A testnet tests technology.
A frontier tests institutions.
That is a much broader experiment.
What could a Kusama digital frontier experiment?
If Kusama were treated as a digital frontier, the experiments could include:
New governance structures.
New economic mechanisms.
New DAO structures.
AI-agent economies.
Machine-to-machine markets.
New reputation systems.
Programmable delegation.
New identity models.
Privacy-preserving organizations.
New forms of digital property.
New resource-allocation mechanisms.
Autonomous organizations.
Human/AI organizations.
New forms of cooperative ownership.
New forms of organizational accountability.
The important point is that Kusama would not merely test whether a technical feature works.
It could test whether a new form of digital organization can survive under real economic conditions.
That is a qualitatively different role.
Why the frontier needs to remain meaningfully independent
A frontier only has value if it has meaningful room to evolve.
If Kusama is simply another deployment environment for the same governance assumptions, incentives and institutional structures as Polkadot, the distinction becomes mostly cosmetic.
At the same time, completely duplicating the underlying infrastructure may be unnecessarily expensive.
This creates a very interesting architectural question:
Can infrastructure be shared without sovereignty being shared?
I believe this question deserves much more attention in the JAM era, especially when evaluating JAM Prime.
Shared infrastructure does not necessarily imply:
Shared governance.
Shared economic policy.
Shared risk tolerance.
Shared identity.
Shared Agency semantics.
Shared political authority.
The substrate can be shared while the domains remain distinct.
That is exactly the kind of structure predicted by Nested Coherence.
Shared infrastructure does not mean shared sovereignty
Consider a simple architecture:
JAM provides the common computational substrate.
Polkadot maintains its own governance and economic domain.
Kusama maintains its own governance and economic domain.
Applications, organizations and Agents exist within these domains.
The lower layer can be shared.
The higher layers can remain autonomous.
This creates a hierarchy:
JAM coherence.
Polkadot domain coherence.
Kusama domain coherence.
Organization coherence.
Agency coherence.
The important question becomes:
Which decisions belong to JAM?
Which decisions belong to Polkadot?
Which decisions belong to Kusama?
Which decisions belong to individual Agencies?
This separation of authority may be more fundamental than the question of how many cores Kusama receives, or whether Kusama should be implemented as a particular JAM Prime configuration.
For the JAM Prime proposal to support genuine Kusama sovereignty, the following questions would need clear answers:
Can Kusama control its own governance and economic parameters?
Can Kusama determine how its allocated resources are used?
Can Kusama reject changes to higher-level semantics that it does not accept?
Can Kusama isolate itself from failures in other domains?
Can Kusama exit the shared substrate with its state and assets intact?
Can Kusama maintain a distinct security and risk profile?
Without credible answers to these questions, “shared substrate + independent domain” may remain only a conceptual distinction.
Kusama could become an experiment for JAM itself
There is another possibility that I find particularly interesting.
Kusama could become not only an experimental network built on JAM.
It could become an experiment in JAM’s own multi-domain architecture.
Suppose JAM can support multiple economically and politically distinct domains.
Then Kusama could become a real-world demonstration that:
One computational substrate can support multiple autonomous communities.
This would test a much deeper hypothesis:
Can decentralized infrastructure become shared infrastructure without forcing every community into the same economic and political system?
That is a fundamental question for the future of Web3.
In this sense, the JAM Prime proposal may be more than a migration or deployment proposal.
It could be a constitutional experiment in how shared infrastructure and independent sovereignty can coexist.
But that experiment should be evaluated not only by technical feasibility or cost efficiency.
It should also be evaluated by whether Kusama retains meaningful agency over its own future.
The economic question
There is also a practical economic reason to think about this architecture.
A sovereign network has to justify its infrastructure cost.
If Kusama maintains a completely independent security and infrastructure stack, that infrastructure must ultimately be justified by the economic value generated by the Kusama ecosystem.
If a common computational substrate can instead be shared across multiple domains, some infrastructure costs could potentially be amortized across the ecosystem.
This does not imply that Kusama should abandon sovereignty.
It means that we should distinguish:
Infrastructure sovereignty
from
Economic sovereignty
and
Political/governance sovereignty.
They are not necessarily the same thing.
A future architecture could potentially provide:
Shared infrastructure.
Independent economic domain.
Independent governance.
Independent experimentation.
That may allow multiple communities to share expensive underlying infrastructure without forcing them to become the same community.
However, shared infrastructure also creates possible dependencies.
For example:
Who determines the cost of resources?
Who can change the resource-allocation mechanism?
Who bears the cost of congestion?
Who decides how security is funded?
Can one domain subsidize or extract value from another?
What happens if the economic assumptions of Polkadot and Kusama diverge?
These questions are central to evaluating whether JAM Prime would strengthen or weaken Kusama’s long-term economic sovereignty.
What should Kusama optimize for?
If this framework is correct, Kusama should not primarily optimize for being:
A smaller Polkadot.
Or:
A cheaper Polkadot.
Its differentiation should come from the kinds of systems that are allowed to emerge.
One possible way to think about this is:
How much organizational and economic experimentation can occur per unit of infrastructure?
Kusama could deliberately allow:
Higher experimentation frequency.
More experimental governance.
More unconventional economic mechanisms.
More unconventional organizations.
More autonomous agents.
More radical coordination mechanisms.
More privacy experiments.
More AI-agent experiments.
More unusual forms of digital ownership and delegation.
This does not mean that Kusama is “better” than Polkadot.
It means that it serves a different function.
Polkadot can provide an environment optimized for production-grade institutions.
Kusama can provide an environment optimized for exploration of the design space.
If Kusama is placed on JAM Prime, the relevant question should therefore not be only whether it can run there.
It should be whether JAM Prime enables more experimentation, autonomy and institutional differentiation than the alternatives.
From Canary Network to Digital Frontier
This suggests a possible evolution of Kusama’s identity.
Phase 1:
Kusama as a Canary Network.
Its primary role is to expose new Polkadot technologies and governance mechanisms to real economic conditions.
Phase 2:
Kusama as an independent experimental network.
It develops its own economic and governance identity.
Phase 3:
Kusama as a digital frontier on JAM.
It becomes a place where new forms of digital organization, Agency and economic coordination can emerge.
The important transition is therefore:
Testing new technology
to
Testing new institutions.
That is a much larger design space.
The JAM Prime discussion may represent an opportunity to make this transition explicit rather than treating Kusama merely as a network that needs a new technical home.
A possible long-term architecture
The architecture I have in mind is conceptually simple.
JAM would be the common computational substrate.
Polkadot would be a production-oriented economic and governance domain.
Kusama would be an experimental economic and governance domain.
Above both would exist organizations, DAOs, AI agents and higher-order Agencies.
Potentially, other domains could emerge in the same way.
The architecture would therefore look conceptually like this:
JAM
├── Polkadot
│ ├── Organizations
│ ├── DAOs
│ ├── Agents
│ └── Higher-order Agency
│
├── Kusama
│ ├── Organizations
│ ├── DAOs
│ ├── Agents
│ └── Higher-order Agency
│
└── Other Domains
├── Organizations
├── DAOs
├── Agents
└── Higher-order Agency
At that point, Kusama would no longer be merely a Canary Network.
It would be one autonomous domain among potentially many domains sharing a common computational substrate.
JAM Prime could potentially serve as the infrastructure through which this architecture is realized.
But the key design requirement would remain:
Kusama must be a domain, not merely a tenant.
This changes the question “Why does Kusama exist?”
Under the traditional model, the answer is:
Kusama exists because Polkadot needs a Canary Network.
Under the JAM-era model, a stronger architectural answer could be:
Kusama exists because a growing digital ecosystem needs a frontier.
The institutional core and the frontier perform different functions.
The institutional core preserves established production systems.
The frontier explores unknown organizational possibilities.
The core provides continuity.
The frontier provides variation.
The core provides coherence.
The frontier provides experimentation.
This is very close to the broader principle of:
Order + Flux.
A complex system needs both.
Too much order produces rigidity.
Too much flux produces fragmentation.
A growing system needs a structure in which experimentation can occur without destroying the coherence of the larger system.
Kusama could potentially play exactly this role.
The deeper connection to Agency
This is where I think the JAM/Kusama architecture becomes particularly interesting.
If the future Web3 economy is increasingly composed of autonomous economic entities, then we will eventually need infrastructure for:
Individuals.
Agents.
Organizations.
Markets.
Higher-order organizations.
These entities will need to create relationships recursively.
That means the system must support:
Agency.
Relationship.
Organization.
Higher-order Agency.
And these structures will need different degrees of coherence.
A small AI agent may need local autonomy.
An organization may need internal coherence.
A DAO may need another level of coherence.
A Kusama domain may need another.
A Polkadot domain may need another.
JAM may provide the underlying computational coherence.
This gives us a recursive architecture:
Agency
→ Organization
→ Domain
→ JAM
and:
JAM
→ Domain
→ Organization
→ Agency.
This is Nested Coherence expressed as an actual system architecture.
The most important unresolved questions
If this direction is worth exploring, I think the community should focus on several concrete questions, including those raised by the proposal for a future on JAM Prime.
A. Sovereignty
What exactly remains under KSM governance if Kusama uses shared JAM infrastructure?
B. Authority boundaries
Which decisions can JAM make?
Which decisions belong exclusively to Kusama?
Can Kusama reject changes to higher-level infrastructure?
C. Economic independence
How does KSM retain meaningful economic utility if infrastructure is shared?
D. Resource allocation
How should JAM resources be allocated between Polkadot, Kusama and potentially other domains?
Who controls the allocation mechanism, and can Kusama protect its access to resources over time?
E. Security
Which security guarantees are shared?
Which risks remain domain-specific?
F. Failure isolation
If one domain experiences a catastrophic economic or governance failure, how isolated is another domain?
G. Exit
Can a domain leave the shared substrate?
What happens to its state, assets and organizations?
H. Experimental freedom
What kinds of experiments should Kusama explicitly encourage that Polkadot should not?
I. Agency
Can Kusama become an economically real environment for experimenting with AI-agent organizations, DAOs and autonomous economic entities?
J. Long-term differentiation
What would make an application, organization or Agency choose Kusama rather than Polkadot?
K. Constitutional guarantees
What guarantees would need to be encoded in the architecture or governance process so that Kusama’s independence does not depend solely on goodwill from other participants?
This last question is critical.
Infrastructure alone does not create a reason for a community to exist.
Kusama needs a distinctive economic and organizational function.
My proposed framing
I would therefore suggest that we stop thinking about the JAM transition primarily as:
“How should Kusama migrate?”
or:
“Should Kusama use JAM Prime?”
Instead, we should ask:
“What should Kusama become once the underlying computational substrate is no longer the primary differentiator?”
My current hypothesis is:
Kusama could become an independent, high-experimentation economic, governance and Agency domain on top of JAM.
Its purpose would be to explore the design space of digital organizations, autonomous agents, governance, economics and new forms of coordination under real economic conditions.
Polkadot could provide a more production-oriented institutional environment.
JAM could provide the common computational substrate.
JAM Prime could potentially provide one implementation path for hosting or coordinating these domains.
Kusama could provide the digital frontier.
This creates a three-layer architecture:
JAM
= common computational substrate
Polkadot
= production-oriented institutional domain
Kusama
= experimental digital frontier
The important point is that JAM Prime should be judged by whether it can support this architecture, not merely by whether it can host Kusama technically.
This is not a proposal to simply merge Kusama into Polkadot
In fact, the argument is almost the opposite.
If Kusama’s purpose is to provide meaningful institutional experimentation, eliminating its independent identity could remove much of the value of having the frontier in the first place.
At the same time, completely duplicating infrastructure may be unnecessary if JAM can safely support multiple domains.
Therefore the interesting design space is not simply:
Complete independence
versus
Complete merger.
There is a third possibility:
Shared substrate + independent domain.
That is the architecture I think deserves deeper technical and constitutional investigation.
The proposal for a future on JAM Prime may be pointing toward this third possibility.
The question is whether the proposed architecture provides enough separation between the shared substrate and Kusama’s domain-level sovereignty.
If it does, JAM Prime could become an important foundation for Kusama’s next phase.
If it does not, then the community should be careful not to confuse infrastructure sharing with genuine independence.
Final hypothesis
There is a broader reason why I find this direction important.
If the future of Web3 is ultimately about autonomous economic entities rather than merely decentralized databases, then the infrastructure problem changes.
We will need systems that allow:
Individuals → Agents → Organizations → Markets → Higher-order Organizations
to form recursively.
This requires autonomy.
But recursive organization also requires coherence.
Therefore the architecture of the future may not be:
One global state machine containing everything.
It may instead be:
A hierarchy of coherence domains sharing a common computational substrate.
If this hypothesis is correct, Kusama could become more than a historical Canary Network.
It could become one of the first real-world laboratories for this architecture.
Not a smaller Polkadot.
Not simply a testnet.
Not merely a cheaper deployment environment.
But an economically real digital frontier where new forms of organization are allowed to emerge.
JAM may provide the substrate.
Polkadot may provide the institutional core.
Kusama may provide the frontier.
JAM Prime may be one possible way to connect these layers.
And the deeper experiment would be whether multiple autonomous communities can share computational infrastructure without giving up their ability to organize themselves differently.
That, to me, is a much more fundamental question for the JAM era than simply asking where Kusama should run.
I would be very interested in hearing where this model, or the JAM Prime proposal, is technically or constitutionally wrong.
In particular:
Which parts of this architecture cannot actually be implemented on JAM or JAM Prime?
Where would shared JAM infrastructure necessarily create shared governance?
What minimum guarantees are required for genuine Kusama sovereignty over a shared substrate?
What would make Kusama economically valuable as a distinct digital frontier?
What kinds of Agency, AI-agent economies, governance systems or organizational experiments would make sense specifically on Kusama?
How should resources, security and failure isolation be allocated between Polkadot, Kusama and other domains?
Could Kusama become a real-world test of JAM’s ability to support multiple autonomous coherence domains?
What specific guarantees would distinguish a sovereign Kusama domain on JAM Prime from a merely dependent deployment environment?
I think these questions may be more fundamental than choosing between “mini-JAM”, “full JAM”, “JAM Prime”, or “no JAM” in isolation.