# Contracts Update: Solidity on PolkaVM **URL:** \ **Category:** Tech Talk\ **Tags:** smart-contracts\ **Created:** [March 21, 2024, 3:08pm UTC](https://forum.polkadot.network/t/contracts-update-solidity-on-polkavm/6949 "2024-03-21T15:08:32Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![Cyrill](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/cyrill/32/7339_2.png) [@Cyrill](https://forum.polkadot.network/u/Cyrill)\ **Post date:** [March 29, 2024, 12:22pm UTC](https://forum.polkadot.network/t/contracts-update-solidity-on-polkavm/6949/5 "2024-03-29T12:22:05Z")
Thanks for the feedback! > This specific PolkaVM-specific Solidity dialect should get its own name, like “P-Solidity”, with a versioned specification [of its own RISC-V assembly, cryptographic computations, whether feasible or not]. By using `solc` as the compiler front-end we do hope to get away without introducing a Solidity dialect. We’d specify what either works differently (at runtime) or is not supported. The goal is that a vast majority of dApps shouldn’t notice and work fine without code changes. The largest deviation will be how deployments work. However this only affects the developer side of it and can be worked around with tooling. For users (anyone just doing regular calls), existing tooling, wallets etc. will just work given we also add compatible RPC (which we could). However, I expect a vast majority of features to just work. The [relevant ZKSync doc section](https://docs.zksync.io/build/developer-reference/differences-with-ethereum.html) should give you a good taste as most of it applies to our case too. > I’m not sure it even needs an RFC… In priniple, you could even link together contracts written partially in EVM and partially in Rust. It’s purely a matter of dev tooling, but the chain won’t care. Yeah for the runtime and chain, the contract Language is fully opaque. A Solidity contract can call anything as long as the callee respects the Solidity ABI encoding (hypothetical the same would apply for dynamic linking). We want to provide ETH precompiles though. > As the Relay Chain is not suitable for smart contracts, I would like to see _system chains_ (specifically AssetHub) incorporate the `contracts` pallet I do agree! I’ve collected and published [ideas and thoughts around it here](https://forum.polkadot.network/t/hybrid-system-chains-to-make-polkadot-permissionless/7089) 🙂 > What is the best vs worst case timing of inclusion for this? I think the sooner we push it to Kusama the better, starting with AssetHub first until other system chains are available. We just need to make sure to not introduce any new attack vectors. > I have closed [RFC #66](https://github.com/polkadot-fellows/RFCs/pull/66) in the expectation of resubmitting it as soon as `contracts` pallet is sufficiently mature – when could that be? I don’t think we need to wait any longer as I don’t expect this final runtime to diverge much from `contracts` as it is today (after all, it is modeled after Ethereums contracts model and already highly compatible). Even if a couple things wind up differently in the end, shipping `contracts` as it is today paves the way and makes this a more incremental process overall 🙂 --- _[View the full topic](https://forum.polkadot.network/t/contracts-update-solidity-on-polkavm/6949)._