Smart Contracts on Polkadot Hub: Progress Update

Ecosystem
1

TL;DR

We are progressing toward launching our smart contract platform that can execute PVM and EVM contracts on Kusama in October and on Polkadot in December. The PVM preview is live on Kusama and the Revm integration, which enables EVM compatibility, is advancing quickly. Our developer tooling is expanding, we are building out precompiles, and we are putting significant emphasis on testing to ensure a reliable launch. In parallel, we are implementing critical core pieces: gas/fee handling, Ethereum-style block data, and 18‑decimal DOT support.

Background

We recently announced a dual approach:

  • Deliver Revm for EVM compatibility to immediately unlock traction as this allows easy onboarding of top-tier Ethereum dApps, third-party providers, and other opportunities in the BD pipeline.

  • Advance PVM as the longer-term innovation path that brings higher compute (faster execution speed via the PVM JIT) and that unlocks new use cases.

This gives developers flexibility as they can choose the right backend from the start: either deploy unmodified Solidity contracts (including older Solidity versions) compiled to EVM today or target PVM to benefit from lower execution costs and more compute.

Current progress

Since then, Parity engineers across multiple teams have been working toward our year-end milestone.

Revm integration

Revm is being integrated as the EVM backend so that Solidity contracts can run unchanged and developers can keep their familiar tooling. The integration is still in development with some pieces missing (e.g., gas handling aligned with the PVM backend). Our target is initial code completion by early September, followed by a thorough testing phase.

Gas mapping and fee model

We’re implementing a sound mapping from Ethereum gas to Substrate weights so that wallets and dApps behave as expected and are consistent with Polkadot’s transaction payment model. The target for the initial implementation is early September.

Ethereum block storage

We’re introducing Ethereum‑style block storage in pallet‑revive. This enables infrastructure that relies on Ethereum block data and Merkle inclusion proofs to operate as expected. The initial version is implemented and under review and testing. Next we will benchmark the performance impact and continue to optimize.

18‑decimal DOT

For the smart contract platform, DOT will be exposed with 18 (rather than 10) to align with Ethereum tooling conventions and remove a common source of friction. The implementation of this feature has already been completed.

Tooling for developers

Hardhat and Foundry integrations continue, with test nodes that resemble our environment, particularly an Anvil‑compatible local node so that teams can test against our actual implementation rather than a reference chain (across both the EVM and the PVM backends). We will also add features to the Anvil node required for very special testing scenarios, such as forking of a live chain.

Testing

We are investing heavily in testing. On the one hand, we are working on tooling so that anyone can reliably and repeatedly test contracts targeting both the PVM and the EVM backends. On the other hand, we are ensuring that developers and users can trust the platform. This includes:

  • Running large test suites from top Ethereum applications across our PVM and EVM backends.

  • Performing differential tests against reference Ethereum implementations to catch divergences early.

  • Conducting stress tests and benchmarks.

We are aiming for high confidence in correctness, predictable gas behavior and resource usage, and rapid bug detection and resolution prior to the launch.

Impact

With this dual approach we balance immediate traction and innovation. Developers can move quickly by deploying unchanged Solidity contracts on EVM. Polkadot-specific features (via precompiles) will be available on both EVM and PVM. PVM’s advanced compute model will open new opportunities over time. With the shared stack, both backends benefit from improvements to the RPC, tooling, and precompiles.

What’s next

  • September: PVM preview part 2 on Kusama (ERC20 support, basic XCM precompile)

  • Late October: EVM and PVM backend live on Kusama

  • Mid December: EVM and PVM backend live on Polkadot

29 Likes
2

That’s an incredible development, contgratulations! I’m delighted that you’re taking this pragmatic and welcoming approach with REVM. I want to deploy on Polkadot an existing protocol written in Solidity for EVM and I’m relieved that I won’t need to port it to PVM. That being said I see that you’re introducing an alien stack to Polkadot and I have a few questions about it.

  1. Is Polkadot Hub running directly on the Relay chain or is it a new parachain?
  2. Polkadot accounts have addresses different from EVM-based chains. Is there a mapping? Is it two-way? Can I use my private key I’m using on Ethereum and use it to control a Polkadot account with the same address? Can I use it to control a regular Polkadot account with a Polkadot-like address?
  3. Can legacy Polkadot assets be handled as ERC-20s inside the EVM? What about assets living on parachains, are they directly accessible and handled by smart contracts as plain ERC-20s?
  4. Can EVM-based ERC-20s be handled on parachains?
  5. Are PVM smart contracts interoperable with EVM smart contracts? Can my EVM smart contract transparently call a PVM smart contract and vice versa?
1 Like
3

I have good news for your questions.

  1. Polkadot Hub is an abstraction and the concrete chain won’t matter for the end user. The low level answer: it will be a union of system chains, particularly the Asset Hub.
  2. The underlying address space consists of the standard 256 bit addresses common in Polkadot. There is a two way mapping between this address space and the 160 bit Ethereum address space. You can just use your Ethereum account (e.g., from your Ethereum wallet) out of the box. Through the address space mapping, this will also correspond to a Polkadot-like address.
  3. There are specific precompiles that allow you to access assets managed on the Polkadot Asset Hub (such as USDT or USDC) through an ERC20 contract interface.
  4. We are working on a full XCM precompiles interface for smart contracts. This is under development and not completely specced yet.
  5. Yes, fully interoperable.
5 Likes
4

The Polkadot Hub is indeed an abstract concept within the Polkadot system. However, for front-end, such as wallet, it must be a concrete concept with a unique name and chainid. It may appear similar to chains like “Arbitrum One,” though their essence is different. Therefore, Polkadot developers need to provide us with the final external chain name and chainid. Front-end code and user perception are adjusted around this.

1 Like
5

Sure, that’s where we need to talk low level. Smart contracts will execute on the Asset Hub and it will have a unique name and chain id of course.

1 Like
6

Good direction and progress on it, thanks for the updates. If the team needs extra hands for testing or precompiles work, please touch base - we’ve done a number of things for PVM already, and are one of the rare teams that’s done a lot on precompiles.

Otherwise, as soon as you have the Revm on the testnet we will do some benchmarking (measuring speed and cost of NFT minting and sending) as we’re setup to do this easily in different chains, and provide feedback. This can be an important tool for testing production readiness in our experience.

7

Thanks, I appreciate it and will come back to this offer.

8

I don’t agree, that’s like saying a Web2 app needs a single cloud server instance. While a Web2 app might have a single IP address as an entry point, it has the logic to route requests to many backend services. Likewise, Polkadot Hub is a collection of many services in the Polkadot network and is not confined by a single chain. I agree that we don’t have the tools to make this “easy”, as in a single entry point, and that pushes a lot of work to front end / wallet developers to create a good experience. But we will not give you a chain ID for Polkadot Hub because Polkadot Hub is not a chain. Working on this tooling and better abstractions will be a big focus of Parity in the next year, and we’d be happy to receive suggestions on what would make this better.

1 Like
9

I agree that the Polkadot Hub isn’t a chain, but as an EVM-compatible wallet, we focus on the RevM/PVM as the primary, user-recognizable entry point, abstracting away everything else. We also hope the Polkadot Hub will offer richer content, but we don’t want to spend more time educating users about the underlying complexity. Regardless of the entry point, we’ll call it the “Polkadot Hub.” Of course, the Polkadot team could also provide a standard for EVM wallets.

10

I understand that Ethereum-based wallets require this chain ID, but it’s always going to depend on the context in which you’re using Polkadot. Since Asset Hub will be the first chain that supports Ethereum compatibility, in this case you would use that chain ID. But more generally, if your app wants to include the user journey of setting / managing an identity, then it will need to connect to the People Chain.

As in, think of the individual system chains as services, not applications. A single application can use many services.

As an example, in the future, we’re also talking about adding pallet-revive to e.g. the Coretime chain so that people can deploy contracts to interact with Coretime directly. In that case, when you’re supporting that feature, your wallet will need to know to which chain to connect for which user journey.

It would be great to have better tooling that creates more standard interfaces, but ultimately it is up to the application developer to route requests to the right chain (backend service) for their users.

4 Likes
11

I agree with your point. It’s not difficult for wallets to correctly connect to Polkadot’s system chains or other services, hidden from users. However, we use the “asset hub” as the main entry point, using xcm/precomile to connect to parachains/system chains. To users, the “asset hub” is the “Polkadot hub.” This doesn’t fit Polkadot’s definition, and it can cause some confusion. I believe many EVM wallets will adopt the same or similar solutions. Polkadot is a widely compatible architecture, and third-party wallets generally don’t consider full support. Personally, I hope the “asset hub” will become the entry point to everything through smart contracts, becoming the abstract “Polkadot mainnet” that users understand. Of course, this doesn’t quite align with Polkadot’s philosophy.

1 Like