# The Road to JAM **URL:** \ **Category:** Tech Talk\ **Created:** [September 10, 2026, 2:17pm UTC](https://forum.polkadot.network/t/the-road-to-jam/18621 "2026-09-10T14:17:47Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![joyce](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/joyce/32/1730_2.png) [@joyce](https://forum.polkadot.network/u/joyce)\ **Post date:** [September 10, 2026, 2:17pm UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/1 "2026-09-10T14:17:47Z")
Dear community, As we’re approaching the switchover of Parachains finality to a JAM service, we want to share with you the coming technical updates of the four underlying projects: 1. Launching JAM in production (project: PolkaJAM), 2. reducing the Relay Chain functionality to only validation of Parachain execution (projects: Minimal Relay aka AHM v2, and Offchain Messaging), and 3. launching and switching over to the new JAM based finality service (project: Parachain Service). Some of these might require an upgrade on your side, which we will communicate and provide guides in a timely manner. Herewith, the project deliverables in more detail: 1. **PolkaJAM:** 2. **Minimal Relay (AHM v2):** 3. **Offchain Messaging:** 4. **Parachain Service:** Related work: 1. **JAM** : As we move forward with the project, we will keep you informed in this thread. Please make sure to subscribe to get notified. In the following months we will share here support channels, guides and other relevant information for the transition to JAM run as smoothly as possible. Best, Parity Technologies ---
**Author:** ![ultracoconut](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/ultracoconut/32/5932_2.png) [@ultracoconut](https://forum.polkadot.network/u/ultracoconut)\ **Post date:** [September 11, 2026, 2:34pm UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/2 "2026-09-11T14:34:10Z")
Perfect, but the community should demand that what I call the PNE (Polkadot Network Engine), in this case JAM, be easily replaceable — meaning that it should not require a hard fork or other complex processes. Let me explain: although JAM may seem revolutionary right now, with advances in technology and hardware, I would say it will probably become obsolete in 8–10 years, once ZK technology becomes practical and usable. I’ve done some research, and with a theoretical ZK-based design, it would be possible to have 1,000 cores for 1,000 validators, along with other advantages. Therefore, for Polkadot to remain competitive in the future, we need to place strong emphasis on this. Polkadot must not be optimized for a specific technology but rather for its capacity to mutate. ---
**Author:** ![bkchr](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/bkchr/32/27_2.png) [@bkchr](https://forum.polkadot.network/u/bkchr)\ **Post date:** [September 11, 2026, 7:43pm UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/3 "2026-09-11T19:43:24Z")
> [@ultracoconut](#): > > in this case JAM, be easily replaceable — meaning that it should not require a hard fork or other complex processes. This is not really possible. > [@ultracoconut](#): > > Let me explain: although JAM may seem revolutionary right now, with advances in technology and hardware, I would say it will probably become obsolete in 8–10 years, once ZK technology becomes practical and usable. You could easily achieve this with JAM, by putting all the proofs into work packages. And yeah for sure, zk will improve, but will the proving ever be real time? Hard to imagine, but let’s see. ---
**Author:** ![ultracoconut](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/ultracoconut/32/5932_2.png) [@ultracoconut](https://forum.polkadot.network/u/ultracoconut)\ **Post date:** [September 11, 2026, 9:27pm UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/4 "2026-09-11T21:27:46Z")
Basti, the problem with doubting ‘real-time proving’ is that you are evaluating the future based on today’s hardware and algorithms. ---
**Author:** ![bkchr](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/bkchr/32/27_2.png) [@bkchr](https://forum.polkadot.network/u/bkchr)\ **Post date:** [September 11, 2026, 9:57pm UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/5 "2026-09-11T21:57:44Z")
We will see what the future will bring 🙂 But JAM will not prevent anything in the future. ---
**Author:** ![olanod](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/olanod/32/804_2.png) [@olanod](https://forum.polkadot.network/u/olanod)\ **Post date:** [September 14, 2026, 7:40am UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/6 "2026-09-14T07:40:15Z")
ZK and JAM are not mutually exclusive, as Basti mentions you can have proofs in the work packages, then a service’s code becomes mostly the proofs verification, processing messages and not a lot more. To give an example, I’m prototyping such a system, not because I think JAM needs zk-rollups to scale but because I still see organizations/communities(decentralized or not) as the main users of decentralized infrastructure(we are B2B), and they need/want **privacy** , that’s why they keep building web2 backends and won’t make the jump to use decentralized technology. There will be huge advantages for organizations to be able to cooperate in a trustless way, but it will take time for them to realize that, so in the meantime I want to meet them in a middle ground, provide an easy to deploy and use backend, an “OS” that in the age of AI pretty much can write its own services for the organization, use PVM off-chain for those private services but also allow parts of them to be “attestatable”, i.e. prove the execution of PVM code on a ZK VM that a JAM service can verify. Those mini private zk-rollups don’t need an ever growing chain of blocks with a byzantine fault tolerant consensus, simpler raft that many databases use works well, anyway most small parachains have a very centralized collator set, still there should be a path for _progressive decentralization_ if the organization ever needs to switch consensus. ---
**Author:** ![bkchr](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/bkchr/32/27_2.png) [@bkchr](https://forum.polkadot.network/u/bkchr)\ **Post date:** [September 14, 2026, 9:03am UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/7 "2026-09-14T09:03:28Z")
> [@olanod](#): > > Those mini private zk-rollups don’t need an ever growing chain of blocks with a byzantine fault tolerant consensus, simpler raft that many databases use works well, anyway most small parachains have a very centralized collator set, still there should be a path for _progressive decentralization_ if the organization ever needs to switch consensus. A collator/workpackage producer can be basically anyone. In the beginning we also had this consensus which allowed anyone to build blocks. This is working, it just introduces more forks etc. But if you don’t have that much traffic and your demand to commit to the global consensus is just driven by certain actions, you can probably run completely without any consensus for committing to JAM. In the end it all depends on the use case and how you build this. 🙂 ---
**Author:** ![ultracoconut](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/ultracoconut/32/5932_2.png) [@ultracoconut](https://forum.polkadot.network/u/ultracoconut)\ **Post date:** [September 14, 2026, 11:44am UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/8 "2026-09-14T11:44:36Z")
The 1000 validators/1000 cores I mentioned can’t be achieved with JAM, but with a new protocol based purely on ZK. Ethereum is also researching a solution based on ZK, so if Polkadot stays on JAM forever, it will become obsolete compared to Ethereum in a decade. So the PNEs in Polkadot should be interchangeable, like Game Boy game cartridges, to make an analogy. ---
**Author:** ![bkchr](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/bkchr/32/27_2.png) [@bkchr](https://forum.polkadot.network/u/bkchr)\ **Post date:** [September 15, 2026, 1:19pm UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/9 "2026-09-15T13:19:19Z")
> [@ultracoconut](#): > > The 1000 validators/1000 cores I mentioned can’t be achieved with JAM, but with a new protocol based purely on ZK. > > Ethereum is also researching a solution based on ZK, so if Polkadot stays on JAM forever, it will become obsolete compared to Ethereum in a decade. If you include 3 zk proofs into each JAM core, you end up with the 1000 cores you are talking about. I’m not sure why you are saying that this is not possible. ---
**Author:** ![ultracoconut](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/ultracoconut/32/5932_2.png) [@ultracoconut](https://forum.polkadot.network/u/ultracoconut)\ **Post date:** [September 15, 2026, 2:25pm UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/10 "2026-09-15T14:25:07Z")
How many validators does JAM need per core? On the other hand, regarding what you’re talking about 3 ZK proofs, it’s not JAM; there’s nothing that says that, nor is it in their specifications. Furthermore, 3 proofs/core ≠ 3 core ---
**Author:** ![burdges](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/burdges/32/172_2.png) [@burdges](https://forum.polkadot.network/u/burdges)\ **Post date:** [September 21, 2026, 8:11pm UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/11 "2026-09-21T20:11:48Z")
In theory, JAM has the same validator vs cores relationship as Polkadot, since the sharding protocol ELVES has only minor changes. We’d an in-depth parameter discussion here: > > > \# Existing \`relayVrfModuloSamples\` don't make too much sense > > Current approval… related values on Polkadot: > \`\`\` > noShowSlots: 2 > nDelayTranches: 89 > zerothDelayTrancheWidth: 0 > neededApprovals: 30 > relayVrfModuloSamples: 40 > \`\`\` > > relayVrfModuloSamples should be way less. With 200 valdiators and 40 parachains it should be around 6. > > \# Existing parameters don't make too much sense > > What is a good number for \`relayVrfModuloSamples\` depends on the number of validators and parachains. This parameter would need to be adjusted on any change in those numbers. It would be better to make \`relayVrfModuloSamples\` a function of those parameters and a different paramer to fine tune this relationship. > > \# Further tuning > > For our threat model it should be sufficient to have around 30 approvals in expectation. Therefore it might be sensible to reduce the number of \`neededApprovals\` a bit to avoid higher tranches kicking in too often to cover for variation. This might be helping in reducing load on approval voting. Other strategies like increasing the tick value should be done first though. > > \# Tasks > > \- \[x\] Pass motion on Kusama and Polkadot to reduce \`relayVrfModuloSamples\` to something more sensible. > \- \[\] Make sure whenever we are increasing \`maxValidators\` or the number of cores we also adjust \`relayVrfModuloSamples\` accordingly. > \- \[\] Make the second task obsolete by replacing \`relayVrfModuloSamples\` config with a tuning knob and derive the actual value based on that and the number of validators and parachains/cores. > > @Sophia-Gold > @burdges - expected variance would be interesting. > @sandreim Intuitively, it should be roughly `num_validators * relayVrfModuloSamples = E * num_cores` The ELVES paper worked out `E=25` but we picked `E=30` based upon earlier simulation work, and just retained it for extra security margin. Also `relayVrfModuloSamples` is defined by validator specs and the protocol, so it increases somewhat in JAM. We’d naively expect every core costs like three validators based upon this, but we’ve a gap between theory and practice.. We’ve done spamening runs with many cores, but not 1/3rd of the validator set. I’ve forgotten the spamening numbers, but they were done on Kusama with its low spec validators and rampant spec cheating. It’s likely there are many protocol inefficiencies too, not only Kusama having weak validators. JAM adopting QUIC should help here eventually, but it’ll take multiple JAM iterations to realise those gains. Anyways if you ask validators to be 10x more powerful and have more bandwidth, and you somehow enforced this, then we could probably run 1000 cores on 1000 validators on Polkadot today. We do not do that because we want private individuals to run validators, not just institutions, and we want validators in many jurisdictions, some of which have worse bandwidth. Zero-knowledge could mean many things. It’s clear private transactions implemented by zero-knowledge have become an overall priority. You are seemingly discussing “zk roll ups” in the Ethereum sense, which incidentally only use SNARKs without the zero-knowledge part, and provide no real privacy. There were many advances in the proof systems of course, but true zk roll ups always have extremely expensive prover time. We’d one major ethereum zk roll up making blocks of 180 tx for more than $20 in Amazon EC2 CPU time. At 6 seconds, that costs $288k per day, or $105 million per year in CPU time, and that’s only 30 tps for the whole zk roll up. Also, they incurred 10s of minutes in cross chain latency waiting for proofs, but later work should’ve improved parallelisation. Amazon EC2 is expensive, but you need redundant provers for liveness, and you need to pay those node operators well, so Amazon EC2 costs make a sane baseline. In other words, if each of 1000 Polkadot validators earns $100k per year then all of Polkadot consts roughly what a single low tps zk roll up costs. After fixing many inefficiencies, this could realistically manage 1 million tps or more. You could pay considerably less or demand much beefier hardware and network too. Around this, true zk roll ups spend heavily on hardware opportunity costs and hosting, which leave their ecosystem, while our costs are predominantly validator and collator salaries, so more chance those payments stay within the ecosystem. I do think zk roll ups could’ve cheaper bandwdith costs than parachains or services, but if they have liveness then the bandwidth costs cannot really beat us by that much, again assuming some optimisations on our side. As SNARKs improved, there exist better non-private SNARK tricks for parachains or JAM services than for Ethereum: If we find a cheap enough storage SNARK, then we could do only the storage proofs in the SNARK, which partially removes the zk roll up bandwidth advantage, but keep the signature verification transparent and batched. We’ve no idea if SNARK have reached the point where this becomes economically viable yet, because doing experiments with altered storage remains complex on polkadot. In summary, true zk roll ups shall always cost many orders of magnitude more than polkadot cores. If zk roll ups ever catch up, then we can copy only the fastest parts of their proofs that cost us bandwidth, but then do native EC MSMs that still massively beats them. Polkadot has never had scalability problems. That’s what we do much much better than anyone else. ---
**Author:** ![ultracoconut](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/ultracoconut/32/5932_2.png) [@ultracoconut](https://forum.polkadot.network/u/ultracoconut)\ **Post date:** [September 21, 2026, 9:18pm UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/12 "2026-09-21T21:18:51Z")
The proofs would obviously be generated off-chain using GPUs or ZK-ASICs, not CPUs. But anyway, I think we’re talking about different things. For the protocol I have in mind, the validator requirements would be minimal, and existing validator hardware would be sufficient. ---
**Author:** ![burdges](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/burdges/32/172_2.png) [@burdges](https://forum.polkadot.network/u/burdges)\ **Post date:** [September 22, 2026, 12:15am UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/13 "2026-09-22T00:15:48Z")
I’m quoted the off-chain costs there. Amazon EC2 is off-chain obviously. The off-chain costs and prover latency are the limiting factors for zk roll ups, well multiplied by the redundancy required by liveness. Yes, GPUs speed up some proof systems, but not enough to be cost competitive with polkadot. CPU and GPU time both cost money. These “zk roll ups” use non-interactive proof systems. Polkadot’s ELVES protocol _is_ also a proof system, but an interactive one that invokes heavier assumptions than zk roll ups. As I said above, Polkadot can open up non-interactive proof techniques, apply what’s useful, and skip what’s costly, or rearrange them to exploit interactivity differently, because we have a much more powerful interactive verifier model that goes way beyond smart contracts. Ergo, Polkadot tx should always be orders of magnitude cheaper than similar zk roll up tx. The price we pay is optics: They can criticise our heavier assumptions. Our assumptions are similar to what everyone assumes in their consensus though. Also, I largely ignored latency above, but afaik the fastest deployed SNARKs are Stwo and Barretenberg. Stwo benchmarks focus upon specific primitives, so maybe useful for storage, but less useful for a general purposes. Barretenberg needs more than 1 second of prover time for a single ECDSA signature on a 32 CPU machine, far slower on normal hardware. 1 second is very fast, but not fast enough if you want 1000s of tx in a block every 6 seconds. ---
**Author:** ![ultracoconut](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/ultracoconut/32/5932_2.png) [@ultracoconut](https://forum.polkadot.network/u/ultracoconut)\ **Post date:** [September 22, 2026, 12:09pm UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/14 "2026-09-22T12:09:13Z")
If you read my comments, what I was criticizing was the rigidity that the JAM protocol could impose on Polkadot, potentially making it harder to accommodate future upgrades involving new technologies. Everything I said about a protocol based on these kinds of technologies was referring to a ten-year horizon, not tomorrow. ---
**Author:** ![computeflux2026isgod](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/computeflux2026isgod/32/11597_2.png) [@computeflux2026isgod](https://forum.polkadot.network/u/computeflux2026isgod)\ **Post date:** [September 23, 2026, 2:05am UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/15 "2026-09-23T02:05:23Z")
do you mean that after JAM we would be have difficult time to upgrading? so the JAM is the final version? ---
**Author:** ![florentina57](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/florentina57/32/7854_2.png) [@florentina57](https://forum.polkadot.network/u/florentina57)\ **Post date:** [September 23, 2026, 9:15am UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/16 "2026-09-23T09:15:47Z")
Hi @burdges, today Polkadot (and Kusama) validators in regions away from Europe are basically penalized by the design of the protocol since latency means they are missing more votes, translating in lower performance and lower era points as they are located quite far from the main european cluster of validators. This in addition to more expensive acces to required hardware and connectivity (sometimes x3), we have already discussed this in the past, for example [here](https://forum.polkadot.network/t/changes-on-polkadot-in-march-2026/17101/6), although the situation is more critical today than a few months ago. The Polkadot active set is mostly composed today of what seems like institutional staking, most independent validators have lost the majority of their organic nominators since the changes implemented this year, including: no more commissions, min self stake (and the incentive), no slashing for nominators and fast unbonding, which reduced staking rewards for nominators, who find a logical alternative in the rewards received from having their own validator nodes with selfstake between 10-100K DOT and enough backing DOT to keep them in the set (~1.3-1.5M). This means nodes previously operated by private individuals have mostly dropped out of the active set and those previously located in diverse geographic locations have ceased to exist or relocated to cheaper locations like Europe or Singapore. How would this change in JAM (aside from QUIC)? > [@burdges](#): > > Anyways if you ask validators to be 10x more powerful and have more bandwidth, and you somehow enforced this, then we could probably run 1000 cores on 1000 validators on Polkadot today. We do not do that because we want private individuals to run validators, not just institutions, and we want validators in many jurisdictions, some of which have worse bandwidth. > [@joyce](#): > > - Launch initial JAM production network, with nodes run by independent operators. How do you plan to achieve this? Will the protocol actually incentivize in any way to have validators in different regions? and independent validators instead of institutions? Otherwise I think it will be very difficult to achieve what you describe above. ---
**Author:** ![bkchr](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/bkchr/32/27_2.png) [@bkchr](https://forum.polkadot.network/u/bkchr)\ **Post date:** [September 23, 2026, 12:13pm UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/17 "2026-09-23T12:13:56Z")
> [@florentina57](#): > > Will the protocol actually incentivize in any way to have validators in different regions? and independent validators instead of institutions? Otherwise I think it will be very difficult to achieve what you describe above. Hey @florentina57, thank you for the questions. Most of them are not really related to JAM. Because incentivization of validators is not done by JAM. It is done by the upper layers, so by the logic that we describe today as Polkadot. JAM itself will broadly work as the relay chain today, but even today I would count the behavior you are explaining as bugs. I know that you raised them before, but this is something we need to improve. Maybe JAM is helping there, as it changes the underlying network, but I can not ensure that this will actually make a difference now. Generally to validator election + incentivization there are some discussions around the staking changes + metanode that will change the dynamics. ---
**Author:** ![sigurpol](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/sigurpol/32/11075_2.png) [@sigurpol](https://forum.polkadot.network/u/sigurpol)\ **Post date:** [September 23, 2026, 1:59pm UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/18 "2026-09-23T13:59:48Z")
Maybe @jonas you can comment as well here. I agree with @florentina57 and Basti that these are concrete issues and they are largely unrelated to JAM. As mentioned, initial discussions are underway regarding broader future of staking, focusing on integration with dotUSD, metanodes serving app, new election mechanism potentially replacing Phragmén and linked to Individuality and the App, and so on, shifting how validator elections and incentives work. So to achieve broader geographic distribution and decentralization, we will need to have proper (upcoming) protocol levers. And there will always be some natural tension on how to guarantee (economical) safety of the active validator set and proper decentralization. I can’t share anything concrete yet and in general it can also be a mix of on-chain and off-chain levers, e.g. via social contract on max number of nodes a validator operates, a decentralization campaign and so on. All largely unrelated to JAM and again, all yet to be properly defined before being shared with a larger audience. More details will follow in a separate post. ---
**Author:** ![ultracoconut](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/ultracoconut/32/5932_2.png) [@ultracoconut](https://forum.polkadot.network/u/ultracoconut)\ **Post date:** [September 23, 2026, 3:04pm UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/19 "2026-09-23T15:04:22Z")
Exactly, JAM breaks with the forkless upgrade system. ---
**Author:** ![bkchr](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/bkchr/32/27_2.png) [@bkchr](https://forum.polkadot.network/u/bkchr)\ **Post date:** [September 23, 2026, 7:00pm UTC](https://forum.polkadot.network/t/the-road-to-jam/18621/20 "2026-09-23T19:00:04Z")
It does not. You can still forkless upgrade services and thus, most of the important business logic. Even today with the relay chain you could not just launch “1000 cores” without doing node side changes. [Next page](https://forum.polkadot.network/t/the-road-to-jam/18621.md?page=2)