# Update on \`cargo-pvm-contract\`: a Rust SDK for smart contracts **URL:** \ **Category:** Tech Talk\ **Tags:** smart-contracts\ **Created:** [June 17, 2026, 10:28am UTC](https://forum.polkadot.network/t/update-on-cargo-pvm-contract-a-rust-sdk-for-smart-contracts/17896 "2026-06-17T10:28:49Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![smiasojed](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/smiasojed/32/2667_2.png) [@smiasojed](https://forum.polkadot.network/u/smiasojed)\ **Post date:** [June 17, 2026, 10:28am UTC](https://forum.polkadot.network/t/update-on-cargo-pvm-contract-a-rust-sdk-for-smart-contracts/17896/1 "2026-06-17T10:28:50Z")
# Update on `cargo-pvm-contract`: a Rust SDK for smart contracts `cargo-pvm-contract` is a Rust toolchain for writing smart contracts that compile to PVM and run on Polkadot through `pallet-revive`. The project has been in active development for a while and has reached a point where it’s worth sharing a public progress update. ## What it is Two authoring flavours, same host ABI: - **macro** - annotated Rust (`#[contract]`, `#[method]`, `Lazy`, `Mapping`) that derives dispatch, storage layout, and ABI encoding at compile time. The higher-level option, easier to start with. - **DSL** - a thinner abstraction. You write the `call()` entry point yourself and chain methods onto a `ContractBuilder`; storage is bare `host.set_storage` / `get_storage` with hand-computed keys. Produces noticeably smaller bytecode once the contract has real surface area. The choice is about how much plumbing is spelled out by hand vs. generated. Both flavours are **ABI- and storage-compatible with Solidity** : function selectors and calldata encoding match `solc`, and storage uses the same keccak-derived slot keys and packed-field layout as Solidity contracts. The SDK makes that compatibility automatic, with concrete consequences: - **Ethereum tooling works unchanged.** Libraries like ethers, viem, and the cast CLI deploy, call, and read SDK contracts - same selectors and storage slots. - **Cross-contract calls between Solidity and Rust work directly** , and because the wire format and slot derivation match, an EIP-1967 proxy should be able to swap a Solidity implementation for a Rust one behind the same address with no adapter. A token in the macro flavour, sketched to show the shape: ```rust #[pvm_contract_sdk::contract(allocator = "bump")] mod my_token { use pvm_contract_sdk::{Address, HostApi, Lazy, Mapping, U256}; #[derive(pvm_contract_sdk::SolError)] pub struct InsufficientBalance; pub struct MyToken { total_supply: Lazy, balances: Mapping, } impl MyToken { #[pvm_contract_sdk::method] pub fn balance_of(&self, account: Address) -> U256 { self.balances.get(&account) } #[pvm_contract_sdk::method] pub fn transfer(&mut self, to: Address, amount: U256) -> Result<(), InsufficientBalance> { let from = self.caller(); let balance = self.balances.get(&from); if balance < amount { return Err(InsufficientBalance); } self.balances.insert(&from, &(balance - amount)); self.balances.insert(&to, &(self.balances.get(&to) + amount)); Ok(()) } fn caller(&self) -> Address { let mut caller = [0u8; 20]; self.host().caller(&mut caller); Address(caller) } } } ``` ## Why bytecode size matters on PVM PVM bytecode is structurally larger than EVM bytecode, and **every byte of contract code is charged as PoV (proof size) on every call**. Smaller contracts aren’t a cosmetic property - they’re a per-call discount that compounds for the lifetime of the contract. Across our benchmark suite, contracts built with `cargo-pvm-contract` are competitive with the same contracts compiled from Solidity to PVM. The numbers below are an early checkpoint from one benchmark run, not guarantees - they’ll move as the SDK matures - but the broad picture is consistent: - **Rust SDK DSL** is the smallest PVM implementation on every token-shaped contract - roughly a third smaller than Solidity (PVM) on the ERC-20/721/1155 benchmarks. - **Rust SDK macro** lands in the same ballpark as Solidity (PVM) on token-shaped contracts - within roughly ±15% either way - and is expected to stay around it as more features land. ![Bytecode size - token-shaped contracts](https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/e/ebe3c8ef1b0a126358afd472f063b8846bf66187.png) > Benchmark provenance: Rust SDK from `cargo-pvm-contract` `main` at commit `2eec1fe`; Solidity (PVM) compiled with the `resolc` `new_york` branch and Solidity (EVM) with `solc` 0.8.30. Numbers are from a single run on 2026-06-16 and will shift as the SDK and toolchain evolve. ## Status: early preview This is not a 1.0. Several things contracts will eventually want are still being wired up: deeper storage composition, a built-in reentrancy guard, and event-ergonomics polish. Bytecode sizes will move up as those land - the relative position vs. Solidity (PVM) should hold, but absolute numbers are an early checkpoint. ## Where to look - **Code** : [paritytech/cargo-pvm-contract](https://github.com/paritytech/cargo-pvm-contract) - **pallet-revive** (the smart-contract pallet): [paritytech/polkadot-sdk – substrate/frame/revive](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/revive) The SDK is being built in the open. Issues, PRs, and API feedback are all welcome - the surface stabilises over the next few months and input from real contract authors is more useful now than later. ---
**Author:** ![sorpaas](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/sorpaas/32/8430_2.png) [@sorpaas](https://forum.polkadot.network/u/sorpaas)\ **Post date:** [June 17, 2026, 10:52am UTC](https://forum.polkadot.network/t/update-on-cargo-pvm-contract-a-rust-sdk-for-smart-contracts/17896/2 "2026-06-17T10:52:15Z")
> [@smiasojed](#): > > ![Bytecode size - token-shaped contracts](https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/e/ebe3c8ef1b0a126358afd472f063b8846bf66187.png) > > > Benchmark provenance: Rust SDK from `cargo-pvm-contract` `main` at commit `2eec1fe`; Solidity (PVM) compiled with the `resolc` `new_york` branch and Solidity (EVM) with `solc` 0.8.30. Numbers are from a single run on 2026-06-16 and will shift as the SDK and toolchain evolve. You have now found the reason why PVM is a bad idea, as we have already known a year ago: [On Ethereum and EVM compatibility](https://forum.polkadot.network/t/on-ethereum-and-evm-compatibility/13663) By the way, if you just switch from PVM to standard RISC-V, you’ll immediately gain 20% code size reduction. This is how bad PVM is (and also why you had to deploy EVM alongside PVM in Polkadot Hub). > [@Announcing PVM2: Reimagining PVM towards standard RISC-V](https://forum.polkadot.network/t/announcing-pvm2-reimagining-pvm-towards-standard-risc-v/17748/14): > > ![Screenshot 2026-06-08 at 21-01-21 JAR JAM Benchmark](https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/9/90dcad8850c31695250673fda8a3e92270417a63.png) > > The fixed version shows an even more significant gain of PVM2. Note: [PVM2 is standard RISC-V (+c)](https://forum.polkadot.network/t/risc-v-is-all-you-need/17804). So this really reaffirms our conclusion – **the custom PVM ISA is unnecessary and actually much worse than PVM2 (standard RISC-V)**. PVM2 (standard RISC-V) beats PVM on binary size, and performance is better or equivalent. ---
**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:** [June 17, 2026, 11:25am UTC](https://forum.polkadot.network/t/update-on-cargo-pvm-contract-a-rust-sdk-for-smart-contracts/17896/3 "2026-06-17T11:25:31Z")
Hey Wei, how is your [compatibility hub](https://forum.polkadot.network/t/compatibility-hub-for-polkadot/13852/4) going? Can’t wait to see it live on Polkadot to completely crush revive on security on performance. Or is it still in the design phase? ---
**Author:** ![sorpaas](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/sorpaas/32/8430_2.png) [@sorpaas](https://forum.polkadot.network/u/sorpaas)\ **Post date:** [June 17, 2026, 11:33am UTC](https://forum.polkadot.network/t/update-on-cargo-pvm-contract-a-rust-sdk-for-smart-contracts/17896/4 "2026-06-17T11:33:33Z")
We didn’t spend much time on that since the final update. The issue we had is the same as all other teams leaving Polkadot. Honestly, most teams will have much better time forking any of the “products” that you developed, deploying to Ethereum or Monad, than helping you to develop it on Polkadot Hub. This is especially considering the performance and binary size issues of PVM. So we just put it there. We hate to derail the thread on unrelated issues but this is what you’re starting. ---
**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:** [June 17, 2026, 11:34am UTC](https://forum.polkadot.network/t/update-on-cargo-pvm-contract-a-rust-sdk-for-smart-contracts/17896/5 "2026-06-17T11:34:56Z")
So you’ve tried nothing and nothing worked. Whats the point of leaving sour comments on real achievements on a real, deployed and working solution? I congratulate @smiasojed and the Team. This is a fantastic achievement. Please don’t let yourself get frustrated because of bad faith comments. Keep it up! ---
**Author:** ![sorpaas](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/sorpaas/32/8430_2.png) [@sorpaas](https://forum.polkadot.network/u/sorpaas)\ **Post date:** [June 17, 2026, 11:38am UTC](https://forum.polkadot.network/t/update-on-cargo-pvm-contract-a-rust-sdk-for-smart-contracts/17896/6 "2026-06-17T11:38:34Z")
You know that up to today, Moonbeam still has more users than Polkadot Hub, right? Comically, Parity is the team who refused to listen, and then spent multiple years to develop a custom solution, and now… still after 6 months of your product launch, there’s still less than a few thousand contracts on the network. ![Screenshot 2026-06-17 at 13.42.54](https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/b/b6ee084a7f3b700c1258d5b899a8ef52f63edbd7.png) We aren’t the guys leaving sour comments. We pointed out that your PVM solution is bad and we already pointed it out a year ago. We have a technical argument and we won’t be shy to share it. ---
**Author:** ![smiasojed](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/smiasojed/32/2667_2.png) [@smiasojed](https://forum.polkadot.network/u/smiasojed)\ **Post date:** [June 29, 2026, 11:24am UTC](https://forum.polkadot.network/t/update-on-cargo-pvm-contract-a-rust-sdk-for-smart-contracts/17896/7 "2026-06-29T11:24:29Z")
The main purpose of this post is to announce the Rust SDK. Regarding PVM vs EVM on the numbers: - **Per-call PoV** : Rust SDK DSL beats native EVM on ERC-721 mint (−22%) and ERC-1155 create (−9%); within a few % of EVM on simpler workloads. - **Per-call ref\_time** : ~5–16% over EVM today in interpreter mode on token-style workloads. JIT lands on PVM soon and closes most of it. - **Deploy** : single-digit % over EVM on token contracts, paid once. Bytecode size is the one axis where PVM structurally costs more than EVM - that’s why the SDK focuses on shrinking it. On the per-call axes the SDK already lands competitive or ahead, and the residual ref\_time gap is an interpreter-overhead artefact closing with JIT.