Author: Yuki, PaperMoon
In the blockchain world, most developers are still using familiar tools: writing contracts in Solidity, deploying and testing with Hardhat, and debugging interactions with MetaMask. However, beneath these familiar operations, a reconstruction of the underlying architecture is quietly happening.
Polkadot has recently launched a new generation of smart contract execution environments—PolkaVM. This is not a minor patch to the traditional virtual machine but a complete re-design of the execution logic from the ground up. It abandons the outdated stack-based model in favor of a register design based on RISC-V architecture and supports more detailed resource billing and future scalability.
These changes are almost 'imperceptible' to application developers. However, from a technical perspective, they constitute a fundamental evolution of the on-chain execution system.
This article will attempt to answer three questions:
What exactly is PolkaVM, and what has it changed?
Why is reconstructing the virtual machine not redundant?
What does this 'invisible upgrade' mean for developers and future applications?
What is PolkaVM?
PolkaVM is a virtual machine based on RISC-V architecture developed by Parity Technologies, aimed at providing a high-performance, scalable, and secure smart contract execution environment for the Polkadot ecosystem. The project is still in active development and has recently been launched on the Westend test network. The PaperMoon team recently tested PolkaVM—running Uniswap V2 on it.
In the blockchain industry, Uniswap has become one of the most common standardized AMM protocols. It is deployed on most EVM chains, has high logical complexity, and intensive inter-module interactions, making it a common choice for verifying the usability and compatibility of new chain execution environments. In early 2025, Uniswap V2 was fully deployed on a virtual machine with a completely different architecture: Polkadot's PolkaVM.
PolkaVM's underlying architecture is completely rewritten using RISC-V, but the development interface and toolchain remain compatible. Therefore, developers can continue to write contracts in Solidity and use existing Hardhat, Remix, and MetaMask for development, deployment, and testing without changing their workflow.
On the surface, there seems to be little change: the process of deploying applications is almost the same as on EVM chains, but behind this seemingly 'ordinary' migration lies an important signal: PolkaVM is no longer reliant on the technical stack of the EVM route, but attempts to provide a foundation for complex contracts from the ground up with a completely new architecture.
This deployment is more like a reality check: PolkaVM has moved beyond the testing logic or running simple contracts phase and has crossed the first standard line of 'complex contract usability'.
In-depth reading (Why did both Polkadot and Ethereum choose RISC-V seemingly independently?)
Why 'rewrite the virtual machine'?
Ethereum's EVM is the core engine driving the explosion of first-generation on-chain applications. It has established a stable, universal standard for smart contracts and has given rise to a large and active developer ecosystem.
However, as the complexity of on-chain applications continues to rise, EVM has gradually revealed challenges in terms of scalability at the architectural level. For instance, its stack-based execution model does not fully align with modern hardware operation; the current language support mainly focuses on Solidity, which imposes certain limitations on multilingual expansion; and in terms of formal verification and automated security guarantees, EVM's original design has not adequately reserved for such needs.
Most public chains' strategy is to continue to be compatible with EVM while adding optimization layers or functional modules on top of it. This path lowers the migration threshold while retaining the usability of the original toolchain.
PolkaVM chooses a completely new approach: attempting to redesign the underlying logic around 'servicing more complex and diverse on-chain applications' without relying on the existing technical route.
Core differences between PolkaVM and EVM
Although PolkaVM employs a completely new architectural logic at its core, it still supports Solidity at the development interface level, as well as mainstream tool stacks including Hardhat, Remix, and MetaMask.
This compatibility is not due to accommodation but is based on considerations of the actual usage paths of developers. The continuity of the toolchain means that projects can gradually migrate to a better underlying architecture without changing their workflow.
In other words, PolkaVM has chosen a more pragmatic engineering path: allowing changes to the execution engine while preserving the certainty and familiarity of the development process.
Looking back, the success of deploying Uniswap V2 on PolkaVM does not stem from it being a technically challenging application, but from its ability to run smoothly in a new execution architecture as a real, structurally complex contract system with frequent component interactions. PolkaVM is transitioning from design philosophy to engineering implementation.
Below is a comparison table to help you visually understand: What are the similarities and differences in deploying Uniswap V2 on PolkaVM versus traditional EVM?
The significance of PolkaVM: compatibility with the present, oriented towards evolution.
In recent years, the blockchain world has never been short of new chains and new virtual machines. Many projects have explored keywords such as 'faster execution', 'modular architecture', and 'multilingual support'. However, most attempts still remain in the testing network, demo, or developer preview stages.
From the design stage, PolkaVM also considered the extensibility for future scenarios— including LLVM compilation support for multiple languages like Rust and C, as well as reservations for zero-knowledge proof (ZK) friendly structures. Rather than being a replacement for existing systems, it serves as a foundation for more complex contracts and richer application scenarios.
The deployment of Uniswap V2 is not a showcase of technology but rather a real-world test: PolkaVM has moved beyond theoretical design and is capable of supporting the production operation of real complex contract systems.
These changes are visible to developers: faster execution, clearer structure, and lower costs.
And for end users, they may not directly perceive what is happening underneath. But it will slowly translate into a sense of 'smoothness' in daily use—transactions respond faster, gas costs are more transparent, failure rates have decreased, and the overall experience is more stable.
This is the significance of infrastructure evolution: not to make people aware that technology has upgraded but to make the experience more reliable without them realizing it.
PolkaVM is not a one-time breakthrough but the beginning of a system update. Its compatibility is not merely for the sake of convenient migration but aims to provide developers with a longer-term, more sustainable execution path—from today's Solidity to future multilingual and ZK contracts, there is ample architectural space to accommodate them.
If you are interested in the bytecode design, compilation pathways, and the workings of the revive tool behind this architecture, we will soon launch a more in-depth series of developer interpretations, so stay tuned.
Disclaimer
The materials provided by PaperMoon and included in this article are for educational purposes only. They do not constitute financial or investment advice and should not be interpreted as guidance for any business decisions. We recommend that readers conduct independent research and consult professionals before making any investment or business-related decisions. PaperMoon assumes no responsibility for any actions taken based on the content of this article.