Polkadot development no longer starts with a parachain slot auction. A team either deploys smart contracts on Polkadot Hub or an existing parachain, or builds its own chain with the Polkadot SDK and buys blockspace as coretime. This guide explains both paths, the tools for each, and the team and budget each path needs.
From slot auctions to coretime
Polkadot's original model asked projects to lock large amounts of DOT in an auction, and the winner leased a parachain slot for up to two years. Agile Coretime replaced that model.
Under Agile Coretime, Polkadot sells relay-chain blockspace as cores, and the Polkadot documentation describes two options:
- Bulk coretime gives a chain a core, or part of a core, for a period of up to 28 days, and the chain renews the purchase when the period ends.
- On-demand coretime lets a chain buy validation one block at a time, which suits chains with low or irregular traffic.
Two related upgrades raise throughput: asynchronous backing lets a parachain build blocks faster, and elastic scaling lets one chain use more than one core when demand rises.
User functions now live on Polkadot Hub, which holds balances and assets, staking, governance, identity and Ethereum-compatible smart contracts. Users can pay Hub transaction fees in assets other than DOT, while the relay chain focuses on security and coordination.
The JAM ("Join-Accumulate Machine") design is the planned successor to the relay chain, so check its rollout status before you plan a product around it.
Four ways to build on Polkadot
| Approach | What you build | Shared security | Relative effort | Typical reason |
|---|---|---|---|---|
| Contracts on Polkadot Hub | Solidity contracts on REVM or PVM | Yes | Lowest | Tokens, DeFi, NFTs and DAOs that want native Polkadot assets |
| Contracts on an existing parachain | Solidity on Moonbeam, Astar or Acala | Yes | Low | The team needs that parachain's users or liquidity |
| Your own parachain (rollup) | A runtime built with the Polkadot SDK and secured by Polkadot | Yes | High | Custom fees, governance, throughput or logic that contracts cannot provide |
| Standalone Substrate chain | A chain built with the SDK but with its own validators | No | High, plus validator economics | Private or sovereign networks without a relay-chain link |
Teams often start with contracts and move to their own chain later if usage grows, and the move in the other direction is rare. The Polkadot dApp guide covers front ends, wallets and indexing for contract-based apps.
Smart contracts on Polkadot Hub
Polkadot Hub runs two contract engines behind one Ethereum-style JSON-RPC interface:
| Engine | How it runs contracts | Status in the docs |
|---|---|---|
| REVM | A Rust implementation of the EVM. Runs standard Ethereum bytecode without changes. | Main path for Solidity teams |
| PVM (PolkaVM) | Compiles Solidity or Rust to RISC-V bytecode for faster execution and lower fees. Solidity compiles with the resolc compiler. | Preview. The docs say PVM contracts may be unstable or incomplete. |
Developers use MetaMask, Hardhat, Foundry, Remix, ethers.js, viem and other Ethereum tools on the Hub, and contracts on the two engines can call each other.
Precompiles let Solidity contracts reach Polkadot features such as governance, multisig and XCM, and the OpenZeppelin Contracts Wizard has a Polkadot version for ERC-20 and ERC-721 contracts.
The Polkadot SDK
The Polkadot SDK is one repository that combines several former projects:
- Substrate is the blockchain framework, which handles networking, consensus, the database and runtime execution.
- FRAME is the Rust framework for runtime modules, called pallets, and includes ready pallets for balances, assets, governance, multisig, proxies, staking and more.
- Cumulus turns a Substrate chain into a parachain that submits blocks to Polkadot validators.
- XCM is the cross-consensus message format and executor for communication with other chains.
A chain's logic lives in its runtime, which compiles to WebAssembly and sits on-chain. To upgrade the chain, the team submits a new runtime through governance, and nodes switch to it without a hard fork.
Generic node binaries such as the Omni Node mean many teams maintain only the runtime and write no custom node code. The Polkadot developer documentation keeps templates and tutorials current, while older Substrate tutorials often use removed APIs.
Polkadot parachain development step by step
- Prototype the logic as contracts first where possible, so a contract version tests demand before the team commits to running a chain.
- Start from the parachain template and add existing pallets before you write new ones.
- Write custom pallets and benchmark their weights, which set fees and protect the chain against spam.
- Test locally with Zombienet, which starts relay-chain and parachain nodes. Fork live state with Chopsticks to test XCM messages and runtime upgrades.
- Deploy to Paseo, the official Polkadot TestNet, after which a team can trial the chain on Kusama with real value. See Kusama.
- Reserve a parachain ID, register the chain and obtain coretime. Bulk coretime suits steady production, and on-demand coretime suits quiet phases.
- Run collators, the nodes that produce your chain's blocks, with monitoring and spare nodes.
- Open XCM channels with Polkadot Hub and the parachains your users need, and register assets such as USDT and USDC.
Cross-chain: XCM and bridges
XCM lets chains move assets and run instructions on each other, using two transfer models:
- Teleports move assets between chains that fully trust each other, such as system chains.
- Reserve transfers keep the real asset on one chain, while other chains hold a derivative of it.
Fee payment, asset registration and failure handling in XCM take significant engineering work. For Ethereum, Snowbridge connects through Bridge Hub with a trust-minimized design. Other bridges exist too, so check each bridge's trust model, because attackers often target bridges.
Contracts or your own chain: a checklist
Many teams expect to need their own chain and later find that contracts would have worked. Answer these questions before you commit to a runtime:
- Custom fee logic. A runtime makes it easier to take fees in your own token, waive fees for some users, or charge per action instead of per weight. Contracts can cover part of this with fee sponsorship.
- Steady throughput. An app with steady heavy traffic may pay less with its own coretime than with space on a shared contract chain. For irregular or unknown traffic, contracts or on-demand coretime carry less risk.
- Protocol-level features. Native privacy schemes, special cryptography, custom governance tracks and logic that would cost too much to run as contract code all need a runtime.
- Long-term staff. A chain needs Rust engineers who know FRAME, benchmarking and storage migrations. It also needs operators for collators and RPC nodes, and these staff costs continue after launch.
- Users. A new chain starts with no users, no liquidity and no wallet support. Contracts on Polkadot Hub or a popular parachain get all three from day one.
A contract deployment can later serve as the reference version for a dedicated chain.
Polkadot development team and cost
| Path | Typical team | Time to mainnet (estimate) | Ongoing costs |
|---|---|---|---|
| Contracts on Polkadot Hub or a parachain | 2 to 4 engineers (Solidity, front end) | 2 to 5 months plus audit | Indexer, RPC, monitoring |
| Own parachain with mostly existing pallets | 3 to 5 engineers, including Rust/FRAME and DevOps | 5 to 9 months plus audit | Coretime, collators, RPC nodes, upgrades |
| Own parachain with new pallets and heavy XCM use | 5 to 8 engineers, senior Rust | 9 to 15 months plus audits | The costs above, plus governance and ecosystem work |
These estimates assume an experienced team and are not quotes. Rust and FRAME developers are harder to hire than Solidity developers, so they cost more, and runtime audits need specialists and also cost more. Coretime prices come from market sales and change over time, so check current sale prices on the Coretime chain.
Common mistakes
- A team builds a chain when contracts would work, and then cannot attract users to the new network.
- A team skips weight benchmarking, so extrinsics are underpriced and spam becomes cheap.
- A team does not test runtime upgrades and storage migrations against real state with Chopsticks.
- A team assumes XCM transfers always succeed, though trapped assets and fee mismatches are common.
- A team ignores wallet and indexer support, so users cannot see the chain's assets. See Polkadot wallet development.
Use cases that fit Polkadot
Polkadot suits application chains that need custom economics, such as DEXs, lending, gaming and identity. It also suits products that span several chains through XCM, and teams that want forkless upgrades and on-chain governance.
Ecosystem examples include the DeFi chain Hydration and the EVM parachains Moonbeam, Astar and Acala. See NFT marketplaces on Astar and IDO launchpads on Polkadot.
Frequently asked questions
Do I still need to win a parachain auction?
No. Coretime replaced slot auctions, so a team registers its chain and buys bulk or on-demand coretime.
Can I write Polkadot smart contracts in Solidity?
Yes. Polkadot Hub runs unmodified Solidity contracts on REVM, and EVM parachains such as Moonbeam run standard Solidity. The PVM engine also accepts Solidity through the resolc compiler, but the docs label PVM a preview.
What is the difference between Substrate and the Polkadot SDK?
Substrate is the blockchain framework, and the Polkadot SDK is the repository that combines Substrate, FRAME, Cumulus and XCM. New documentation refers to the SDK.
Should I launch on Kusama first?
Kusama is optional. It offers a network with real value and faster governance, which helps a team trial risky features. The Polkadot docs recommend Paseo for testing before either network.
Which language do I need for Polkadot development?
Runtime and pallet work uses Rust, while contracts use Solidity, or Rust on PVM. Front ends use TypeScript with libraries such as polkadot-api or Dedot.