In the technical roadmap of Polkadot, smart contracts have always held a somewhat nuanced position.
It is not absent, but has always been hard to claim as 'easy to use.' Over the past few years, Polkadot has emphasized the development of parachains, multi-chain architecture, shared security, and cross-chain communication—these are foundational capabilities that have rarely translated into an application experience that developers can immediately implement.
The emergence of Revive is precisely to address this long-standing fracture.
Revive is Polkadot's 'next-generation smart contract platform' and a key step for Polkadot toward EVM compatibility + parallel development of native smart contracts.
In Polkadot, EVM compatibility is not about 'recreating Ethereum,' nor is it simply about adding EVM compatibility as a feature, but rather trying to answer a more realistic question: when can Polkadot's smart contracts become the infrastructure that developers are truly willing to rely on long-term?
Recently, Parity provided a clear timeline.
Parity announces Revive Go Live Time
Parity has officially announced the go-live timeline for Revive. However, the specific process will be initiated through governance!
On Kusama, the public vote for runtime upgrades has entered the submission phase, expected to take effect by the end of December;
Meanwhile, on the Polkadot mainnet, the corresponding public vote will be submitted in early January 2026, planned to take effect on January 20, 2026.
https://forum.polkadot.network/t/revive-smart-contracts-status-update/16366
This timing is slightly later than initially expected by a month, but given that Christmas is approaching, a one-month delay is understandable! If it were just to launch as quickly as possible, Revive could have launched a 'working' version long ago.
In the past few months, the majority of their energy has not been spent on adding new features, but rather on refining the underlying details that, if they encounter issues, would directly affect developer trust.
The goal of Revive is to achieve a production environment that can be safely used at launch.
From Parity's updates, in the past few months, they have primarily focused on the following key areas in advancing to the final launch stage.
The focus of Revive's progress during this period
In the past few months, the Parity contract team has focused primarily on one thing: delivering the functions planned in the first official version of Revive completely and stably!
Around this goal, Revive has completed core work at multiple key levels.
First, in terms of execution layers, Revive introduces the REVM backend, enabling the platform to support both EVM and PVM smart contracts, which can collaborate in the same environment. For developers, this means that existing Solidity contracts can be deployed directly without modification, and developers familiar with the Ethereum ecosystem can continue to use their original development tools and workflows without needing to adapt to a completely different system.
In terms of the fee mechanism, the team has completed a highly challenging but crucial task—establishing the mapping relationship from Ethereum Gas to Substrate Weight. Substrate Weight is the underlying mechanism used by Polkadot to calculate execution costs and transaction fees. This mapping model does not simply replicate Ethereum's Gas rules; rather, it ensures that the costs of contracts in the Polkadot execution environment are stable and predictable while maintaining internal consistency.
At the same time, Revive also provides externally compatible block data with Ethereum. This allows infrastructures and applications that rely on block metadata or block inclusion proofs to operate normally in the Revive environment according to existing logic, without needing additional adaptations for underlying differences.
In terms of developer experience, Revive has integrated mainstream Ethereum development tools, including Foundry and Hardhat. At the same time, the team provides a local testing node based on Anvil, using pallet-revive as the actual execution engine, so that developers face a real Revive environment during local testing that is highly consistent with on-chain behavior, rather than a reference chain or simulation system. These tools are currently available for direct use, and future functionality will continue to be expanded and optimized.
Why does it seem to be progressing slowly? Because a lot of time has been spent on verification
If we look only at the time dimension, the progress of Revive is not fast.
But this is not due to a halt in development; rather, significant effort has been devoted to testing and verification. Before launch, sufficient confidence in the platform itself must be established, which can only be achieved through extensive and systematic testing.
Specifically, the work at this stage mainly includes:
First is compatibility testing. The team ran multiple large-scale, widely used Ethereum testing suites, covering tens of thousands of test cases to verify whether smart contracts behave as expected in various scenarios.
Secondly, there is differentiated testing. By comparing Revive’s execution results with Ethereum's reference implementation item by item, the team can identify and analyze behavioral differences between the two early on, avoiding issues from surfacing later.
Finally, there are stress tests and performance benchmark tests. The team tests the platform under high load conditions and measures performance under different execution paths to fully understand the system's operational characteristics in actual use.
These works rarely appear in promotions, yet they directly determine the credibility of the platform after launch. Its core goal is singular: from day one of the launch, developers should be able to trust Revive and obtain stable, consistent, and reliable performance in various usage scenarios.
Elastic scaling will be introduced into the Kusama Hub.
The upcoming Kusama Hub runtime upgrade includes not only Revive, but also Elastic Scaling packaged for launch together. Elastic Scaling is a significant improvement that will enhance the chain's throughput capacity and prepare for shorter block times.
Although the block time will not change immediately upon the enactment of the upgrade, this feature will be enabled shortly thereafter, reducing the block time from 6 seconds to 2 seconds. This will significantly reduce the latency of smart contract execution, especially in DeFi and high-frequency interaction scenarios.
What does the launch of Revive truly mean?
If we look at these changes together, the outcomes of Revive's first phase are actually very clear:
Polkadot finally has a smart contract platform that is friendly enough for Ethereum developers and deeply integrated into its own architecture.
In this version, developers can use the familiar Ethereum toolchain to deploy unmodified Solidity contracts directly; at the same time, Revive also supports smart contracts written in Rust (including ink!) so that the native contract ecosystem can develop in parallel.
More importantly, some 'system-level capabilities' that Polkadot inherently possesses are also brought into the contract world, such as native access to multiple assets and message interaction with other chains via XCM, all of which can be directly invoked in contracts through precompiled modules.
In terms of execution, Revive provides both EVM and PVM execution paths, sharing the same toolchain and infrastructure, allowing different types of contracts to coexist smoothly in the same environment.
Of course, this is just the first step. In the next few months, several important improvements are already being planned. With this infrastructure officially online, the team can iterate and optimize faster based on real usage scenarios and community feedback.
More importantly, what will happen next?
The significance of Revive does not lie in a statement of 'Polkadot also has EVM now.'
And, Polkadot is elevating smart contracts from a 'supplementary capability' to a core gateway connecting developers, applications, and ecological value.
Now, this entrance is about to open. What will be truly worth observing next is the choices in reality:
Which applications will migrate over?
Which new projects will start directly from Polkadot?
Which past ideas that were unfeasible due to cost, complexity, or performance will start to become viable?
The answers to these questions will not be written in blogs or announcements, but will only appear in real usage and ecological feedback.
PolkaWorld will continue to follow up.
PolkaWorld Telegram group: https://t.me/+z7BUktDraU1mNWE1
PolkaWorld Youtube channel:
https://www.youtube.com/c/PolkaWorld
PolkaWorld Twitter:
@polkaworld_org
