Polkadot Hub: Prioritizing growing ecosystem 3rd party providers, inc. DeFi, ASAP (through EVM)

Ecosystem
1

A technical update for parachain teams, runtime engineers, and governance voters regarding the Polkadot Hub. This post is the successor to “Solidity smart contracts: Striking a balance between innovating and traction” post.

After preparation, and a review by Parity, the Web 3 Foundation, BD teams and other ecosystem partners (thank you for all the input in the forum), the decision was made to prioritize ASAP growing an ecosystem of 3rd party providers (e.g. indexers, oracles, AML providers, and similar) that the unblock the

  1. porting across top tier Eth dapps, and
  2. enable greater functionality, e.g. economic possibilities in larger markets, for existing Polkadot rollups, and make Polkadot attractive for a greater set of new potential Polkadot rollups (through exposing these 3rd party providers via Polkadot Hub to the entire Polkadot).

Most of these 3rd party providers, as well as the top opportunities in the BD pipeline, require unmodified Solidity contracts, i.e. a 100% EVM compatible solution on Polkadot Hub, and similarly, versions of Solidity earlier than 0.8 are often required. (the Solidity to PVM compiler resolv only works with Solidity >=0.8 and even though it is Ethereum compatible, it isn’t 100% EVM compatible.)

Accordingly, Parity has basically deprioritized all other technical work at Parity (except for Asset Hub migration) so that we can deliver a 100% EVM compatible solution before the Dec holidays.

PVM is the future, but 3rd party provider traction is now

We originally pursued an Ethereum compatible stack that would execute in a PVM implementation rather than an EVM one. Because of its architecture, PVM offers several advantages like the ability to target it with many languages (e.g. Rust, C++, etc.) rather than Ethereum-specific languages like Solidity and Vyper. The PVM will also offer more powerful and less expensive on-chain compute that will unlock use cases that cannot be done on-chain now.

But we had to concede that the tooling stack around PVM was not strong enough to offer a compelling alternative to Ethereum solutions… yet. As an example, the resolc compiler, which compiles Solidity code to PVM bytecode, only works with Solidity versions 0.8 and greater. Many popular contracts (e.g. Circle’s CCTP) use older Solidity versions and the upgrade path can be non-trivial. While this does not affect new projects deploying, many new projects depend on older contracts like CCTP, so we have to make sure to support older versions of the Ethereum stack as well.

Parity will continue working on the PVM tooling stack to address issues like this to lower the barriers of accessing the power of PVM.

Pallet-revive shared stack

Pallet-revive’s ability to handle multiple VM backends allows us to create a shared stack (ETH-RPC + pallet-revive + EVM/PVM) which brings us a lot of advantages, e.g.:

  • We can maintain the momentum of in-house expertise and experience we’ve built on ETH-RPC and pallet-revive (as well as take advantage of the audits already done).
  • All improvements to ETH-RPC and pallet-revive will benefit both EVM and PVM.
  • E.g., precompiles are available to both EVM and PVM on launch, e.g., the XCM precompiles, which will be part of the launch, will be accessible to both.
  • Implementing cross-calling of contracts between PVM and EVM will be trivial, and the cross-calling will execute faster.
  • Lots of tooling innovation can be shared between PVM and EVM, e.g., we are building an Anvil test node (part of Foundry) that will allow testing smart contracts against our actual implementation (rather than a reference Ethereum/EVM implementation).
  • Smaller maintenance/tech debt footprint, i.e., we can allocate more people to innovating in the future.

We evaluated Frontier. While it serves the ecosystem well in specific contexts, it isn’t suitable for our needs on Polkadot Hub for several reasons:

  • Not compatible with PVM - making long-term migration and interoperability with PVM difficult.
  • Designed for a single VM backend, i.e., forces a double stack solution, instead of a shared stack.
  • Doesn’t address key issues - such as the resolution difference of DOT-based currency denominations and robust gas mapping.

REVM

As a 100% EVM-compatible solution, we choose REVM. REVM is:

  • Proven in production (e.g. used by Foundry, Hardhat, Optimism, Coinbase, Risc0, and many more).
  • Well-maintained.
  • Fast.
  • Actively audited.

In short: Combining REVM with pallet-revive and our ETH-RPC node is how we get to a high quality 100% EVM compatible solution quickest, and so enable the growth of an ecosystem of top tier 3rd party providers ASAP. And this solution is aligned with Polkadot’s future direction.

Timeline

  • Today: PVM preview part 1 on Kusama
  • Sep: PVM preview part 2 on Kusama: ERC20 support, basic XCM precompile.
  • Late Oct: 100% EVM-compatible REVM on Kusama Hub
  • Mid Dec: 100% EVM-compatible REVM on Polkadot Hub, along with PVM preview

Addendum

A note on developer experience

Key to our success in this regard will be a great developer experience, including:

  • All existing Solidity contracts deploy unchanged via Foundry or Hardhat, by having their compilation target EVM. This is ideal for the BD pipeline where top tier projects are ported from other blockchains.
    • Many can also target PVM unchanged.
  • New contracts can easily opt to be compiled via Foundry or Hardhat targeting PVM for lower gas cost and, once we release the JIT, more compute.
  • Tooling parity: Anvil-compatible dev node will ship with both VM backends enabled.

A note on gas mapping

Ethereum gas and Polkadot weight are not isomorphic. While simply emulating the EVM gas model might seem like an option, it isn’t a practical one, because:

  1. It would completely shut the door on throughout optimizations as we wouldn’t be able to account for the faster execution speed when using the PVM JIT.
  2. We won’t be able to make use of different gas models for different VM backends as this will make interop between them practically impossible.

[UPDATE]

  1. Changed PolkaVM to PVM.
  2. Improved wording on “PVM is the future…”.
  3. Ethreum gas priced is not fixed; hence point removed.
22 Likes
2

Just a small note on Frontier since it’s mentioned in this post:

  • There’s already PolkaVM support there and we actually think that’s the better way how PVM and EVM should interact based on our past benchmarks.
  • Frontier has swappable VM backend from the very early days since its development through the Runner trait. We predates revm (which only comes around 2 years ago). We think it’s really great for Ethereum mainnet and for situation that doesn’t require extensive customizability. We also thought about integrating revm using Frontier’s swappable VM backend architecture before, but are currently deciding against it due to its current lack of necessary customizibility.
  • The customizibility will be even better with the Rust EVM 1.0 launch (take a look at the unreleased master branch if you’re interested)!
8 Likes
3

I spoke of “3rd party providers“ which is clunky, but I couldn’t find the right words. I recently hear @nico_a speak of “financial primitives” (instead of speaking of DeFi, and associated infrastructure, as a vertical) which I think captures what I’m trying to convey a lot better.

4

Given Parity engineers’ focus for the rest of 2025 is the 100% EVM compatibility & AssetHub migration, it makes sense to me that the Gossamer and KAGOME teams focus on the Polkadot-SDK for the rest of this year (per their recent OpenGov proposals 1688 & 1689). Outside of Parity, they are likely the dev teams who are the most familiar with it, given the last few years they’ve spent attempting to develop alternative client implementations without a specification.

2 Likes
5

Nice to go with a “stable“ (r)evm :smiley: right now there is only one block explorer for passethub, the blockscout, would be great if more people hosted more EVM compatible block explorers. When will revm be available on Paseo? Will revm come to Paseo assethub or to passethub?

6

I’ve been following the EVM-on-PVM discussions over the past months and have been collaborating with friends from the Parity and DevRel teams to support this effort. I’ve now taken responsibility for making Thirdweb’s prebuilt contracts available on PolkaVM.

TL;DR

I’m acting as a consultant-developer-from-ecosystem on this proposal. The BD team from Thirdweb mentioned they have no interest or bandwidth to handle the caveats of PolkaVM and prefer to stay focused exclusively on EVM. Given the potential of leveraging their 130+ prebuilt audited contracts, I’ve decided to take on the integration myself.

Key Findings from My Research

Thirdweb’s SDK separates deployment logic and relies heavily on IPFS. The prebuilt contracts are developed using Foundry and stored as bytecode + compiler settings + ABI on IPFS, which the SDK consumes for deployment.

Deployment Workflow:

  1. Fetch Deployment Metadata from a Polygon Contract
    Link to source
    → returns publishMetadataUri with IPFS address

  2. Fetch Compiler Data (ABI + Compilation Settings)
    Link to source

  3. Fetch Contract Bytecode from IPFS
    Link to source

  4. Deploy Implementation Contract Once Per Chain
    Uses TWCloneFactory to reuse the implementation
    Link to source

Next Steps

The SDK uses this structure across all deployments. There’s also some custom logic for zkSync, still IPFS-based. Initially, I thought we’d need to upload ReSolC bytecode to their IPFS to enable usage on PVM. However, since they rely on TWCloneFactory, we’ll also need to adapt proxy generation to work with PolkaVM’s on-chain constructors.

This last point led me in a direction I’m not very familiar with. @Jan-Jan could you point me to someone who could help me keep progressing on adapting proxy generation to work with PolkaVM’s on-chain constructors?

Also, I’m already in touch with friends and contacts from Chainlink and Aragon. I’d love to stay aligned with you all on the prioritization of third-party tooling we want to bring into the ecosystem so I can coordinate and activate relevant contacts from my last four years working with EVM.

1 Like
7

Hi all, Nico here from Velocity Labs—one of the teams contributing to the launch of Polkadot Hub. We’ve been actively supporting Parity and W3F in the decision-making process, and we’re aligned with the direction that’s been collectively chosen. The extent to which Parity and W3F are reallocating resources to this initiative underscores both its urgency and its potential to serve as a major catalyst for ecosystem growth.

We firmly believe that the short- to medium-term benefits of Polkadot Hub lie in its compatibility with the EVM, rather than in the potential performance gains of the PVM. While we see value in the PVM long-term, we’re fully aligned with prioritizing EVM compatibility now to unlock real utility and adoption asap.

In relation to @Jan-Jan update: many of the ecosystem’s persistent challenges can be traced back to our lack of parity with the generic BUT core financial primitives that other ecosystems already offer. Because Web3 is inherently token-centric, these primitives are essential—not just for DeFi as a vertical, but as a horizontal layer that enables all use-cases and verticals to thirve.

When we talk about “financial primitives,” we’re referring to both DeFi, CeFi and token infrastructure like oracles, custodians, wallets, and bridges—components that enable the secure creation, movement, and custody of tokens. Polkadot has long suffered from either a lack of these tools or from siloed, ecosystem-specific versions that are unfamiliar to developers coming from other chains.

The reality is that many of these primitives have historically built their business models around where users—and liquidity—are concentrated, which has overwhelmingly been within EVM ecosystems. Meeting these builders where they are is the most pragmatic way for Polkadot to level the playing field. It will allow us to showcase the unique advantages we offer, rather than being overlooked simply because we lack the standard infrastructure that other ecosystems already provide.

At Velocity, we’ll continue working closely with Parity, W3F, and ecosystem partners to ensure these critical building blocks are available from day one as we roll out EVM compatibility on Polkadot Hub.

6 Likes
8

Hi there, Revm author here.

This is awesome news! Revm is currently the state of the art EVM used by the majority of Ethereum ecosystem. Not mentioned in the original post, but it is EVM used in Reth (an Ethereum client), so it participates and follows the upcoming Ethereum changes very closely.

Would bring to the attention that it is extensible and used as a framework to extend or override Eth mainnet functionality. This approach makes maintaining and following the new versions a lot easier. For example (Can’t link as new forum user):
op: github . com/bluealloy/revm/tree/main/crates/op-revm
bcs: github . com/bnb-chain/reth-bsc/blob/main/src/evm/handler.rs
gnosis: github . com/gnosischain/reth_gnosis/blob/master/src/evm/gnosis_evm.rs

My DMs are open if there are any questions.

8 Likes
9

We (as in Bitarray and Moonbeam) actually thought about integrating revm into Frontier as another engine we support, but then later spotted this enormous and gigantic PR from the Revive team. You can see that for revm integration, it’s currently required to literally copy all opcode implementation again in order to customize gas metering. We thought about this carefully and in that form it’s simply not maintainable.

From what I know, Revive has a deadline of this December to deliver a full EVM interpreter integration. If they continue to do it like that gigantic and unmaintainable way, I don’t believe they’ll catch it and it’s huge work for testing and auditing.

It would be great if there are further customization possibilities in revm. For example, in rust-evm, an opcode eval is divided into two steps, a separate gas metering step, and then the actual opcode impl. It would be great if we can do something like that in revm.

1 Like
10

To explain a bit further, I think what both Frontier and Revive need is probably a way to customize the gas metering without duplicating opcode implementations. We do always need quite extensive gas customization but not so much for other opcode behaviors.

A possible way to do this in revm is to add another generic Gasometer into the Evm struct and the opcode impls call it. This does require a bit of refactoring in revm so not sure if you are open to that for something specific to Polkadot?

(In the unreleased rust-evm1.0-alpha it’s designed specifically for this kind of extensive customizability, but it remained work-in-progress for a few years due to lack of time. We’re in the process of picking that up and finishing the release and testing if no other solutions are possible.)