JAM: What It Is, How It Works, and What It Means for Polkadot

JAM is a protocol for building a decentralised computer from many machines, designed to combine two properties that distributed systems have traditionally struggled to provide at the same time: large amounts of parallel computation and a shared environment in which different services can interact directly.

Parity is developing an implementation of JAM, one of several JAM implementations, as the next major step in Polkadot's underlying technology. The intended transition would move parachain finality from the current Relay Chain architecture to a service running on JAM, while preserving continuity for existing parachains.

The transition will happen through a staged engineering program: introducing Offchain Messaging, implementing parachain consensus as a service on top of JAM, and delivering the JAM node implementation required to support that architecture. Importantly, while preparation is staged, the eventual transition is expected to culminate in a hard fork. 

But JAM itself is broader than that transition.

Its architecture provides a more general computing model in which substantial work can run in parallel and the correctness of that execution can be verified through JAM's global consensus. This means JAM is not limited to blockchains, smart contracts, or even state-machine-based apps; ordinary programs and services can use the same decentralised computing infrastructure. 

A useful analogy, and perhaps an easier way to understand this, is a conventional computer: JAM's cores behave like CPU cores, JAM coordinates them like an operating system, data availability provides something closer to shared memory, and work packages provide the data each core needs to execute.

Why JAM is being developed

One fundamental challenge in computer architecture is that increasing a system's size usually makes coordination harder, and the same problem appears in blockchains. Ethereum demonstrated the power of a shared execution environment. Smart contracts operate against a common state and can interact directly with one another. This creates a highly coherent system where applications can be composed from one another.

Maintaining that coherence, however, limits how much computation can run at the same time. Polkadot has approached the problem differently. Instead of placing all computation inside one state machine, Polkadot distributes work across multiple independent state machines: parachains. Each parachain advances its own state while the Relay Chain provides shared security, coordination, and finality.

That architecture lets computation run in parallel.

The trade-off is that parachains remain separate execution environments. Communication between them is asynchronous. A contract running in one environment cannot simply call a contract in another and wait synchronously for the result.

JAM is designed around a different balance, retaining the ability to do large amounts of work in parallel while bringing results into a shared environment where services can inspect state and interact more directly. This relationship between scale and coherence is central to JAM.

From blockchains to a decentralised computer

JAM is better understood as a distributed computer than as another blockchain. Its cores provide parallel processing capacity, while the protocol coordinates execution and verifies the resulting work through consensus.

This means software running on JAM does not need to resemble a blockchain at all. A service can run general-purpose code, use distributed computational resources, and produce results the network can verify. Blockchain-style systems, smart-contract environments, and Polkadot parachains are possible uses of that infrastructure, but they are not its limits.

One could provide a smart-contract environment. Another could expose an entirely different programming model. Polkadot's existing parachain model can itself be represented through a service running on JAM. The important distinction is that JAM provides the underlying computing infrastructure rather than prescribing everything that must run on top of it.

How JAM works

At a high level, JAM separates computation into two stages: refinement and accumulation.

The first lets large amounts of work run in parallel, while the second brings the results into JAM's shared consensus state; this split is central to the architecture.

Refinement

Work reaches JAM's cores as work packages containing one or more work items. Each core processes its assigned work package independently, allowing many packages to be refined in parallel. The current JAM architecture defines 341 cores that can process work simultaneously. The result is condensed into a work report, which is then checked and accumulated into JAM's shared state.

Accumulation

In the accumulation phase, JAM brings together the results produced during refinement and operates against JAM's shared state.

This is where parallel computation results can alter a service's state, balances can be transferred, and services can interact with other services. JAM therefore does not attempt to make every computation globally synchronous.

Instead, it allows much of the computational work to happen independently and in parallel, then brings the resulting state changes into a common environment.

In simplified form: Work → Parallel refinement → Work reports → Accumulation → Shared state

This separation lets JAM scale computation while maintaining stronger coherence between services.

What makes JAM secure? 

One vital part of JAM is that it doesn't require every validator to execute every piece of computation. In simple terms, not everyone does all the work, but enough independent checks exist to make incorrect work extremely hard to pass as valid. That is really essential to scalability because if every validator had to repeat all work performed across every core, the system would quickly be limited by what a single validator can do.

Instead, JAM builds on the security model developed for Polkadot's execution sharding, where under normal conditions, subsets of validators execute and check work assigned to individual cores and attest that the resulting work report is correct and that the data is available. Clearly, the network shouldn't simply trust that initial subset, so additional validators can independently check the work, and if conflicting judgments or a dispute emerge, the validation process escalates and, in critical cases, the broader validator set can become involved.

This family of mechanisms is known as ELVES, and it allows computation to be distributed across cores without making each workload's security depend only on the small group that first executed it. 

Services: the software that runs on JAM

The basic programmable unit in JAM is a service.

A service contains code, storage, and a balance. Developers can deploy services and use JAM's computing resources to run them; in this regard, a JAM service is similar to an Ethereum smart contract, but with a broader execution model.

A service has two entry points: refine and accumulate. Refinement performs work on a core; accumulation determines how the verified result affects shared state. These services can inspect other services' state and interact through the common environment JAM provides, enabling stronger synchronous composability without requiring all computation to run sequentially inside one execution environment.

The Polkadot Virtual Machine

Code inside JAM services runs using the Polkadot Virtual Machine, or PVM.

The PVM is based on a simple RISC architecture. Like the Ethereum Virtual Machine, it provides a common execution target for programmable logic. The PVM, however, is a simpler general-purpose machine rather than a blockchain-specific instruction set with complex cryptographic operations.

This gives JAM a common machine architecture on which different kinds of services and execution environments can run.

Coretime: access to JAM's computing resources

Computation is a finite resource, and JAM uses Coretime to represent access to its processing capacity. Building on Polkadot's Agile Coretime model, work packages require Coretime to use JAM's cores, allowing JAM to allocate computational resources independently of the applications or services that consume them.

This separates the underlying computing resource from the software that runs on top of it.

An authorisation system determines how allocated Coretime may be used and which workloads may consume it, while the deeper mechanics involve authorizers and other parts of the JAM protocol; the high-level model is straightforward: JAM provides computational capacity, and services consume that capacity to perform work.

Coretime can be thought of as an execution slice. In a conventional operating system, a process gets access to a CPU core for a period before the OS moves on. JAM applies a similar concept: Coretime gives work access to a core for a defined execution period.

What JAM Means for Polkadot

JAM is being developed as the infrastructure for an intended transition in Polkadot's architecture. Today, the Relay Chain performs several roles within Polkadot, including parachain finality and cross-chain coordination. The intended future architecture moves parachain consensus into a service running on JAM, while JAM provides the underlying consensus and finality guarantees the Relay Chain currently supplies.

For Polkadot, the significance goes beyond replacing one piece of infrastructure with another. JAM extends the original Web3 ambition: building shared computing infrastructure that is not owned or controlled by a small number of technology companies.

That matters in a world where a handful of centralised platforms control more of the internet's computation, storage, and application infrastructure. JAM attempts to push in the opposite direction: toward a globally distributed, cryptographically verified computer that can support large-scale computation while remaining open, permissionless, and collectively secured.

For Polkadot, that means preserving the parachain model while getting access to a more general computing architecture with greater parallelism, shared state and stronger composability between services.

In practical terms, the aim is to keep what already works in Polkadot while moving closer to the broader Web3 vision: infrastructure that can support serious computation without depending on centralised providers. Technically, we're approaching that transition in stages.

1. Reducing messaging dependence on the Relay Chain

The first area is Offchain Messaging, the messaging protocol being developed for JAM.

Rather than routing parachain communication through the Relay Chain, Offchain Messaging lets messages move directly between participants while preserving the guarantees the wider system needs.

The aim is to make messaging fit the JAM architecture so it's less dependent on the Relay Chain, better suited to a more distributed execution model, and able to support communication between services as the network transitions.

2. Running parachains through a service on JAM

The second step is the Parachain Service, which shows that existing parachains can keep operating while a service on JAM provides finality, rather than the current Relay Chain architecture. The current public implementation is a proof of concept, and moving it to production readiness requires further implementation, integration, ecosystem testing, security work, and audits.

PolkaJAM

PolkaJAM supports this work as the JAM node implementation required for this intended architecture. Together, these workstreams connect development on today's Polkadot with the longer-term JAM architecture. They should therefore be understood as parts of the same transition program, not unrelated upgrades.

A staged transition culminating in a hard fork

The work leading to JAM is being delivered in stages, with individual components developed, tested and integrated before the network is ready to transition. That preparation is expected to culminate in a hard fork, providing a clear point at which Polkadot moves from the current architecture to the JAM-based model.

Reaching that point will depend on evidence across implementation, testing, security, ecosystem readiness, and known risks. Before parachain teams, validators, or other ecosystem participants need to act, updates will outline affected versions, migration requirements, test environments, deadlines, support channels, and current readiness.

This means individual components can make substantial progress long before the network itself is ready to switch. The hard fork is the transition point; the work before it proves the system is ready.

A different approach to composability

Beyond the Polkadot transition, one of JAM's most significant architectural goals is stronger synchronous composability because in systems composed of separate blockchains, communication between environments usually involves sending a message and waiting for another system to process it, but JAM lets services in the same shared environment interact more directly.

Services can inspect other services' state and execute interactions against a common view of that state. This does not mean every operation in JAM occurs synchronously, but much of JAM's scalability comes precisely from allowing refinement work to happen independently and in parallel. The architecture separates work that benefits from parallel execution from interactions that require shared state.

More than a replacement for the Relay Chain

The intended Polkadot transition is one application of JAM, but it doesn't define the system's limits, since JAM is designed as a general-purpose decentralised computing environment. Services can contain arbitrary code and use JAM's computational resources, so the system isn't limited to blockchain applications, smart contracts, or any single execution model.

Polkadot-style parachains could run on JAM, but so could entirely different kinds of software, services, and computational workloads. Some may resemble blockchains; others may not, which changes the abstraction considerably. Instead of designing the protocol around a particular kind of blockchain, JAM provides shared decentralised computation on top of which many different systems can be built.

The scale and coherence problem

The architectural argument behind JAM ultimately reduces to one question: How much can a decentralised system grow without making its parts increasingly isolated from one another?

Ethereum demonstrated the advantages of strong coherence, and Polkadot showed how parallelisation can expand the computation available to a decentralised network, so JAM draws on ideas from both.

Its cores provide parallel computation, while its shared state provides a common environment where the results can interact. Services provide the programmable layer, and the PVM provides a common machine on which their code can execute. The Parachain Service gives Polkadot's existing architecture a path to use that infrastructure without requiring the existing parachain model to disappear.

Together, we think these components describe something broader than another blockchain architecture. It describes a decentralised computing environment designed to scale while preserving the ability of its software to work together.

Where JAM stands today

JAM and the wider Polkadot transition remain active engineering work.

The public Parachain Service implementation is currently a proof of concept. Offchain Messaging is under active development as the messaging protocol for the JAM-based architecture. The broader transition still requires implementation, integration, benchmarking, ecosystem testing, security review, and audit work before it can be production-ready.

There is therefore an important distinction between demonstrating that an architecture works and establishing that it is ready to carry an existing network and future updates will continue to document progress against those milestones.

Going deeper into JAM

JAM contains considerably more machinery than one overview can cover, and its architecture includes mechanisms for allocating and authorising Coretime, validating work across its cores, producing blocks, selecting validators, and making computation available to services.

Concepts such as Safrole, authorizers, work-reports, and in-core consensus form part of the JAM protocol, while services such as CorePlay demonstrate what can be built on top of it.

JAM is designed to run many different kinds of computation in parallel while keeping them connected through shared state. In practice, that could support services such as applications, smart-contract environments, identity systems, messaging, data processing, and other forms of decentralised computation on the same underlying network.

For Polkadot, the work underway is to prove that this architecture can become the foundation beneath the network that already exists. Follow the Parity blog and the monthly Polkadot forum updates for the latest.

Watch Gavin Wood's Keynote on JAM at Web3 Summit 2026.