Major Milestone for Solidity Smart Contracts: First Part of the Preview Release Now Live on Kusama

Ecosystem
,
1

Hello Polkadot community,

Following up on the smart contracts update earlier this year, I’m excited to announce a major step toward bringing Ethereum-compatible smart contracts to Polkadot Hub: part 1 of the Solidity on PolkaVM smart contracts preview version is now live on Kusama.

We invite the community to start testing functionality by:

  • following our new smart contracts documentation and tutorials;

  • deploying initially on the testnet (Paseo), and optionally then to Kusama; and

  • letting us know your feedback and developer experience so we can improve for the Polkadot launch.

1. Part 1 of Solidity Smart Contracts Launched on Kusama

Smart contract functionality is being released in parts. Part 1 was released on Kusama on 24 June 2025 as part of the v1.6 upgrade.

Note that in each release stage we will provide an update with specifics on the functionality, compatibility and integrations available at that time.

June 2025: Part 1 of Preview Release on Kusama

  • Part 1 of the preview smart contract functionality with Solidity support / Ethereum compatibility has launched on Kusama.

  • The release already works with familiar Ethereum tooling (Remix, Hardhat) and has integration with popular libraries.

  • Please note that this is the preview version and there are some known issues (see FAQs in the documentation for more information):

    • Known incompatibility issues with Ethereum wallets and some other applications that don’t pass the gas estimation as-is. This will be fixed with the release of the next part. In the meantime we recommend using Hardhat to compile, deploy, and interact with smart contracts.

    • Our current compiler produces smart contracts that are larger than typical EVM bytecode, which can lead to hitting size limits. We are addressing this by raising memory limits, improving memory management, and optimizing the compiler. These efforts are already in progress, but you may still encounter size constraints in the meantime.

  • Your testing and feedback will be invaluable for helping refine these before launch on Polkadot Hub - see below for how to share your findings.

2. Invitation: Start Testing Now!

Start experimenting and provide feedback on part 1 of the preview version of the Ethereum-compatible PolkaVM stack.

  • Test deploying with PolkaVM: Use the testnet (Paseo) for the most up-to-date stable version, or Kusama to deploy in a live environment. Last week we published comprehensive, up-to-date smart contracts documentation - thank you to the Papermoon team for this fantastic work.

  • Share your feedback: Submit your insights here to make sure we can understand your experience with smart contracts and the documentation and address your findings.

  • Log any bugs: Report any bugs you find directly to the contracts team here in GitHub.

  • Get support: Live chat developer support is on Discord (#solidity-smart-contracts channel), with best effort support on Telegram.
    ​

Deploying to the testnet

To deploy to the testnet (Paseo), please follow the steps outlined here in the documentation.

Note: as outlined in the update regarding testnets earlier this month, this testing environment is a second, temporary Preview Asset Hub (“Passet Hub”) chain on the testnet (Paseo) to use for testing before smart contracts land on Polkadot.

  • We’ll push smart contract updates to “Passet Hub” as and when they are stable, so you will have access to features here earlier than on both Kusama and Polkadot.

  • “Passet Hub” is additional to the testnet’s main Asset Hub chain, which has the same runtime as Polkadot’s Asset Hub.

  • Once smart contracts are fully live on Polkadot Hub (and the testnet Asset Hub), “Passet Hub” will be decommissioned and documentation updated. Please note contracts will not be migrated.

Deploying to Kusama

Please note that the most recent version of our Ethereum-compatible stack is available on the testnet.

However if you wish to deploy in a live environment, you can deploy to Kusama Hub as follows:

Important notes for deploying on Kusama

While we are still maximizing compatibility, we recommend you:

  • use HardHat to compile, deploy, and interact with your contract
  • use Metamask to interact with your dApp. Note that using Metamask can sometimes lead to “Invalid transaction” errors. We are actively working on fixing this.

If you use REMIX to deploy, be aware that Metamask enforces a 48kb size limit. This is why we recommend HardHat for deployment.

3. Next steps

The preview release will be completed with the addition of part 2 (coming soon), which includes:

  • Additional precompiles for basic cross-chain messaging (XCM) and ERC 20 interfaces.

  • Further tooling improvements, e.g. with OpenZeppelin templates and basic Foundry functionality.

At this time, we will also share with you our roadmap for improving compute performance and reducing latency, as well as exciting integrations.
​

GTM and Comms activity

  • To support the launch of smart contracts, there are BD activities and hackathons already underway for targeted user testing and feedback.

  • In the coming months we are ramping up communications and marketing activities, e.g. speaking engagements and comms campaigns, especially around milestone launches and the Polkadot Hub 2.0 launch.

4. Terminology

We welcome and appreciate everyone who wants to help promote this launch. Those who know me know that I am particular about terminology :innocent: . Here are a few guidelines that I believe will improve clarity and set us up to communicate our advantages over competitors:

  • Ethereum vs. EVM Compatibility: We should describe our stack as being “Ethereum compatible”. Since we are using the RISC-V based PVM, we cannot execute bytecode meant for an EVM. However, our compiler and RPC interfaces make us compatible with Ethereum languages (like Solidity), developer tooling (like HardHat), and user interfaces (like MetaMask). We should avoid the term “EVM” because we want to highlight all of the advantages (especially in compute performance) of PVM, and talking about two VMs adds confusion.

  • Polkadot Hub vs. Asset Hub: While Asset Hub is a single parachain, Polkadot Hub is a product and larger concept. Polkadot Hub includes all the functionality and user journeys that one can use the DOT token for. These include setting identity, participating in staking, being in a collective, and deploying a smart contract. And these user journeys can take place across many parachains. Asset Hub, the parachain, is simply one component in the larger system and should not be exposed to users or marketed. When talking about Polkadot Hub, communication should treat it as a product / system, and not a chain. One of our main goals with Polkadot Hub is to improve developer and user experience by abstracting the individual chains for most use cases.

1600×1387 210 KB

5. Points of Contact

  • Technical project management and delivery: Jan-Jan @jan-jan, Torsten @torsten, and Parity’s Runtime engineering department (led by me).

  • BD / GTM (including financial integrations): W3F-led working group lead by Alex @alexdimes, further info here.

  • Product launch coordination and delivery: Parity’s Product Engineering department PMs (Cyril @Cyr06130 and Rebecca @Ser.Otto). Additional specific responsibilities are:

    • DevRel coordination:

      • Documentation: Papermoon @albertov19

      • Developer outreach: EcoDev working group (W3F @Radha, Parity, Papermoon, Web0, Dev Cult (Denis P @TriplEight and Daniel A), Easy A, Encode, OpenGuild, etc.)

    • Comms and marketing (e.g. events, campaigns, wider outreach): Distractive @nateham1, Parity, W3F.

30 Likes
2

This is fantastic news! Huge congratulations for hitting this milestone. Big kudos also for the excellent collaboration with the mentioned ecosystem teams, this is how we build great things together. :star_struck:

5 Likes
3

Absolutely insane that whoever designed this didn’t consider the implications of breaking create/create2 among other invariants. It’s literally used by every Ethereum project and defi protocol. I’m not sure if there is a major project out there not using a create2 factory.

4

This is exactly the kind of detailed feedback we’re hoping to gather with this preview release. The team is actively looking into ensuring the best possible compatibility and developer experience.

Could you please share your observations/specific use cases you’re concerned about via our feedback form that Joe shared in his post? Thank you!

2 Likes
5

Hi @0xTaylor

Thanks for your input. We have actually taken the requirements from preliminary (DeFi) dApps on how specific codebases are being implemented, and thought about addressing according to Solidity SCs in Polkadot.

To our knowledge, “create/create2” are needed because dApps need to be able to deterministically resolve pool addresses without actually asking the chain.

PolkaVM’s workaround is set in a following way:

While addresses are still deterministic, contracts in PVM work in a way that a contract can’t upload code; A transaction has to do it.

The “create2” references the code by hash.

So the idea is to bake the upload into the tooling, so whichever contract contains the “create2” instruction has the initcode baked in.

In short, it is static anyways, so whatever transaction deploys that contract would also upload the code, its just not bundled into the contract.

I am not an Engineer (Joe mentioned my involvement via BD/GTM), but this is mostly what Parity engineers (with help from Papermoon team) has communicated with external partners (dApps) targeting the deployment via Solidity SCs on Polkadot.

What I can also add to this, is that we already have an exhaustive list of compatibilities the teams are diligently working on. But only that, using Passet Hub and Westend to practically test these in the coming weeks/months, according to specific deployments in Ethereum world.

So we’re doing everything we can to handle those and provide an “Ethereum-like” Dev-Ex.

1 Like
6

If I have to fill out a 3 page form for someone to realize what a bad idea it is to not have full support for create2, we are in trouble.

7

Point taken. We’re looking at ways to make providing qualified feedback easier, or a more streamlined option for folks who are very short on time or have a very specific or critical point to make. (fyi @Ser.Otto )

It helps our TPMs to have all the feedback in one place to rank/compare with other requests or feedback coming from partners, builders, hackathon participants etc.

For this specific case though, the team is aware and we’re working on it. In the meantime, I’m personally really looking forward to some nice contracts that will be deployed on Kusama! :nerd_face:

2 Likes
8

Heya, PM at Parity here, thanks heaps for this feedback to help optimise and it’s great to get points that we can look further into.

Just to reassure you we are also (doing our best to) collect all feedback shared here, on Discord, through conversations, on Element, in various Telegram chats, etc. etc. as well as through the feedback form.
(The form is a prompt to make sure we are hearing from people trying out our tech, but is not the only channel possible to talk to us through.) :slight_smile:

I’ve added your feedback into the contracts issues tracker (also linked above and in the feedback form) so it’s in front of the devs working on this. :slight_smile:

1 Like
9

Create(2) does work. Most of the factories out there will work. Those are the common ones which just deploy a bytecode they contain.

It’s just factories that to use EXTCODECOPY to construct EVM code at runtime which will fail. The reason is that they operate on EVM byte code directly. The assumption is baked in and written in assembly. There is no way to make this work when your actual byte code is not EVM. It is a necessary evil in the name of progress.

So you see, it was considered. I am not insane. Probably.

2 Likes
10

Using EXTCODECOPY looks very unsafe (loading dynamically code at runtime is unsafe). It’s usage is discouraged in Ethereum land.

I dont think it is widely used. Is that correct?

11

We have ran into the EXTCODECOPY problem as some ZK to solidity use this to copy the ZK verifer key from one contract to another, but decided to bake in the code that’s being copied into one bigger file. Compile with resolc · Issue #1 · BigTava/kusama-shield-verify · GitHub

1 Like
12

My assumption is that it is rare.

  • Nothing in OpenZeppelin is using this opcode
  • EXTCODECOPY is also unsupported in zksync

Building code at runtime cannot be supported on a platform that uses a different arch. But those tricks are used to work around the lack of on-chain constructors and size issues that arise from the factory contract having to contain the full deployees code.

Problems that just don’t exist on our platform. Naive factory contracts just work since they only contain the hash of the deployee.

2 Likes
13

It is used in some of the Solady libraries Code search results · GitHub - The erc6551 reference implementation also uses it Repository search results · GitHub(&type=code

Used in the uniswap utilities contract: util-contracts/src/ERC7914Detector.sol at 2b163a0f9eac0aa49c12bfd4effa36f04193f9bb · Uniswap/util-contracts · GitHub

Used in the Wildcat protocol: https://github.com/search?q=org%3Awildcat-finance%20extcodecopy&type=code

That’s just spot checking some large Defi products.

14

Of course you find some contracts who do use it. Everything that is available will be used by somebody.

But the point is:

  • There is no way to support this without adding an EVM backend.
  • It is super complicated code to work around the lack of on-chain constructors. It can be replaced with a one liner of Solidity. I don’t think anybody enjoys fiddling with assembly in security critical code.
2 Likes
15

How to send Kusama to metamask address?

1 Like
16

telegram-cloud-photo-size-5-6280495703478355128-y
telegram-cloud-photo-size-5-6280495703478355128-y1280×690 36.7 KB

Hi @joepetrowski @Karim @niklabh @Ser.Otto @pierreaubert @RustSyndicate

:police_car_light: We’re pleased to announce that the Kusama Asset Hub is now live on thirdweb.com — listed under Thirdweb’s free integration package.

:backhand_index_pointing_right: Check it out: Kusama Asset Hub: RPC and Chain Settings

But we’re not stopping there.

We’re currently working to secure Thirdweb’s full developer support for Kusama, which would unlock:

:unlocked: Account abstraction – smart wallets, gasless UX

:credit_card: Credit card payments – yes, real-world onramps

:hammer_and_wrench: InSite – no-code smart contract deployment for launching on Kusama in minutes

Once enabled, this gives Kusama the full EVM dev toolkit — unlocking fast, accessible, and production-ready dApp deployment.

:ballot_box_with_ballot: We would love your support if you see value in our current proposal:

https://kusama.subsquare.io/referenda/542

Expect chaos. Kusama-style.

17

You can use this to convert you address from Metamask to Kusama: Substrate JS Utilities
Then you need to teleport them to “Kusama AssetHub” into that address.

1 Like
19

Thanks for the update, @joepetrowski, the early feature access on Passet Hub is very exciting!

One question I’ve been getting quite frequently from developers: is it currently possible to deploy smart contracts that interact with precompiles for the assets pallet and/or for cross-chain functionalities? I’ve searched around but haven’t seen any mention of these capabilities being available yet.

Are these precompiles deployed on Passet Hub or westend-ah, or is there an ETA for their availability? These are pretty crucial building blocks for many potential use cases, and a bit of clarity here would go a long way :folded_hands:

1 Like
20

Heya Josep! Just saw this q here as well so linking my reply on the other thread in case any other readers are curious.

1 Like
21

Not yet. But stable2507 will be released any day now. PassetHub will then support XCM and Asset pre-compiles.

3 Likes