Polkadot Development in 2026: Contracts, Rollups and Coretime Explained

Building on Polkadot no longer means winning a parachain slot auction. Today you either deploy smart contracts on Polkadot Hub or an existing parachain, or you build your own chain with the Polkadot SDK and buy blockspace as coretime when you need it. Picking the right level of the stack is the most important decision you will make, because the cost and team you need differ by an order of magnitude between them.

What changed: from slot auctions to coretime

Polkadot's original model asked projects to lock large amounts of DOT in auctions to lease a parachain slot for up to two years. That model is gone. With Agile Coretime, blockspace on the relay chain is sold as cores: bulk coretime is bought in monthly regions on the Coretime system chain, and on-demand coretime lets a chain buy blocks only when it needs them. Related upgrades such as asynchronous backing and elastic scaling let a single chain produce blocks faster and use more than one core when demand rises.

At the same time, user-facing functionality has moved to Polkadot Hub (built on Asset Hub): balances, assets, staking-related functions and Ethereum-compatible smart contracts. The relay chain increasingly focuses on security and coordination. Further out, the JAM ("Join-Accumulate Machine") design proposes a more general successor to the relay chain; treat it as roadmap, not something to build against today.

Four ways to build on Polkadot

Teams often start with contracts and migrate to their own chain later if usage justifies it. Going the other way is rare. For contract-level dApps, the dedicated Polkadot dApp development guide covers front ends, wallets and indexing.

The Polkadot SDK

The Polkadot SDK is a single repository that brings together what used to be separate projects:

• Substrate: the blockchain framework (networking, consensus, database, runtime execution).
• FRAME: the Rust framework for writing runtime modules called pallets, with a large library of existing pallets for balances, assets, governance, multisig, proxies, staking and more.
• Cumulus: the layer that turns a Substrate chain into a parachain that submits blocks to Polkadot validators.
• XCM: the cross-consensus messaging format and executor for talking to other chains.

Your chain's logic lives in its runtime, compiled to WebAssembly and stored on-chain. Upgrading the chain means submitting a new runtime through governance; nodes pick it up without a hard fork. This forkless upgrade path is one of the strongest reasons to build a chain with the SDK. Generic node binaries (such as the Omni Node) mean many teams no longer need to maintain custom node code at all, just the runtime.

The official Polkadot developer documentation keeps templates and tutorials current with these changes; older Substrate tutorials often reference removed APIs.

Building your own rollup step by step

1. Prototype the logic as contracts first if you can. It validates demand before you commit to running a chain.
2. Start from a parachain template and compose existing pallets before writing new ones.
3. Write custom pallets with careful weight benchmarking, since weights determine fees and protect against denial-of-service.
4. Test locally with Zombienet (spawning relay chain and parachain nodes) and fork-test against live state with Chopsticks, including XCM interactions and runtime upgrades.
5. Launch on a testnet (Paseo is the community testnet for parachain teams), then optionally on Kusama for a real-economy trial (see Kusama development).
6. Register the chain and buy coretime: bulk for steady production, on-demand for low-traffic phases.
7. Run collators, the nodes that produce your chain's blocks, with monitoring and redundancy.
8. Open XCM channels with Polkadot Hub and the parachains your users need, and integrate assets such as USDT and USDC.

Cross-chain: XCM and bridges

XCM lets chains transfer assets and execute instructions on each other. The two transfer models are teleports (between chains that fully trust each other, such as system chains) and reserve transfers (one chain holds the real asset and others hold derivatives). Getting fee payment, asset registration and failure handling right is a significant engineering effort. For Ethereum connectivity, Snowbridge provides a trust-minimized bridge via Bridge Hub, and other bridging options exist; evaluate each one's trust model carefully, since bridges are a common target for exploits.

Contracts or your own chain: a decision checklist

Most teams overestimate how much they need their own chain. Answer these questions honestly before committing to a runtime:

• Do you need custom fee logic? Paying fees in your own token, waiving fees for certain users, or charging per action rather than per weight are easier at the runtime level. Contracts can approximate some of this with sponsorship, but not all.
• Is your throughput need sustained? If your app will produce steady, heavy traffic, dedicated blockspace via coretime can be cheaper and more predictable than competing for space on a shared contract chain. If traffic is spiky or unknown, contracts or on-demand coretime are safer.
• Do you need protocol-level features? Native privacy schemes, specialized cryptography, custom governance with its own origins and tracks, or on-chain logic that would be too expensive as contract code all point toward a runtime.
• Can you staff it long term? A chain needs Rust engineers who understand FRAME, benchmarking and storage migrations, plus operators for collators and RPC nodes. That cost continues after launch.
• Where are your users? A new chain starts with zero users, zero liquidity and no wallet support. Contracts on Polkadot Hub or a popular parachain inherit all three.

If most answers point toward contracts, start there. A contract deployment can later become the reference implementation for a dedicated chain once demand is proven.

Team and cost

These estimates assume an experienced team. Rust and FRAME expertise is scarcer than Solidity expertise, and runtime audits are specialized, so both carry a premium. Coretime prices are set by market mechanisms and change over time; check current sale prices on the Coretime chain rather than relying on old figures.

Common mistakes

• Building a chain when contracts would do, then struggling to attract users to a new network.
• Skipping weight benchmarking, leaving extrinsics underpriced and the chain open to spam.
• Not testing runtime upgrades and storage migrations against real state with Chopsticks.
• Assuming XCM transfers always succeed; trapped assets and fee mismatches are common.
• Ignoring wallet and indexer support. Users need to see your chain's assets in Polkadot wallets; see Polkadot wallet development.

Use cases that fit Polkadot

Polkadot suits application-specific chains needing custom economics (DEXs, lending, gaming, identity), products that span several chains through XCM, and teams that want forkless upgrades and on-chain governance. Ecosystem examples include DeFi chains such as Hydration, EVM and multi-VM chains such as Moonbeam and Astar (see NFT marketplaces on Astar), and liquid staking chains. Token launches in the ecosystem are covered in IDO launchpads on Polkadot.

Frequently asked questions