Over the past few years, many have had an enduring question about Polkadot: 'The technology is strong, but where exactly do the applications run?'
Consensus, security, and cross-chain; these are issues that Polkadot has long since resolved; but at the most critical 'execution layer', it has long been in a state of misunderstanding and underestimation — EVM feels like an add-on, contracts feel like guests, and the real execution rules are scattered across different parachains.
The emergence of Revive has changed this for the first time.
It's not as simple as 'Polkadot can also run EVM', but rather Polkadot is officially reclaiming the execution layer back into the protocol's main stack:
Making EVM no longer a compatible module, and PolkaVM (PVM) not just a future concept,
Allowing all transactions, contracts, assets, and governance to start operating collaboratively under the same execution rules.
If you've always wanted to understand:
👉 Is Polkadot's EVM truly 'Ethereum-level'?
👉 What does the launch of PVM mean?
👉 Why is this the first time Polkadot's execution layer is 'truly systematic'?
So, this major upgrade of Polkadot Revive is worth a serious look.
Before discussing the latest developments in Polkadot, we need to clarify a concept that can easily be confused. What Polkadot refers to as the 'execution layer' does not only refer to the execution environment of smart contracts.
In the context of Polkadot, it refers to the unified mechanism of how all transactions and state changes—whether transfers, governance, staking, or contract calls—are executed, billed, and combined with other computing environments, all within the same execution layer.
In the past, Polkadot achieved high unification in the consensus and security layers, but the execution layer has long presented a fragmented state: different parachains implement their own execution logic, and EVM is merely a 'hosted' type of contract environment, rather than a protocol-level system capability.
This is the root of the problem.
How is Polkadot's EVM execution environment actually implemented?
Some may question whether it is difficult to implement EVM on Polkadot? Let's first dispel this misunderstanding.
Polkadot is not building 'another EVM public chain'; it is constructing a unified execution layer capable of accommodating multiple VMs (virtual machines). It's a bit like skipping MVP and directly advancing to the professional version.
In the framework envisioned by Polkadot, EVM will not run independently but must share the same address space, calling model, and resource system with PolkaVM (RISC-V), governance/assets/staking runtime primitives, and XCM multi-chain capabilities.
This means Polkadot needs a VM that the entire industry has never done before: it must become a hexagonal warrior in a multi-VM world, rather than a subordinate compatible module.
To empower itself to realize its envisioned capabilities, Polkadot introduces a new contract execution stack—Revive.
Note that Revive is neither a chain nor a simple EVM module; it is the core framework of the Polkadot execution layer. It can support two sets of virtual machines in the same environment:
REVM: A Rust EVM engine developed by bluealloy, providing complete Ethereum semantics and ETH-RPC support;
PolkaVM (PVM): A high-performance VM based on RISC-V, which will be the main force for future multi-language and heavy computational applications.
The specific role of Revive is to coordinate execution between these two VMs, unify gas/weight billing, access on-chain state, and expose a consistent entry point to RPC and toolchains through pallet-revive.
This is the first time Polkadot has incorporated the 'execution layer' into the protocol itself, rather than outsourcing it to parachains.
However, the most critical part is still REVM. It is not the VM inside Revive, but the external Rust EVM engine we mentioned, which has been deeply integrated into Revive by Polkadot, allowing Solidity contracts to achieve Ethereum-level semantic consistency, toolchain support, and a complete debugging experience, while still being interoperable with PVM and runtime primitives.
This makes the execution layer story of Polkadot truly begin to become convincing.
The following diagram visually explains Polkadot's latest VM compatibility strategy.
To what extent has Polkadot's EVM execution environment been upgraded now?
This has been discussed since the end of 2024, with many people thinking it's still at the PPT stage. But by the end of 2025, the overall completion of the execution layer has far exceeded most people's imaginations. Technical elites should look directly here: https://github.com/paritytech/polkadot-sdk/pull/10552
1. Execution Semantics
Definition explanation: A complete set of rules defining how a piece of contract code is executed on-chain and what precise behaviors it will produce.
In the Polkadot SDK, a whole set of upgrades around pallet-revive has been systematically introduced to the main stack, including the REVM backend, Ethereum-style block storage, ETH-RPC behavior, and trace infrastructure. These changes give Kusama and the upcoming Polkadot Hub execution semantics close to that of Ethereum's mainnet, rather than being a compatibility layer or simulation logic. Polkadot's EVM execution environment possesses the underlying capability of 'semantic-level alignment with Ethereum.'
2. Block Model
Definition explanation: What kind of blocks these transactions are packaged into, what they look like externally, who consumes them and how.
In the past, the blocks seen on ETH-RPC on Polkadot were not true Ethereum Blocks in the real sense, but rather derivative views of Substrate blocks, making it impossible for wallets, indexers, and rollup tooling to seamlessly connect. This upgrade has implemented a complete Ethereum-style block storage layer (Ethereum Block Storage) in the main stack, allowing Polkadot Hub to no longer just 'look like an EVM environment,' but to provide a true Ethereum Block in the protocol's main stack, and to offer Ethereum-style block storage and full ETH-RPC behavior in the protocol's main stack, enabling existing wallets, indexers, and rollup tools to almost directly connect.
3. Gas / Weight Model
Definition explanation: How a chain uses a set of numbers to clarify 'how much on-chain resource you used and how much you need to pay.'
Polkadot is not a single VM Layer1; it must handle three completely different cost systems simultaneously:
Substrate weight (two-dimensional measurement): distinguishing ref_time from proof_size
Storage deposit: on-chain occupancy cost charged by byte
EVM gas: the only billing method understood by Ethereum toolchains and wallets
The core achievement of this round of upgrades is the establishment of a Generalized Gas Mapping in pallet-revive. Simply put, Polkadot has solved the problem of 'how to still present standard Ethereum gas under a multi-VM + multi-resource system,' making EVM truly usable within the Polkadot ecosystem. There is also scalable space reserved here: reserved gas scale/conversion, providing interfaces for future JAM/PolkaVM multi-VM collaborative billing.
4. Development Experience
Definition explanation: You only know when you use it~
With the ongoing upgrades of pallet-revive and ETH-RPC, the overall development experience of Polkadot has also been greatly enhanced. These capabilities allow Solidity teams to almost directly continue using their existing Foundry/Hardhat toolchain, simply by switching the RPC endpoint to Polkadot Hub. The migration cost has been reduced from 'rebuilding a development workflow' to 'changing an RPC address,' which is a crucial step for EVM to be truly feasible.
What do I want to express?
Regarding the upgrade around Revive, the truly important point is not that 'Polkadot can also run EVM,' but that Polkadot has embedded its own execution layer into the protocol's main stack for the first time in a complete form. The execution semantics strive to align with Ethereum, the block model has been standardized, and the gas system has unified mapping, while the foundational coexistence of multiple virtual machines has also been established.
From now on, Solidity developers only need to switch a single RPC endpoint to deploy applications on a network with stronger composability and higher performance ceilings. For Polkadot, the narrative has also upgraded to 'multi-VM open computing platform': simultaneously hosting EVM, PolkaVM, and more VMs in the same network, allowing them to cooperate.
The execution layer story of Polkadot has just begun, and the narrative space of the future is much larger than just an 'EVM-compatible layer.'
PolkaWorld Telegram group: https://t.me/+z7BUktDraU1mNWE1
PolkaWorld Youtube channel:
https://www.youtube.com/c/PolkaWorld
PolkaWorld Twitter:
@polkaworld_org
