Smart Contracts

The Polkadot Relay Chain will not natively support smart contracts, however, parachains on Polkadot will support smart contracts.

Difference between developing a smart contract and a parachain

Layer of Abstraction

When you write a smart contract, you are creating the instructions that associate with and deploy on a specific chain address.

In comparison, a runtime module is the entire logic of a chain's state transitions (what's called a state transition function).

Smart contracts must consciously implement upgradability while parachains will have the ability to swap out their code entirely through a root command or via the governance pallet.

When you build a smart contract, it will eventually be deployed to a target chain with its own environment. Parachains allow the developer to declare the environment of their own chain, even allowing others to write smart contracts for it.

Gas Fees

Smart contracts must find a way to limit their own execution, or else full nodes are vulnerable to DOS attacks. An infinite loop in a smart contract, for example, could consume the computational resources of an entire chain, preventing others from using it. The halting problem shows that with a powerful enough language, it is impossible to know ahead of time whether or not a program will ever cease execution. Some platforms, such as Bitcoin, get around this constraint by providing a very restricted scripting language. Others, such as Ethereum, "charge" the smart contract "gas" for the rights to execute their code. If a smart contract does get into a state where execution will never halt, it eventually runs out of gas, ceases execution, and any state transition that the smart contract would have made is rolled back. Polkadot uses a weight-fee model and not a gas-metering model.

Parachains can implement arbitrarily powerful programming languages and contain no gas notion for their own native logic. This means that some functionality is easier to implement for the developer, but some constructs, such as a loop without a terminating condition, should never be implemented. Leaving certain logic, such as complex loops that could run indefinitely, to a non-smart contract layer, or even trying to eliminate it, will often be a wiser choice. Parachains try to be proactive, while smart contract platforms are event-driven.

Building a Smart Contract

The Polkadot relay chain itself will not support smart contracts. However, since the parachains that connect to Polkadot can support arbitrary state transitions, they can support smart contracts.

Substrate presently supports smart contracts out-of-the-box in two ways:

Frontier EVM Contracts

Frontier is the suite of tools that enables a Substrate chain to run Ethereum contacts (EVM) natively with the same API/RPC interface, Ethereum exposes on Substrate. Ethereum Addresses can also be mapped directly to and from Substrate's SS58 scheme from existing accounts.

Substrate Contracts

Substrate offers a built-in contract pallet; as time goes on, more parachains will support WebAssembly smart contracts. Additionally, there is the EVM Pallet, which allows a parachain to implement the Ethereum Virtual Machine, thereby supporting almost direct ports of Ethereum contracts.

A video version of the recap of the smart contract situation is available on the Polkadot YouTube channel.


When should I build a Substrate runtime versus a Substrate smart contract? This post answers the question more technically of when a developer might choose to develop a runtime versus a smart contract.

Here is the list of current resources available to developers who want to get started writing smart contracts to deploy on parachains based on Substrate.

  • ink! - Parity's ink to write smart contracts.

  • Substrate ink! Workshop - Walks you through the basics of writing and deploying an ERC-20 token using ink!.

Contracts Pallet

The experience of deploying to an EVM-based chain may be more familiar to developers that have written smart contracts before. However, the Contracts pallet makes some notable improvements to the design of the EVM:

  1. Wasm. The Contracts pallet uses WebAssembly as its compilation target. Any language that compiles to Wasm can potentially be used to write smart contracts. Nevertheless, it is better to have a dedicated domain-specific language, and for that reason Parity offers the ink! language.

  2. Rent. Contracts must pay rent or else hold a deposit suitably large enough in order to justify its existence on-chain. When a contract does not uphold this, it may create what's called a tombstone which is a reference to the contract. In some conditions, the contract will be deleted outright along with its storage if it does not maintain these requirements.

  3. Caching. Contracts are cached by default and therefore means they only need to be deployed once and afterward be instantiated as many times as you want. This helps to keep the storage load on the chain down to the minimum. On top of this, when a contract is no longer being used and the existential deposit is drained, the code will be erased from storage (known as reaping).

Storage Rent: Deprecated

pallet_contracts was initially designed to combat unbounded state growth by charging contracts for the state they consume but has since been deprecated.

See the associated pull request for more details.

Polkadot Standards Proposals (PSPs)

Web3 Foundation supports proposals for Polkadot that define a set standards to fit ecosystem needs. These standards go through several acceptance phases, where the engagement of the whole community is needed to build valuable and future-proof standards. All the teams who will benefit from a standard need to agree on its content.

Some of these PSPs are targeting Substrate's contracts pallet:


ink! is a domain specific language for writing smart contracts in Rust and compiles to Wasm code. As it states in its README, it is still in an experimental phase so brave developers should be aware that they might have a bumpy - but workable - development experience. There are some projects that have built projects in ink! with a decent level of complexity such as Plasm's Plasma contracts, so it is mature enough to start building interesting things.

For interested developers, they can get started writing smart contracts using ink! by studying the examples that were already written. These can be used as guideposts to writing more complex logic that will be deployable on smart contract parachains.

ink! has laid much of the groundwork for a new smart contract stack that is based on a Wasm virtual machine and compatible with Substrate chains.

Libraries for Smart Contracts in ink!

Collected below are some community examples of smart contracts in ink!. Are you working on a smart contract example? Ask us to add it to this page!

  • OpenBrush: an ink! library providing standard contracts based on PSP with useful contracts and macros for building.

  • Metis: a Wasm contract standard library, developed by Patract Labs.

Smart Contract Environments are still Maturing

It is still early for smart contracts on Polkadot and the development is only now stabilizing. We are actively producing content to help developers get up to speed and will maintain the Wiki with the latest resources. You should also keep up to date with the following links:

Parity Tech


Many smart contract platforms are building to become a parachain in the ecosystem. A community created and maintained list of different smart contract platforms building on Polkadot can be found at PolkaProjects.


Moonbeam is another project that is planning to deploy to Polkadot as a parachain and will support Ethereum compatible smart contracts. Since Moonbeam uses Frontier, an interoperability layer with existing Ethereum tooling, it will support all applications that are written to target the EVM environment with little friction.

Moonriver, a companion network to Moonbeam, launched as a parachain on Kusama. Parachain functionality is live, and features are being incrementally released. The final phase of the launch will include EVM functionality and balance transfers.

Try deploying a smart contract to Moonbeam by following their documentation.


Astar (formerly Plasm) is built on Substrate as a smart contract platform and intends to integrate with Polkadot as a parachain. Shiden is the sister network to Astar, is currently live on Kusama, and supports EVM, WASM, and Layer 2 solutions. Astar aims to house all layer 2 scaling solutions and support all layer 2 protocols through the OVM (Optimistic Virtual Machine).

Try deploying an Ethereum or ink! smart contract by following their documentation.


Acala is a decentralized finance consortium and DeFi infrastructure chain delivering a set of protocols to serve as the DeFi hub on Polkadot. Karura, Acala's canary network is live as a parachain on Kusama. Interested teams are now able to deploy DApps and smart contracts on Karura's platform. Acala is also implementing the Acala EVM.

Try deploying an Acala EVM smart contract by following their documentation.


Phala is a privacy-preserving cloud compute platform and aims to provide strong guarantees of confidentiality as a cross-chain platform. As a smart contract platform, Phala will enable the use of confidential smart contracts on Polkadot. Khala is Phala's canary network and is live as a parachain on Kusama.

Try deploying a confidential smart contract by following their documentation.

Keep In Touch

Even though the tooling is still maturing, the advantage of being early will be the familiarity and head start on your project, allowing you to innovate and create something truly new.

If you have interesting ideas for smart contracts on Polkadot, feel free to drop into the Polkadot Watercooler to talk about them. Developers may be interested in joining the Polkadot Beginners Lounge or Substrate Technical to ask their questions. As always, keep up to date with Polkadot and Kusama by following the social channels.

All the best.

Last updated