# Release of smart contracts on Polkadot **URL:** \ **Category:** Tech Talk\ **Created:** [January 27, 2026, 5:53pm UTC](https://forum.polkadot.network/t/release-of-smart-contracts-on-polkadot/16848 "2026-01-27T17:53:23Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![torsten](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/torsten/32/9358_2.png) [@torsten](https://forum.polkadot.network/u/torsten)\ **Post date:** [January 27, 2026, 5:53pm UTC](https://forum.polkadot.network/t/release-of-smart-contracts-on-polkadot/16848/1 "2026-01-27T17:53:24Z")
And we’re live! As of today, the Revive smart contract functionality has been released on Polkadot. This initial Polkadot release focuses on correctness and reliability. Revive supports smart contracts running either on the EVM for full Ethereum compatibility or on Polkadot’s novel PVM for maximum performance. Developers can use familiar Solidity workflows or write Rust-based contracts, depending on their needs. All type of contracts are fully interoperable. Polkadot Hub provides a solid, production-grade smart contracts platform: low latency, fast finality, access to assets and cross-chain messaging via precompiles, and both EVM and PVM execution paths are available with shared infrastructure. 👷 [Start building](https://docs.polkadot.com/smart-contracts/get-started/) There are areas we plan to expand and optimize in upcoming releases, particularly around performance and tooling, but having this foundation live allows us to iterate based on real-world usage. For developers considering where to deploy next, this is a good point to start kicking the tires and providing feedback. We’ve published a short overview that outlines what’s available today and how the pieces fit together: 👉 [Why Developers Should Deploy Smart Contracts on Polkadot](https://www.parity.io/blog/why-developers-should-deploy-smart-contracts-on-polkadot) Hands-on testing and practical feedback will be incredibly valuable as we move into the next phase. Please share any feedback on our tester form [here](https://forms.gle/XRVged1eaL3yVTTg7). I want to thank the community for its patience, positive outlook, and willingness to help with testing. This is the start of a simpler, more attractive developer experience on Polkadot. Tell a friend, tell your leader, tell the world! Native smart contract functionality on Polkadot is here. ---
**Author:** ![seunlanlege](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/seunlanlege/32/285_2.png) [@seunlanlege](https://forum.polkadot.network/u/seunlanlege)\ **Post date:** [January 27, 2026, 9:00pm UTC](https://forum.polkadot.network/t/release-of-smart-contracts-on-polkadot/16848/2 "2026-01-27T21:00:09Z")
This release while truly monumental still presents a few DX problems for developers. We’re already playing with contracts on testnet and we’ve experienced a few issues. 1. Still can’t deploy legacy transactions with hardcoded gas prices/gas limits Eg. [https://github.com/Arachnid/deterministic-deployment-proxy](https://github.com/Arachnid/deterministic-deployment-proxy) 2. The Eth rpc sidecar should be unified behind the same rpc endpoint for the substrate rpc endpoint. Having to run a seperate binary means more overhead for rpc providers who will most likely not run the side car 3. Transaction receipts seem to be ephemeral if even available. And you can see the consequences of this on the testnet explorer [https://polkadot.testnet.routescan.io/tx/0xf41a36f6578f3771a270cd6db23da30d86ee75e38af77747427377f75f32c879](https://polkadot.testnet.routescan.io/tx/0xf41a36f6578f3771a270cd6db23da30d86ee75e38af77747427377f75f32c879). Some txs no longer have a transaction details page. I don’t think theres any reasonable “optimization” for an ethereum chain to not serve transaction receipts for any reason whatsoever 4. Contract verification is also broken on foundry. It seems routescan doesn’t support verifying contracts on Polkadot testnet. These are just the few issues we’ve discovered at Polytope Labs. Once fixed, I believe will put asset hub in a position to properly compete in the Evm landscape. Hoping these issues get fixed soon! ---
**Author:** ![pgherveou](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/pgherveou/32/1416_2.png) [@pgherveou](https://forum.polkadot.network/u/pgherveou)\ **Post date:** [January 30, 2026, 4:20pm UTC](https://forum.polkadot.network/t/release-of-smart-contracts-on-polkadot/16848/3 "2026-01-30T16:20:56Z")
Thanks @seunlanlege for the feedback > [@seunlanlege](#): > > Still can’t deploy legacy transactions with hardcoded gas prices/gas limits Eg. [GitHub - Arachnid/deterministic-deployment-proxy: An Ethereum proxy contract that can be used for deploying contracts to a deterministic address on any chain.](https://github.com/Arachnid/deterministic-deployment-proxy) @torsten answered [here](https://github.com/paritytech/contract-issues/issues/263#issuecomment-3818743276), We have a PR for Nick’s method that was merged [here](https://github.com/paritytech/polkadot-sdk/pull/10476) but unfortunately given the difference in gas model, this won’t work if the transaction strongly limits both the gas and the gas price. > [@seunlanlege](#): > > The Eth rpc sidecar should be unified behind the same rpc endpoint for the substrate rpc endpoint. Having to run a seperate binary means more overhead for rpc providers who will most likely not run the side car Until now, to iterate fast , it was easier to have the RPC outside of the client, but indeed we should consider merging it into the client now that it’s more feature complete. > [@seunlanlege](#): > > Transaction receipts seem to be ephemeral if even available. And you can see the consequences of this on the testnet explorer [https://polkadot.testnet.routescan.io/tx/0xf41a36f6578f3771a270cd6db23da30d86ee75e38af77747427377f75f32c879](https://polkadot.testnet.routescan.io/tx/0xf41a36f6578f3771a270cd6db23da30d86ee75e38af77747427377f75f32c879). Some txs no longer have a transaction details page. I don’t think theres any reasonable “optimization” for an ethereum chain to not serve transaction receipts for any reason whatsoever the eth-rpc needs to be configured with a [database\_url or env setting](https://github.com/paritytech/polkadot-sdk/blob/8807c22f2a3507af2401e99a8c420f68e0ce7dfd/substrate/frame/revive/rpc/src/cli.rs#L58-L62) to maintain a permanent index, it also needs to point to an archive node if there is a need to fetch old receipts. This is probably mis-configured here, we will look into it and fix this. > [@seunlanlege](#): > > Contract verification is also broken on foundry. It seems routescan doesn’t support verifying contracts on Polkadot testnet. We will check it out 👀