Polkadot 2.0 resource shifts and JAM implementation

Agile Coretime replaces the two-year lease system for single cores with a dynamic, on-demand blockspace model. Projects purchase blockspace in bulk or on-demand, which allows them to match resource availability with network demand. This prevents resource waste during low activity and manages congestion during peak times. Developers no longer face the binary choice of competing for limited blockspace with smart contracts or paying for large amounts of dedicated blockspace for a blockchain.

Derek Yoo, CEO of Moonsong Labs, notes that Agile Coretime allows mature projects with product-market fit to scale without needing sharding. Smaller projects access Polkadot infrastructure without significant DOT collateral, which lowers entry barriers. Eskimor, a lead developer at Parity Technologies, expects more experimentation and projects to launch on Polkadot because of this accessibility.

The transition to JAM moves Polkadot away from the Relay-chain model toward a design that functions as a collective computer. JAM splits computation among discrete units called cores, similar to CPU cores. These cores execute smart-contract execution, agent execution, media serving, and regular software like Quake. While the Relay-chain focused on checking parachain business logic, JAM allows cores to perform these tasks directly. This makes JAM comparable to general-purpose L1 smart-contract protocols like Ethereum and Solana.

JAM operates transactionlessly through a two-stage process. The Refine function handles mostly stateless computation, while the Accumulate function folds results into the service state. Refine accepts up to 15 MB of data per 6-second time slot, but it yields a maximum of 90 kB of data. This results in significant data compaction. The Accumulate function is stateful, meaning it accesses the JAM chain state, reads storage from services, and transfers funds.

Interoperability competition and technical differences

Cosmos and Polkadot both target the interoperability market using different architectural models. Cosmos uses a Hub and Zone model where Hubs connect with Zones through the Inter-Blockchain Communication Protocol (IBC). Validators on Cosmos operate independently for each zone. Polkadot uses a sharded model where Parachains connect to a Relay Chain. Parachains lease security from the Relay Chain, so they do not maintain their own validators.

The scope of Cosmos currently focuses on asset transfer, and its largest application remains decentralized exchanges. Polkadot focuses on inter-parachain messaging through the Cross-Chain Message format (XCM). XCM defines how messages move between chains, smart contracts, and bridges. Polkadot utilizes Vertical Message Passing, consisting of Upward Message Passing and Downward Message Passing, to route information between parachains and the Relay Chain.

The Cosmos SDK helps developers create blockchains that interact with the Cosmos Hub. Polkadot uses Substrate, though developers can use alternate software to integrate as shards. The Cosmos approach differs from Polkadot because Cosmos validators are independent, while Polkadot validators reside on the Relay Chain.

Governance and the Dots Army

The Dots Army consists of DOT holders, developers, validators, and contributors who govern the network through OpenGov. OpenGov replaced the centralized Council and Technical Committee with a decentralized framework. This system uses multiple Tracks, such as the Root Track for critical runtime upgrades and the Whitelisted Caller Track for technical emergencies.

OpenGov uses Conviction Voting to prevent governance capture by high-capital entities. Users lock DOT tokens to multiply their voting power. Locking 100 DOT for 32 enactment periods, which is about 896 days, yields a 6.0x multiplier. This differs from the "one token equals one vote" model. OpenGov also uses adaptive quorum biasing to adjust the supermajority required for a referendum based on voter turnout. This prevents minorities from blocking proposals by simply refusing to vote.

The system faces challenges including governance overload and fatigue because OpenGov operates 24/7. The continuous influx of proposals requires significant time and technical expertise to analyze. Can the community maintain high engagement levels during periods of low activity? Users must also manage the 28-day unbonding period for staked DOT, which prevents trading during market volatility.