Discussions on the Frontier roadmap for 2025 and 2026

[sorpaas]

Project status

After year long disagreement with Parity over the direction of Ethereum-compatibility roadmap for Polkadot, we ended up parting ways. Ironically, in July 2025, Parity admitted itself that its current roadmap (the revive project) will not work as expected.

On 25 Jan 2024, "Parity Technologies Limited" and me signed an "Intellectual Property Rights Assignment Agreement" which assigned the IP of the whole Frontier project to me. In July 2025, I decided to found Bitarray GmbH which I'll move Frontier's ownership into, and I'll continue to develop Frontier always as before.

Regarding copyright, however, it is important to note that Frontier has not required CLA, and therefore the actual copyright is never owned by a single person or entity but by all contributors. So rest assured that even though the "ownership" can change, nothing practical will change.

At this moment, for Bitarray GmbH, we have secured sufficient cashflow for this year from another project. However, we don't yet have anything from the Polkadot ecosystem or for Frontier. In the next few months, we'll begin talking with ecosystem shareholders. We believe that the maintenance cost for Frontier is low to moderate (and we can justify the costs with support for parachain teams). Therefore we shouldn't expect big problems. However, it's important to note that the implementation of the roadmap may be subject to our funding status.

Rust EVM 1.0

In Frontier, we use the Rust EVM (originally called SputnikVM) project due to the usually extensive customization requirements for parachains. Gas metering must be adopted specifically for Substrate. Interop and precompile requirements. Special limitations on Polkadot, etc. Rust EVM has been the most suitable engine as it's designed from the very beginning with customization in mind (the first user of Rust EVM is actually not Ethereum mainnet!).

However, the codebase is indeed getting older and older as a 7 years old project. Certain customizations are currently not so smooth and they usually require changing the Rust EVM codebase. Our testing framework is also a bit "awkward" because it must be maintained as a separate repo (the old testing framework uses certain GPL components, but Rust EVM is Apache-2, so they must not be mixed).

Last year we started the work of Rust EVM 1.0 which aims to fix all the above problems:

• A new testing framework, rewritten completely and released under Apache-2, which we'll follow upstream Ethereum and always maintain 100% coverage.
• Even more extensive customization down to per-opcode level.
• A newly designed call stack, which is generic to be reused. The call stack is unique that it is stack-based for "shadow call stacks", which is fast and covers all common smart contracts, but then switches to heap-based for "deep call stacks" (which is slightly slower but needed to maintain full compatibility).
• Proactively follow future Ethereum upgrades and AllCoreDev so we have new features starting from the first day when it's available on Ethereum mainnet.

We want to finish this work of Rust EVM 1.0 and fully integrate it into Frontier. The current remaining major work in Rust EVM is testing. Once that's finished we can then begin the integration in Frontier.

Optional PolkaVM support

The Revive project doesn't work, but that does not mean PolkaVM is bad. We know the majority of smart contracts are IO-bound. Still, a small number of them are compute-heavy. We therefore think that an optimal integration of PolkaVM is to simply use it as "pure precompiles". The idea is that smart contract developers continue to write all their business logic in EVM bytecode. At the time when they identified that certain parts are compute heavy, they rewrite only that specific part in Rust, compiled down to PolkaVM, and deploy it as pure precompiles. The business logic smart contract then invoke this PolkaVM precompile as a normal call.

As PoV and other storage IO costs are the major limitations in Polkadot (but not VM performance), we believe this may be the best way to get the best of both worlds (full compatibility + improved performance for compute-heavy contracts).

The PolkaVM support will be designed that it's completely optional. It'll be a separate crate/pallet that you can decide if you want to use it or not. If you don't like PolkaVM, then it's also perfectly fine to ignore it!

We already have basic implementation pallet-evm-polkavm merged into this repo. Our next step would be to clear up a few testing and benchmark issues and write more documentations.

Open maintenance policy

Over the past years, we have added team members from parachain teams with maintenance rights in Frontier. We aim to further continue this policy and invite parachain teams in. The goal is to reduce the bottleneck of PR merging and avoid any possible "single-point-of-failure".

Request for input from the Polkadot ecosystem

If you are a Polkadot parachain or are developing tools for Polkadot, please leave a comment. We would love to hear your feedback and include what's important to you into our Frontier roadmap.

[RomarQ]

I am glad to hear about the roadmap for integrating EVM v1 into Frontier. This has been a concern of mine for some time, as maintaining two separate implementations has been contributing to technical debt.

My main concern moving forward is ensuring that all fixes and features are properly ported from the v0.x to the master branch. (We did this well for the Cancun changes, but we still need to port Pectra EIP's and other fixes to the master branch).

One aspect I am particularly interested about EVM v1 is that we will finally be able to utilize the vector tests from ethereum/tests, which will greatly improve test coverage and consistency.

Additionally, I do like to raise a question: have we explored the possibility of using revm in Frontier? I think the main challenges would be the tracing features and external cost recorders, but it seems like a direction worth considering. What is your opinion on this?

[sorpaas]

Additionally, I do like to raise a question: have we explored the possibility of using revm in Frontier? I think the main challenges would be the tracing features and external cost recorders, but it seems like a rust-ethereum/evm#222 (comment). What is your opinion on this?

I actually really like Paradigm's work, but I also quite excited about evmv1, especially its new architectural design. It would allow us to experiment a lot of things.

I would say we can probably provide both as options, revm and evmv1. Frontier already supports this -- we have the generic Runner trait and the underlying thing can be different EVM engines. revm may lack some customization features (so we may need to cfg compile certain things), but for parachains that don't need them, I agree that it would always be great that there's the option of revm which is the same thing Reth uses on Ethereum mainnet.

Still, evmv1 has certain things which are quite beneficial to us, which just doesn't exist in other EVM engines including revm. For those things I'm still quite excited about. Of course, this time we'll integrate the full compliance test so things should work out well.

[sorpaas]

There's a small additional problem that revm uses alloy, while we use ethereum. This however should be fixable by creating some conversion functions.

[sorpaas]

The Revive team has been adding revm into pallet-revive (basically a complicated reimplementation of Frontier). But based my review of their code, my new conclusion is that it's probably a really terrible idea to use revm instead of evm. The problem lies in the necessary customization (custom gas metering, etc). revm is just not designed for such use cases, and you can see from their code that they have to duplicate each and every instruction implementation to make gas metering customization possible. This will go really bad and is a huge maintenance hell which I think we'll want to avoid.

I do think we'll probably just want Rust EVM 1.0 because it's designed for our use case.

[RomarQ]

That seems too much code duplication indeed, not sure it will be merged like that. The purpose of using revm would be to reduce the maintenance effort for keeping up with new ethereum EIP's.

[boundless-forest]

I read the discussion on the Polkadot forum yesterday and was excited to see Wei returning to Frontier.

As an old member/user of Frontier, we (Darwinia parachain) are one of the projects using Frontier as Darwinia chain's base layer. However, we made some changes to our development direction at the start of this year. We now only keep the most critical pallets on the Darwinia chain and maintain them over time. Our team currently focuses more effort on our new project at the application layer, such as https://github.com/ringecosystem/degov that I am working on. This means I won't be able to contribute to Frontier as much as I did before, but I will still keep an eye on it and support it in any way I can.

[ShankarWarang]

Interesting approach. Glad to see a roadmap for frontier.
My only concern is will there be a permissionless process for the deployment of such pure precompiles? If not, won't the network's upgrade cycle, the maintainers' and community's choices with respect to network upgrades can create a hindrance for the smart contract developers?

[sorpaas]

My only concern is will there be a permissionless process for the deployment of such pure precompiles?

Only permissionless deployment is allowed. :)
Parachain teams can already do "pure precompile" directly in their runtimes. The goal of PolkaVm is just specifically to make this permissionless.

We have a dispatchable EVMPolkaVm::create_polkavm and this is callable by any signed address. We do this as a simple Substrate dispatchable (instead of Ethereum RPC) because normally a PolkaVM contract will be larger than the code blob size limit of Ethereum (so tooling can't work on the other side anyway). The planned usage is Rust->PolkaVM where people can write specific pure precompiles, and then call those precompiles in their EVM bytecodes.

[ShankarWarang]

Amazing. Thanks for the elaboration.