Polkadot founder Gavin Wood’s JAM represents a new direction in blockchain architecture evolution. Compared to existing scaling solutions, JAM is not simply stacking more validators or optimizing hardware but fundamentally redefining the operational logic of blockchain as a decentralized computing platform. This innovative system design has attracted global developer attention and is expected to be implemented in Q4 2025.
The Eternal Paradox of Blockchain Scaling: Centralization or Decentralization
The core dilemma facing current blockchains is straightforward—transactions are processed sequentially, and validators must re-verify each transaction to ensure security. This design guarantees safety but sacrifices performance.
Scaling blockchain seems simple but faces two distinct paths: one is vertical scaling—optimizing hardware and code to achieve high performance on a single chain; the other is horizontal scaling—distributing workload across multiple weaker systems operating in parallel.
Solana chose vertical scaling—continually optimizing code, using faster validators, improving connectivity—to maximize throughput on a single chain. However, this approach hits a ceiling: to maintain decentralization, the threshold for running validator nodes cannot be infinitely raised, or the network risks centralization.
The Dilemma of Vertical vs. Horizontal Scaling: Mainstream Solutions’ Conundrum
If opting for horizontal scaling, multiple independent systems must operate concurrently. The Cosmos ecosystem exemplifies this approach—you can join with your own security, scaling as needed. But the trade-offs are clear: security levels vary across chains, cross-chain interactions are limited, and the ecosystem becomes fragmented.
Ethereum has adopted Rollups, attempting to retain mainnet security while introducing multiple Layer 2 solutions. However, since smart contracts share the same execution environment, even with Rollups, application fragmentation persists—cross-chain communication remains slow and complex, far less efficient than native transactions.
Limitations of Parachain Models and JAM’s Breakthrough
Polkadot takes a different approach: scaling via parachains sharing a secure network. Each parachain has its own state and governance but shares the same validator set for security. Unlike Ethereum, validators not only store data but also re-execute transactions on parachains to ensure consistency.
However, this model has limitations: data is locked within specific shards and cannot flow across shards; developers must choose between parachains or Rollup chains to connect to Polkadot, limiting flexibility; DOT is mainly used for paying block space fees, with relatively narrow use cases.
Deeper questions arise: why force developers to choose a specific chain type? What if they don’t need to make such a choice at all?
Inspired by these insights, JAM was born—not merely adding features but abstracting and generalizing the entire Polkadot infrastructure.
From Operating System Kernels to Blockchain Foundations: JAM’s Architectural Innovation
To understand JAM, it’s best to compare it to a computer’s operating system kernel.
What is the kernel responsible for? Managing system resources (CPU, memory), enabling communication between hardware and software, without restricting what software users run—that’s up to the user. JAM plays this role: it is the kernel of Polkadot’s hardware infrastructure, allocating compute and storage resources, allowing any program to run in a shared, shard-based, secure environment without restrictions.
In simple terms:
Traditional blockchains (like Ethereum) are akin to self-hosted basement servers—full-featured but limited in scalability.
Polkadot parachain model is like renting cloud computing resources—shared security but still requiring choosing a chain type.
JAM is like serverless computing—developers just write code, no need to worry about underlying infrastructure.
Serverless architecture has transformed Web 2.0 applications; JAM aims to bring this mindset into blockchain.
Performance Data: Why JAM Surpasses Existing Smart Contract Chains
Concrete numbers are more intuitive. Polkadot currently has 1,023 validators distributed across 341 cores (each core with 3 validators). Regarding data availability (DA):
Before asynchronous support: 20 Mbps
After asynchronous support: 67 Mbps
In JAM: 852 Mbps
This is 85 times the current Polkadot computational load. Based on a transaction size of 250 bytes, JAM aims for 300,000 TPS, with long-term optimization potentially exceeding 1.5 million TPS.
Why can it reach such performance? The key lies in JAM’s dual-layer code architecture.
Standard smart contracts run a single code on-chain. JAM’s service has two parts:
On-chain: runs logic similar to smart contracts, responsible for changing blockchain state.
Off-chain: runs in parallel across 341 “cores” (akin to CPU cores), accessing a 2 PB decentralized data lake.
Because off-chain computation is extremely fast and handles large datasets, traditional fee models (per transaction) are no longer suitable. JAM operates on a vastly different scale—a system beyond conventional blockchain concepts, with multi-functionality.
Data Storage and Long-term Persistence in JAM
To support this architecture, JAM includes decentralized storage:
2 PB data lake supporting high-speed read/write
Data can be marked for individual storage
Storage duration is about 28 days, after which data is automatically deleted or re-stored
For data beyond 28 days, long-term storage must be accessed via separate decentralized storage solutions—blockchains, smart contracts, or other methods. JAM’s design makes this process more efficient and developer-friendly, without requiring complex configurations.
What Innovations Can JAM Bring?
Combining these features, JAM unlocks several new possibilities:
Transaction fee-free dApps—traditional smart contract chains require gas fees for every operation; JAM breaks this barrier, enabling new types of encrypted applications.
Surpassing Solana’s throughput—Solana’s maximum throughput is around 850 MB/s; JAM achieves 852 MB/s and solves synchronization and composability issues in multi-chain environments (a pain point current multi-chain architectures cannot address).
Universal computing platform—any code, any program can run on it, not limited to specific chain types or smart contract languages.
Notably, JAM’s sharding allows synchronized processing: cores share data within shards, enabling applications to interact within the same block—something current multi-chain architectures struggle with.
JAM Launch and Global Roadmap: 2025–2026
Development of JAM is accelerating. The first implementation is expected in Q4 2025. Polkadot has launched a 10 million DOT incentive program to encourage developers to build within the JAM ecosystem.
Gavin Wood has been on a global outreach tour since early this year, visiting Buenos Aires, Berkeley, Zurich, Tokyo, Seoul, China, Singapore, Brussels, aiming to introduce JAM’s vision and technology to future developers. He even returned to Silicon Valley—where he and Vitalik once proposed Ethereum, which was initially rejected—now invited back.
Why Is Decentralization So Difficult?
Why has the journey been so long? The fundamental reason is the cost of decentralization.
Computing speeds are increasing, blockchains are advancing, databases are evolving, but the key difference lies in whether the system is truly built on decentralization. If you only need one node or 42 nodes in the same data center (like ICP), scaling is easy—just deploy high-end hardware, gigabit networks, and few nodes handle most transactions.
But achieving genuine decentralization exponentially increases difficulty. This explains why Ethereum, despite many talented developers, still faces scaling challenges—it’s only now reaching the stage Polkadot achieved years ago. And Polkadot, through JAM, is pushing the frontier again. It’s expected that in the coming years, other mainstream networks will adopt similar architectural concepts.
In contrast, Solana is currently following the path Ethereum started two years ago with Layer 2 solutions.
JAM signifies that blockchain scaling has entered a new era—moving from “how to do it faster” to “how to achieve fundamental breakthroughs under decentralization.”
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
How does JAM ultimately solve the blockchain scalability problem? Polkadot creates the next-generation universal computing layer
Polkadot founder Gavin Wood’s JAM represents a new direction in blockchain architecture evolution. Compared to existing scaling solutions, JAM is not simply stacking more validators or optimizing hardware but fundamentally redefining the operational logic of blockchain as a decentralized computing platform. This innovative system design has attracted global developer attention and is expected to be implemented in Q4 2025.
The Eternal Paradox of Blockchain Scaling: Centralization or Decentralization
The core dilemma facing current blockchains is straightforward—transactions are processed sequentially, and validators must re-verify each transaction to ensure security. This design guarantees safety but sacrifices performance.
Scaling blockchain seems simple but faces two distinct paths: one is vertical scaling—optimizing hardware and code to achieve high performance on a single chain; the other is horizontal scaling—distributing workload across multiple weaker systems operating in parallel.
Solana chose vertical scaling—continually optimizing code, using faster validators, improving connectivity—to maximize throughput on a single chain. However, this approach hits a ceiling: to maintain decentralization, the threshold for running validator nodes cannot be infinitely raised, or the network risks centralization.
The Dilemma of Vertical vs. Horizontal Scaling: Mainstream Solutions’ Conundrum
If opting for horizontal scaling, multiple independent systems must operate concurrently. The Cosmos ecosystem exemplifies this approach—you can join with your own security, scaling as needed. But the trade-offs are clear: security levels vary across chains, cross-chain interactions are limited, and the ecosystem becomes fragmented.
Ethereum has adopted Rollups, attempting to retain mainnet security while introducing multiple Layer 2 solutions. However, since smart contracts share the same execution environment, even with Rollups, application fragmentation persists—cross-chain communication remains slow and complex, far less efficient than native transactions.
Limitations of Parachain Models and JAM’s Breakthrough
Polkadot takes a different approach: scaling via parachains sharing a secure network. Each parachain has its own state and governance but shares the same validator set for security. Unlike Ethereum, validators not only store data but also re-execute transactions on parachains to ensure consistency.
However, this model has limitations: data is locked within specific shards and cannot flow across shards; developers must choose between parachains or Rollup chains to connect to Polkadot, limiting flexibility; DOT is mainly used for paying block space fees, with relatively narrow use cases.
Deeper questions arise: why force developers to choose a specific chain type? What if they don’t need to make such a choice at all?
Inspired by these insights, JAM was born—not merely adding features but abstracting and generalizing the entire Polkadot infrastructure.
From Operating System Kernels to Blockchain Foundations: JAM’s Architectural Innovation
To understand JAM, it’s best to compare it to a computer’s operating system kernel.
What is the kernel responsible for? Managing system resources (CPU, memory), enabling communication between hardware and software, without restricting what software users run—that’s up to the user. JAM plays this role: it is the kernel of Polkadot’s hardware infrastructure, allocating compute and storage resources, allowing any program to run in a shared, shard-based, secure environment without restrictions.
In simple terms:
Serverless architecture has transformed Web 2.0 applications; JAM aims to bring this mindset into blockchain.
Performance Data: Why JAM Surpasses Existing Smart Contract Chains
Concrete numbers are more intuitive. Polkadot currently has 1,023 validators distributed across 341 cores (each core with 3 validators). Regarding data availability (DA):
This is 85 times the current Polkadot computational load. Based on a transaction size of 250 bytes, JAM aims for 300,000 TPS, with long-term optimization potentially exceeding 1.5 million TPS.
Why can it reach such performance? The key lies in JAM’s dual-layer code architecture.
Standard smart contracts run a single code on-chain. JAM’s service has two parts:
Because off-chain computation is extremely fast and handles large datasets, traditional fee models (per transaction) are no longer suitable. JAM operates on a vastly different scale—a system beyond conventional blockchain concepts, with multi-functionality.
Data Storage and Long-term Persistence in JAM
To support this architecture, JAM includes decentralized storage:
For data beyond 28 days, long-term storage must be accessed via separate decentralized storage solutions—blockchains, smart contracts, or other methods. JAM’s design makes this process more efficient and developer-friendly, without requiring complex configurations.
What Innovations Can JAM Bring?
Combining these features, JAM unlocks several new possibilities:
Transaction fee-free dApps—traditional smart contract chains require gas fees for every operation; JAM breaks this barrier, enabling new types of encrypted applications.
Surpassing Solana’s throughput—Solana’s maximum throughput is around 850 MB/s; JAM achieves 852 MB/s and solves synchronization and composability issues in multi-chain environments (a pain point current multi-chain architectures cannot address).
Universal computing platform—any code, any program can run on it, not limited to specific chain types or smart contract languages.
Notably, JAM’s sharding allows synchronized processing: cores share data within shards, enabling applications to interact within the same block—something current multi-chain architectures struggle with.
JAM Launch and Global Roadmap: 2025–2026
Development of JAM is accelerating. The first implementation is expected in Q4 2025. Polkadot has launched a 10 million DOT incentive program to encourage developers to build within the JAM ecosystem.
Gavin Wood has been on a global outreach tour since early this year, visiting Buenos Aires, Berkeley, Zurich, Tokyo, Seoul, China, Singapore, Brussels, aiming to introduce JAM’s vision and technology to future developers. He even returned to Silicon Valley—where he and Vitalik once proposed Ethereum, which was initially rejected—now invited back.
Why Is Decentralization So Difficult?
Why has the journey been so long? The fundamental reason is the cost of decentralization.
Computing speeds are increasing, blockchains are advancing, databases are evolving, but the key difference lies in whether the system is truly built on decentralization. If you only need one node or 42 nodes in the same data center (like ICP), scaling is easy—just deploy high-end hardware, gigabit networks, and few nodes handle most transactions.
But achieving genuine decentralization exponentially increases difficulty. This explains why Ethereum, despite many talented developers, still faces scaling challenges—it’s only now reaching the stage Polkadot achieved years ago. And Polkadot, through JAM, is pushing the frontier again. It’s expected that in the coming years, other mainstream networks will adopt similar architectural concepts.
In contrast, Solana is currently following the path Ethereum started two years ago with Layer 2 solutions.
JAM signifies that blockchain scaling has entered a new era—moving from “how to do it faster” to “how to achieve fundamental breakthroughs under decentralization.”